RC3 Relaunch Strategy and Testing

eduffield

eduffield

Core Developer
The last couple of days I've been working on implementing the hashing algorithm for the last issues we had on the 20th and I've come up with a strategy that I think will much better suit us for launching the masternode payment system.

Instead I propose the following plan for launching RC3 in stages, which will be much safer and more stable:

We'll introduce an "enforcing" setting for masternode payments. This will be turned off at launch making it the equivalent of a soft fork, but will allow us to use the full infrastructure of the darkcoin network for testing. In the debug log, the system will complain when any issues arise and users can report such issues. After a period of time passes with no issues, we'll set a date to begin enforcing. At this time all issues should be dealt with so we'll have a much smoother launch.

In the past launches all problems have come from the client checking the block to possible forging of masternode votes. With enforcing mode off, the system will still detect these and report them but it won't reject the block. So once we stop seeing these messages (except for valid forged blocks) the system is ready.

This also allows us to turn on masternode payments much sooner. I believe it will take us just a few days to test this new setup, then we can turn them on for mainnet.
 
Last edited by a moderator:
Sounds like a plan... will it be trialed on testnet first to see how it works? If yes, do a test with a client that maliciously tries to "enforce on" to see what happens in that scenario and also do a simulation run on what will happen when we activate "enforce on" on the main network and some clients are still either on the old "enforce off" status or the even older clients who do not have such features.
 
Great Idea. I really like it.
Maybe setting a one-time-use centralized switch could help to reduce the stress related with multiple software updates. The switch will not have a pre defined time to activate it. (Additionally it could work as an emergency shut-off for a revert, just in case it will be necessary to avoid panic).
Later it can be removed without a stressful mandatory update. (maybe on RC4 or other opportunity that you consider better and safe).

For your consideration, the switch, can be as easy as a withdraw from a pre-defined DRK account that you hold to easily propagate over the network. if you withdraw from A to B wallet, switch is on, system will run with payments (normal mode). if you withdraw from A to C, and payments are running, the system will shut-off. You can go creative with the variants of this proposal.
 
Last edited by a moderator:
Good idea.

How will the enforce mode will be triggered?
Will you announce and every wallet owners enforce at the same time? Or is it automatically triggered from central server?
 
What a cool idea, had no idea you could do that! Exciting! Ready to go, just say the word!

I'm assuming when you're ready to start masternode payments, we'll update again? And also, the network will still keep the blockchain properly checked, right? It's only the masternode payments that won't be enforeced, no? Thanks for explaining
 
eduffield said:
The last couple of days I've been working on implementing the hashing algorithm for the last issues we had on the 20th and I've come up with a strategy that I think will much better suit us for launching the masternode payment system.

Instead I propose the following plan for launching RC3 in stages, which will be much safer and more stable:

We'll introduce an "enforcing" setting for masternode payments. This will be turned off at launch making it the equivalent of a soft fork, but will allow us to use the full infrastructure of the darkcoin network for testing. In the debug log, the system will complain when any issues arise and users can report such issues. After a period of time passes with no issues, we'll set a date to begin enforcing. At this time all issues should be dealt with so we'll have a much smoother launch.

In the past launches all problems have come from the client checking the block to possible forging of masternode votes. With enforcing mode off, the system will still detect these and report them but it won't reject the block. So once we stop seeing these messages (except for valid forged blocks) the system is ready.

This also allows us to turn on masternode payments much sooner. I believe it will take us just a few days to test this new setup, then we can turn them on for mainnet.
Click to expand...
Good idea, will give us the ability to "test" the feature in mainnet before activation - has more of a soft launch than a hard fork :)
 
My Man.....Enforcing sounds bad-ass!
I cant wait to enforce some shit with my wallet now. Could we upgrade to "Epic Master Node Enforcement" at some point with this technology? I'm thrilled either way
Brilliant development.
 
TanteStefana said:
What a cool idea, had no idea you could do that! Exciting! Ready to go, just say the word!

I'm assuming when you're ready to start masternode payments, we'll update again? And also, the network will still keep the blockchain properly checked, right? It's only the masternode payments that won't be enforeced, no? Thanks for explaining
Click to expand...

As I understand it masternodes will be paid. Furthermore, the network will be checked and bad/forged blocks will be flagged, BUT the network will not reject these blocks so long as "enforcing" is set to off.

This means that this will be a soft fork.

The disadvantage is that pools that don't update their clients won't pay masternodes and, of course, they could modify their clients to do something fraudulent to the MN payments. This will get flagged in the debug log, but the block will still be accepted.

The advantage is that this will not cause unwanted forking so whenever this update does go in MNs will finally start getting paid without having to worry about any more reverting. Also, the debug log will be studied and the bad blocks that are getting flagged can be compared against expectations. Any blocks that are getting inappropriately flagged means that there is likely a bug which can then get fixed without have to revert.

Once there are no unexpected flagged blocks for a length of time, we will then hardfork to allow the network to not just flag but also reject bad blocks. Assuming that due diligence was done using the debug logs, this fork will go smoothly.

I was one of those who argued against a voluntary MN payment system even for a short time, but given how hard this is proving to be to successfully implement while only testing on testnet and the fact that we can't keep testing on mainnet then reverting -- I think that this is a wise way (maybe the only way) to proceed forward.
 
Last edited by a moderator:
Always encouraging to see such a resourceful developer behind your coin. DRK is going to places. Can't wait.
 
a basic pseudo code example of the temporal remote switch control: (it can implement many other things or use a similar approach)

int flag_EnablePayments=0;
int flag_otherDebug1=0;
int flag_otherDebug2=0;
int flag_parameter1=0;
.......
string controlAddress;
double trInput;
.......
while ( blockchainExplorerScan) {
if (trInput = TransactionFROM(controlAddress)) {
// last trInput will control the Flag_enablePayments
switch (trInput) {
case 0.0477:
flag_EnablePayments = -1; break;
case 0.0921:
flag_EnablePayments = 0; break;
case 0.0142:
flag_otherDebug1 = -1; break;
case 0.0149:
flag_otherDebug1 = 0; break;
case 0.073:
flag_otherDebug2 = -1; break;
case 0.041:
flag_otherDebug2 = 0; break;
default:
if (trInput > 0.001 && trInput < 0.01) {
flag_parameter1 = (trInput - 0.001) * 1000;
} else { // more debug control conditions }
}
}
}

DebugPrintLog("temporal remote custom activation: EnablePayments: %1, Flag1: %2, Flag2: %3, parameter1: %4, flag_EnablePayments, flag_otherDebug1,flag_otherDebug2, flag_parameter1);
---------------------------------------------------------------------------------------------------------------------

Propagation across network will be faster than ask everybody to update a binary.
Using the data payload, you can even include pre-compiled code (x64) in the form of external libraries to update/ replace critical parts of the code almost instantly. (Many real life products use this trick, and with the security of the blockchain it could be implemented temporarily to accelerate the debugging and reduce the stress of continuous mandatory updates)
Bad actors will be always bad actors so will not be a problem on this specific case.

Hope will be useful for the community and developers.
 
Last edited by a moderator:
+111
javqui said:
a basic pseudo code example of the temporal remote switch control: (it can implement many other things or use a similar approach)

int flag_EnablePayments=0;
int flag_otherDebug1=0;
int flag_otherDebug2=0;
int flag_parameter1=0;
.......
string controlAddress;
double trInput;
.......
while ( blockchainExplorerScan) {
if (trInput = TransactionFROM(controlAddress)) {
// last trInput will control the Flag_enablePayments
switch (trInput) {
case 0.0477:
flag_EnablePayments = -1; break;
case 0.0921:
flag_EnablePayments = 0; break;
case 0.0142:
flag_otherDebug1 = -1; break;
case 0.0149:
flag_otherDebug1 = 0; break;
case 0.073:
flag_otherDebug2 = -1; break;
case 0.041:
flag_otherDebug2 = 0; break;
default:
if (trInput > 0.001 && trInput < 0.01) {
flag_parameter1 = (trInput - 0.001) * 1000;
} else { // more debug control conditions }
}
}
}

DebugPrintLog("temporal remote custom activation: EnablePayments: %1, Flag1: %2, Flag2: %3, parameter1: %4, flag_EnablePayments, flag_otherDebug1,flag_otherDebug2, flag_parameter1);
---------------------------------------------------------------------------------------------------------------------

Propagation across network will be faster than ask everybody to update a binary.
Using the data payload, you can even include pre-compiled code (x64) in the form of external libraries to update/ replace critical parts of the code almost instantly. (Many real life products use this trick, and with the security of the blockchain it could be implemented temporarily to accelerate the debugging and reduce the stress of continuous mandatory updates)
Bad actors will be always bad actors so will not be a problem on this specific case.

Hope will be useful for the community and developers.
Click to expand...
 
eduffield said:
The last couple of days I've been working on implementing the hashing algorithm for the last issues we had on the 20th and I've come up with a strategy that I think will much better suit us for launching the masternode payment system.

Instead I propose the following plan for launching RC3 in stages, which will be much safer and more stable:

We'll introduce an "enforcing" setting for masternode payments. This will be turned off at launch making it the equivalent of a soft fork, but will allow us to use the full infrastructure of the darkcoin network for testing. In the debug log, the system will complain when any issues arise and users can report such issues. After a period of time passes with no issues, we'll set a date to begin enforcing. At this time all issues should be dealt with so we'll have a much smoother launch.

In the past launches all problems have come from the client checking the block to possible forging of masternode votes. With enforcing mode off, the system will still detect these and report them but it won't reject the block. So once we stop seeing these messages (except for valid forged blocks) the system is ready.

This also allows us to turn on masternode payments much sooner. I believe it will take us just a few days to test this new setup, then we can turn them on for mainnet.
Click to expand...

So when do we need to be ready/running our nodes? This is a good idea!
 
Would it be possible to eventually separate client and masternode code so that masternodes could be upgraded / add new features without regular wallets needing to update also?
 
You must log in or register to reply here.
Back
Top