Bible Pay

Recent Posts

Pages: 1 ... 3 4 5 6 7 8 9 [10]
91
Setup another wallet, Upgraded both my wallets to v1.4.2.7

getblockhash 63152
48394253*

I still have an old hot masternode (1 wallet), setting up cold masternode now (2 wallets)
Reference: http://wiki.biblepay.org/Create_Sanctuary_2

I agree with you.  Ill stick it out for a while and keep the chain, lets see how we do.

(I'll still put these 3 new features in however, for the next mandatory).

92
I've been having a hard time resyncing every time we have a mandatory upgrade.  I know part of the problem is when we force a new protocol version, it knocks all the sancs offline.  (I have an old biblepay classic feature I am going to port that prevents that, allowing us to sync easier but still forces us to upgrade), so I will need to put this in today.

Two other things, I have realized one of the reasons we have trouble syncing when the diff is < .02 is because the wallet is having a hard time figuring out which fork is valid (in its diff calculator).  I believe we will need a couple consensus rules added.  For one, we should only add and enforce ABNs when the diff is > 1.0 in testnet (and a higher number in prod).  I think this would help us immensely (coming to consensus).  The other is the same with anti-gpu.  We shouldnt really be monitoring or enforcing that if the diff < 1.0.


93
Setup another wallet, Upgraded both my wallets to v1.4.2.7

getblockhash 63152
48394253*

I still have an old hot masternode (1 wallet), setting up cold masternode now (2 wallets)
Reference: http://wiki.biblepay.org/Create_Sanctuary_2
94
1.4.2.7-Mandatory Upgrade for TestNet

- Prevent memory pool tithe attacks
 
95
Our amateur hacker is back online - it seems to be the same person who likes to send 666 to SX.  Probably Slovakia or Noko.

Anyway I have a mandatory upgrade coming in 30 mins, please shut off the miners.

They are going to lose this cat & mouse game- I've been through this before, but this time I'm working for God.

96
As founder I am keeping a very serious eye on any potential forks, as one of the goals of Evo is to eliminate forks with extra prevention layers.

So far we have had a reason for every fork: a mandatory upgrade with half of the sancs running on the old version forced on the network.

I just want to make everyone aware that something we did today should have caused a fork:  Enabling dip15 erases all of the old sancs votes (meaning the daily gsc superblock could fail and I see in the logs the one after that height did fail), then we picked back up later but I see a lot of ddos going on.

We will have to remember, when we are about to go live, we should plan on upgrading all of the sancs in Evo before the cutover height to GSC, have the spork enabled, then start GSC in deterministic mode to prevent this risk in prod.

97
Thats awesome man!  So to elaborate a little more:
1) Dash allows a sanctuary owner to specify where future rewards go (IE they allow you to tell the wallet a specific address to receive sanc rewards).  This is useful if you are trying to make an untraceable wallet.
2) Dash allows any designated public key to be a voting delegate.  This means a friend can vote on a sanc poll for you if you provide their pubkey.

To make this easy to start, the upgradesanc command fills those two things in for you.

To find out how we filled them in, go to receiving addresses, look for:
Yoursancname-D and Yoursancname-V.

The D is the address biblepay set up for your rewards.
The V is the address we created for your voting.

The vote-many and vote-alias automatically finds your V address to vote from (no changes are necessary there).

The rewards will start coming in to the D address (theoretically), lets check that.

Nice features :) I can confirm that the D and V addresses have been created. You're doing a great job Rob!
98
I forgot to mention, we have to wait until everyone upgrades their legacy sancs first, then we flip dip15 to on, then we can check to see if the deterministic rewards start coming into the new address.

99
Cool! Seems to have worked for me. My sanc is now in the dip3 tab :)

Thats awesome man!  So to elaborate a little more:
1) Dash allows a sanctuary owner to specify where future rewards go (IE they allow you to tell the wallet a specific address to receive sanc rewards).  This is useful if you are trying to make an untraceable wallet.
2) Dash allows any designated public key to be a voting delegate.  This means a friend can vote on a sanc poll for you if you provide their pubkey.

To make this easy to start, the upgradesanc command fills those two things in for you.

To find out how we filled them in, go to receiving addresses, look for:
Yoursancname-D and Yoursancname-V.

The D is the address biblepay set up for your rewards.
The V is the address we created for your voting.

The vote-many and vote-alias automatically finds your V address to vote from (no changes are necessary there).

The rewards will start coming in to the D address (theoretically), lets check that.

100
*** UPGRADING A LEGACY BIBLEPAY SANCTUARY TO A DETERMINISTIC SANCTUARY ***



Guys, go ahead and try this.
1.  You must have a *cold* sanc (that means your sanctuary doesn't have the locked funds in it and you have a controller wallet with the funds locked, and the old sanctuary works (IE its probably ENABLED right now), and your controller wallet has a masternode.conf file.

2.  From your controller wallet, go to the RPC terminal and type:
Code: [Select]
exec upgradesanc sanctuary_name 0(where 0 means dry run, and sanctuary_name is the name of the sanctuary (the first field) in the masternode.conf file).

3.  Check the output of that command and make sure there are no errors.  If so continue to the next step.

4.  From the controller wallet, RPC terminal type:
Code: [Select]
exec upgradesanc sanctuary_name 1Ensure this command does not throw an error.

If the results are successful, you will be in the dip3 sanctuary tab (from the Sanctuaries page | Dip3 sancs).

Note that we create a deterministicsanctuary.conf file for your convenience (this is a biblepay feature).  We automatically add all your dip3 sancs to that file.
This will be useful if you have more than say 10, then you can write a script to pull values from this file and do things like update remote configs, run remote commands etc.  Its also highly useful if you need to access your BLSprivkey or BLSpubkey, or voting information.

Cool! Seems to have worked for me. My sanc is now in the dip3 tab :)
Pages: 1 ... 3 4 5 6 7 8 9 [10]