RC3 Relaunch Strategy and Testing

eduffield

Core Developer
Mar 9, 2014
1,084
5,319
183
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:

AlexGR

New Member
May 24, 2014
26
21
3
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.
 
  • Like
Reactions: derk

javqui

New Member
May 18, 2014
6
1
3
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:

miningpoolhub

New Member
Mar 9, 2014
12
1
3
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?
 

TanteStefana

Grizzled Member
Foundation Member
Mar 9, 2014
2,861
1,854
1,283
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
 

flare

Administrator
Dash Core Team
Moderator
May 18, 2014
2,287
2,406
1,183
Germany
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.
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 :)
 

Red-Shinobi

Member
Apr 9, 2014
117
76
78
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.
 
  • Like
Reactions: derk

JGCMiner

Moderator
Moderator
Jun 8, 2014
360
211
113
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
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:

wmr1988

New Member
May 27, 2014
10
2
3
Always encouraging to see such a resourceful developer behind your coin. DRK is going to places. Can't wait.
 

javqui

New Member
May 18, 2014
6
1
3
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:
  • Like
Reactions: minersday

minersday

Member
Apr 9, 2014
77
19
48
+111
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.
 

jimbit

Well-known Member
Foundation Member
May 23, 2014
229
103
203
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.
So when do we need to be ready/running our nodes? This is a good idea!
 

eltito

Active Member
Apr 21, 2014
157
185
103
+1 - but what does the PR team think naming it like that? :D
Lol - personally I think it's great but we can't officially call it that.

Feel free to call it a spork in conversation all you want though.
 
Last edited by a moderator:
  • Like
Reactions: tungfa and flare

thelonecrouton

Well-known Member
Foundation Member
Apr 15, 2014
1,135
813
283
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?
 

flare

Administrator
Dash Core Team
Moderator
May 18, 2014
2,287
2,406
1,183
Germany
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?
Yeah, thought about that too - problem is that the 'regular wallet' is also used to mine, which is dependent on masternode election code. So currently we would have to provide three different flavours of wallets... added complexity.

- regular wallet (mining disabled)
- miner wallet (regular wallet + masternode protocol; opensource)
- masternode (miner wallet + darksend; closed source)

Maybe things simplify as soon as darksend is open sourced...
 
  • Like
Reactions: vertoe

HammerHedd

Member
Mar 10, 2014
182
34
88
Once things go open, probably a lot of this will be simpler

I do like the idea of being able to push code patches - the obvious potential flaw would be someone's ability to manipulate an update to game the system. Still, I do like the idea as I am, of course, in favor of an intelligent network.

Evan, is someone capturing your development process? By that, I mean that you and the dev team have jumped through a ton of hurdles and in the process improvised a number of fork procedures. Some of these have worked well, and some... not so well. I think it is important to document this process, though, because at some point, it will be a fascinating explanation of DRK development. And, although it isn't our business to invent new ways of creating coins, I think the lessons learned from these fork attempts are really valuable to the *-coin community as a whole.
 
  • Like
Reactions: Red-Shinobi

fernando

Powered by Dash
Dash Core Team
Moderator
Foundation Member
May 9, 2014
1,527
2,058
283
Once things go open, probably a lot of this will be simpler

I do like the idea of being able to push code patches - the obvious potential flaw would be someone's ability to manipulate an update to game the system. Still, I do like the idea as I am, of course, in favor of an intelligent network.

Evan, is someone capturing your development process? By that, I mean that you and the dev team have jumped through a ton of hurdles and in the process improvised a number of fork procedures. Some of these have worked well, and some... not so well. I think it is important to document this process, though, because at some point, it will be a fascinating explanation of DRK development. And, although it isn't our business to invent new ways of creating coins, I think the lessons learned from these fork attempts are really valuable to the *-coin community as a whole.
I guess all versions are in github, so anyone interested should be able to look and learn.
 
  • Like
Reactions: Red-Shinobi

HammerHedd

Member
Mar 10, 2014
182
34
88
I guess all versions are in github, so anyone interested should be able to look and learn.
I"m actually thinking more about the process rather than the code... the way to best fork a major change, etc.
We're probably watching history in the making, so I was wondering if anyone was keeping a log or anything.
 
  • Like
Reactions: fernando

simplecrypto

New Member
Jun 26, 2014
1
0
1
.... In the debug log, the system will complain when any issues arise and users can report such issues.....


Would it be possible to get a grep command that could be periodically run over debug logs to check for complaints? I'd gladly do that for our pool node's logs, but I don't have the time required to sift through by hand.