TestNet - BiblePay-Evolution & GSCs (Generic Smart Contracts)

That seems to have worked It's in PRE-ENABLED mode now because I restarted it. My sancs IP is the 84.92 one.

84.29 :p

I upgraded but forgot to turn my QT back on, Im up now and match

getblockhash 62042
4d32aab9042e18a6ecc2229875b0e94499204be423e4084bd18076c02f7e2748

Masternode was in UPDATE_REQUIRED status, just started it, now in PRE_ENABLED

It appears my sanc 45.63 has upgraded to Deterministic (dip3).  I manually voted on a proposal and the vote went through, and it says ENABLED.  Checking now to see if it votes on the next GSC automatically.

NOTES:  We must remember this critical Note!  After we upgrade all of our testnet sancs to deterministic, and I flip DIP15, this will make the non-deterministic list dissapear.  We need to ensure that someone can still create a legacy sanc and upgrade it after that moment (so we know how to deal with that scenario).  I hope that also works, because we will surely have some stragglers who want to add a few sancs after dip15 is enabled - who dont want to go through the long process of creating a deterministic sanc.

Hey Rob, what are the steps to upgrade to a deterministic masternode?
https://docs.dash.org/en/stable/masternodes/dip3-upgrade.html

From some digging, looks like you added a command in v1.4.1.7:

Code: [Select]

exec upgradesanc sancname
Reference: https://forum.biblepay.org/index.php?topic=391.msg5798#msg5798

Hey Rob, what are the steps to upgrade to a deterministic masternode?
https://docs.dash.org/en/stable/masternodes/dip3-upgrade.html

From some digging, looks like you added a command in v1.4.1.7:

Code: [Select]

exec upgradesanc sancname
Reference: https://forum.biblepay.org/index.php?topic=391.msg5798#msg5798

Yeah, I just upgraded one of my sancs and it worked.

Lets go ahead and upgrade some, one sec.

*** 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.

*** 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

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.

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.

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!

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.

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.

1.4.2.7-Mandatory Upgrade for TestNet

- Prevent memory pool tithe attacks
 

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'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.