Welcome to the Dash Forum!

Please sign up to discuss the most innovative cryptocurrency!

RC3 Relaunch Strategy and Testing

Discussion in 'Official Developer Thread' started by eduffield, Jun 23, 2014.

  1. eduffield

    eduffield Core Developer
    Core Developer Moderator

    Joined:
    Mar 9, 2014
    Messages:
    1,084
    Likes Received:
    5,308
    Trophy Points:
    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.
     
    #1 eduffield, Jun 23, 2014
    Last edited by a moderator: Jun 23, 2014
    • Like Like x 30
  2. David

    David Well-known Member
    Masternode Owner/Operator

    Joined:
    Jun 21, 2014
    Messages:
    617
    Likes Received:
    628
    Trophy Points:
    163
    Wow, that is absolutely brilliant. I'm so glad you're on our team!!
     
    • Like Like x 1
  3. AlexGR

    AlexGR New Member

    Joined:
    May 24, 2014
    Messages:
    26
    Likes Received:
    21
    Trophy Points:
    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 Like x 1
  4. tifozi

    tifozi New Member

    Joined:
    Mar 23, 2014
    Messages:
    18
    Likes Received:
    8
    Trophy Points:
    3
    Indeed. Sounds like a great plan.
     
    • Like Like x 1
  5. javqui

    javqui New Member

    Joined:
    May 18, 2014
    Messages:
    6
    Likes Received:
    1
    Trophy Points:
    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.
     
    #5 javqui, Jun 23, 2014
    Last edited by a moderator: Jun 23, 2014
  6. miningpoolhub

    miningpoolhub New Member

    Joined:
    Mar 9, 2014
    Messages:
    12
    Likes Received:
    1
    Trophy Points:
    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?
     
  7. TanteStefana

    TanteStefana Moderator
    Dash Core Group Linguistic Foundation Member

    Joined:
    Mar 9, 2014
    Messages:
    2,754
    Likes Received:
    1,817
    Trophy Points:
    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
     
  8. flare

    flare Administrator
    Core Developer Moderator

    Joined:
    May 18, 2014
    Messages:
    2,245
    Likes Received:
    2,400
    Trophy Points:
    1,183
    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 :)
     
  9. Red-Shinobi

    Red-Shinobi Member

    Joined:
    Apr 9, 2014
    Messages:
    112
    Likes Received:
    75
    Trophy Points:
    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 Like x 1
  10. JGCMiner

    JGCMiner Active Member

    Joined:
    Jun 8, 2014
    Messages:
    289
    Likes Received:
    177
    Trophy Points:
    103
    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.
     
    #10 JGCMiner, Jun 23, 2014
    Last edited by a moderator: Jun 23, 2014
  11. wmr1988

    wmr1988 New Member

    Joined:
    May 27, 2014
    Messages:
    10
    Likes Received:
    2
    Trophy Points:
    3
    Always encouraging to see such a resourceful developer behind your coin. DRK is going to places. Can't wait.
     
  12. javqui

    javqui New Member

    Joined:
    May 18, 2014
    Messages:
    6
    Likes Received:
    1
    Trophy Points:
    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.
     
    #12 javqui, Jun 23, 2014
    Last edited by a moderator: Jun 23, 2014
    • Like Like x 1
  13. minersday

    minersday Member

    Joined:
    Apr 9, 2014
    Messages:
    77
    Likes Received:
    19
    Trophy Points:
    48
    +111
     
  14. stilgars

    stilgars New Member

    Joined:
    Jun 21, 2014
    Messages:
    11
    Likes Received:
    10
    Trophy Points:
    3
    great plan, and good way to manage expectation
     
  15. jimbit

    jimbit Well-known Member
    Foundation Member Masternode Owner/Operator

    Joined:
    May 23, 2014
    Messages:
    223
    Likes Received:
    103
    Trophy Points:
    203
    We call it a spork :)
     
    • Like Like x 4
  16. flare

    flare Administrator
    Core Developer Moderator

    Joined:
    May 18, 2014
    Messages:
    2,245
    Likes Received:
    2,400
    Trophy Points:
    1,183
    +1 - but what does the PR team think naming it like that? :D
     
  17. jimbit

    jimbit Well-known Member
    Foundation Member Masternode Owner/Operator

    Joined:
    May 23, 2014
    Messages:
    223
    Likes Received:
    103
    Trophy Points:
    203
    So when do we need to be ready/running our nodes? This is a good idea!
     
  18. yidakee

    yidakee Well-known Member
    Dash Core Group Foundation Member

    Joined:
    Apr 16, 2014
    Messages:
    1,812
    Likes Received:
    1,168
    Trophy Points:
    283
    I assume a new version will be out addressing the double block voting hash glitch ?
     
  19. eltito

    eltito Active Member

    Joined:
    Apr 21, 2014
    Messages:
    157
    Likes Received:
    185
    Trophy Points:
    103
    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.
     
    #19 eltito, Jun 23, 2014
    Last edited by a moderator: Jun 23, 2014
    • Like Like x 2
  20. thelonecrouton

    thelonecrouton Well-known Member
    Foundation Member

    Joined:
    Apr 15, 2014
    Messages:
    1,140
    Likes Received:
    816
    Trophy Points:
    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?
     
  21. flare

    flare Administrator
    Core Developer Moderator

    Joined:
    May 18, 2014
    Messages:
    2,245
    Likes Received:
    2,400
    Trophy Points:
    1,183
    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 Like x 1
  22. HammerHedd

    HammerHedd Member

    Joined:
    Mar 10, 2014
    Messages:
    182
    Likes Received:
    32
    Trophy Points:
    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 Like x 1
  23. fernando

    fernando Powered by Dash
    Dash Core Group Foundation Member Moderator

    Joined:
    May 9, 2014
    Messages:
    1,495
    Likes Received:
    1,935
    Trophy Points:
    283
    I guess all versions are in github, so anyone interested should be able to look and learn.
     
    • Like Like x 1
  24. recan86

    recan86 Member

    Joined:
    Jun 8, 2014
    Messages:
    75
    Likes Received:
    23
    Trophy Points:
    48
    Is there a tentative timeline for moving forward?
     
  25. Ignition75

    Ignition75 Active Member

    Joined:
    May 25, 2014
    Messages:
    334
    Likes Received:
    207
    Trophy Points:
    113
    Good to see the project is being managed well... No rush, loving cheap DRK for a short while longer :cool:
     
  26. HammerHedd

    HammerHedd Member

    Joined:
    Mar 10, 2014
    Messages:
    182
    Likes Received:
    32
    Trophy Points:
    88
    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 Like x 1
  27. simplecrypto

    simplecrypto New Member

    Joined:
    Jun 26, 2014
    Messages:
    1
    Likes Received:
    0
    Trophy Points:
    1


    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.
     
  28. flare

    flare Administrator
    Core Developer Moderator

    Joined:
    May 18, 2014
    Messages:
    2,245
    Likes Received:
    2,400
    Trophy Points:
    1,183
    It seems the spork sporked :)
     
    #28 flare, Jun 26, 2014
    Last edited by a moderator: Jun 26, 2014
    • Like Like x 2

Share This Page