1. Dear Guests, Advertisements are awful. If you make an account they go away.

Development Update - 6/6/2014 - Masternode Payments

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

  1. eduffield

    eduffield Core Developer Core Developer Moderator

    Messages:
    766
    Likes Received:
    3,419
    Trophy Points:
    163
    Automatic Checkpoints

    This week has been a busy one. As we discussed last week, we’ve come up with a strategy to shield Darkcoin from future issues with unintended blockchain forks by adding an automatic checkpointing system. This will allow us to move ahead quickly with development and innovation without risking the occurrence of another forking event like the one we had at the launch of RC2.

    To expedite the implementation of automatic checkpointing, we engaged Hiro, of Hirocoin fame. He had experience with this system and we knew he could implement it quickly and correctly.

    We want to make it clear that automatic checkpointing is a temporary solution that will be removed from the code as soon as we feel it is safe to do so. Though it is clearly beneficial for use as a failsafe mechanism while we perfect the code that powers Darksend, in the long term, the presence of a centralized checkpointing server on the network is unacceptable.

    Masternode Payment Fix

    The Masternode payment system is working nearly perfectly on testnet. Some of the issues we’ve addressed are:
    • Ghost Masternodes - Masternodes which the network continued to list as active even after the Masternode had been taken offline
    • Instances in which Masternode messages were not fully propagating throughout the network

    Modifications were also made which will add some flexibility to the Masternode voting system. This should result in more blocks being paid out to Masternodes.

    At present, about 95% of Masternode payments on testnet are executing properly. The remaining 5% are failing due to inconsistencies in the Masternode lists held by individual clients. There could be a few reasons for these inconsistencies, and we should be able to get closer to a 100% success rate after some more debugging.

    To see the payments as they happen on testnet, check out: http://tdrk.poolhash.org/

    How Masternode Voting Works

    We’ve seen some questions asked about the precise manner in which the Masternode voting system functions. Many people don’t realize that we have an innovative system built into the blockchain solely for the purpose of voting on Masternode payouts. It could be thought of as something like a “blockchain within a blockchain”.

    Before getting into the nuts and bolts, it should be said that although the word “voting” implies some willful intervention on the part of the user, this is absolutely not the case. Voting is performed by the client software in a fully automated process that is hard-coded into the system. It cannot be manipulated by the user.

    The voting system functions as follows:

    Block 14217

    Blockheight ------------Pubkey --------------------- Votes
    14214 ------------ Xaddr1 ---------------------- 2
    14215 ------------ Xaddr2 ---------------------- 3
    14216 ------------ Xaddr3 ---------------------- 2
    14217 ------------ Xaddr4 ---------------------- 1

    If you mined this block, your client added the pubkey for 14217. It's also allowed to increment each existing vote by one if it agrees with it. So the code goes something like this:

    On block 14214 was the pubkey to be paid Xaddr1?
    • If yes increment votes from 1 to 2
    • If no and votes=1, change pubkey to the correct one and don't vote (this only can happen if no voting has happened and it looks incorrect)
    On block 14215 was the pubkey to be paid Xaddr2?
    • If yes increment votes from 2 to 3
    • If no, don't vote
    On block 14216 was the pubkey to be paid Xaddr3?
    • If yes increment votes from 1 to 2
    Added block 14217, pubkey Xaddr4, votes 1

    Timeline Update

    At this point we are comfortable setting a firm release date for RC3. Release dates for versions beyond that will be updated as circumstances dictate and as development progresses.
    • RC3 (June 18th): Fully implemented Masternode payments (20% of each block), automatic checkpointing, fixes for network forking issues
    • RC4 (Mid July): Improved anonymity and removal of 10 DRK Darksend limitation
    • Code Audit: We will release details on this as they become available
    • RC5: Address any security issues or major bugs discovered in the audit

    Assuming all goes well with RC5, we will do a bit more testing and then open source the project.
    Last edited: Jun 6, 2014
    tungfa, vertoe, Populandum and 18 others like this.

    Advertisements are not affiliated with DarkcoinTalk. If you'd like to advertise, click here.

  2. fernando

    fernando Powered by Dash Moderator Foundation Member

    Messages:
    1,009
    Likes Received:
    845
    Trophy Points:
    283
    Launching RC3 on Wednesday 18th is much better than doing it during the weekend like in previous occasions. Exchanges can react better and things should go smoother.
  3. Stray

    Stray New Member

    Messages:
    39
    Likes Received:
    11
    Trophy Points:
    8
    Hi there,
    I have two questions around communication since that was clearly a sore point the first time around:

    1. Will we be able to see something like what I believe Fernando had suggested in another thread to know whose up to date as far as pools and sites go?:
    Pool 1: NOT UPDATED
    Pool 2: Updated
    Site x: Implementing

    2. Will there be a central point of contact or location that is constantly updated for info, with perhaps a core group dedicated to disseminating information across all major channels to address concerns as real time as possible? (Reddit / Twitter / bitcointalk / darkcointalk / facebook / google +,Myspace, smoke signals, etc.) There was a lot of panic when the first notifications of the network forking came out and information was scarce. Also I would not put it past an organized FUD campaign to be online and active trying to cause panic during this event even if everything is going smoothly. We've already been seeing coordinated attacks against this coin and hard fork is clearly a tempting target for rogue actors.

    Thank you.
    derk likes this.
  4. fernando

    fernando Powered by Dash Moderator Foundation Member

    Messages:
    1,009
    Likes Received:
    845
    Trophy Points:
    283
    Yes to both. We are already planning and we will be ready!!!
    derk likes this.
  5. derk

    derk New Member

    Messages:
    38
    Likes Received:
    20
    Trophy Points:
    8
    If you need anyone to proofread anything you can send it to me.
    fernando likes this.
  6. eltito

    eltito Active Member Community Lead

    Messages:
    159
    Likes Received:
    185
    Trophy Points:
    103
    As fernando already said, we have been working out a system for information dissemination for the past couple weeks in the wake of the issues with RC2. We have a very good head start already, and between now and the 18th the Community Team will make it a top priority to flesh this system out.

    Sometime before the RC3 release we will issue a statement detailing key personnel, sites and sources for official information that you can access before, during and after the fork.
    derk and tifozi like this.
  7. TanteStefana

    TanteStefana Active Member Linguistic

    Messages:
    940
    Likes Received:
    399
    Trophy Points:
    133
    Great explanation of the voting system! I kinda got it with the conversation on the other thread, but it hurt my brain, :eek::tongue::grin: This wrapped it up nice and simple, LOL
  8. phryed

    phryed Member

    Messages:
    45
    Likes Received:
    2
    Trophy Points:
    48
    Thanks for all the hard work!
  9. fusecavator

    fusecavator Member

    Messages:
    40
    Likes Received:
    38
    Trophy Points:
    58
    I'm still not quite following how this is tamper-proof. If the client is allowed to decide whether it agrees or not and how to vote, then why wouldn't miners use modified clients that never vote when they mine a block? It may not directly affect their earnings for that block they mined, but especially in the case of pools , it could cause less to get paid out to masternodes in later blocks they have a chance of mining?
    flare likes this.
  10. flare

    flare Official Dash Dev Core Developer

    Messages:
    1,625
    Likes Received:
    1,472
    Trophy Points:
    183
    I concur this argument: Pools may be very interested to sabotage the voting system by increasing the unpaid blocks to increase their own earnings. Sad we live in a bad world... :sad:

    Are there any countermeasures to harden the voting system against such an attack? Or is relying on 51% hashpower needed enough?
  11. Raico

    Raico Well-Known Member Foundation Member

    Messages:
    119
    Likes Received:
    98
    Trophy Points:
    178
    Nice ~!
    Thanks everyone for your contribution.
  12. ImI

    ImI New Member

    Messages:
    13
    Likes Received:
    1
    Trophy Points:
    3
    agree. i also suggest to promote twitter as backup communication channel. as i would expect ddos to knock out any smaller site as soon as the fork starts.
  13. TanteStefana

    TanteStefana Active Member Linguistic

    Messages:
    940
    Likes Received:
    399
    Trophy Points:
    133
    Is there a way to keep the rewards to miners at 80% no matter what? That way they can't play the system? However, it would have to be a huge group effort to do this and expect any rewards to make their way around to you again...
    Last edited: Jun 7, 2014
  14. YourNightmare

    YourNightmare New Member Linguistic

    Messages:
    23
    Likes Received:
    4
    Trophy Points:
    3
    Thanks for very good explanation! Waiting for relase. Great Job guys!
  15. flare

    flare Official Dash Dev Core Developer

    Messages:
    1,625
    Likes Received:
    1,472
    Trophy Points:
    183
    Agreed, its perhaps more a theoretical scenario: The group will need enough power to supress the votes for 10 rounds to push them into expiration, which means you have to mine 6 blocks out of 10. Thats surely more than 51% hashpower :grin:
  16. vertoe

    vertoe Three of Nine

    Messages:
    2,750
    Likes Received:
    1,764
    Trophy Points:
    1,283
    Well its the same like hashpower. If you want to attack the mining network you will need at least 100-150 GH/s power.
    If you want to attack the voting network, you would need at least 500k DRK.
    Both is very unlikely currently.
  17. fusecavator

    fusecavator Member

    Messages:
    40
    Likes Received:
    38
    Trophy Points:
    58
    I could be misunderstanding something, but it seems to me that it's very different than hashpower. Hashpower can be verified by walking through the blockchain from the beginning, regardless of what point in time the verification is done. For checking on whether a masternode is accessible and whether to vote on it, verification can only be done at that time, as nodes can move and go up and down. On top of that, different users' internet access will be through different ISPs, different firewalls, different filters, etc, so different legitimate users may have different views on what is and isn't accessible, so verification can't really be done at all. This seems to fit with the description in the OP which seems to indicate that only the blockfinders(usually pools) cast votes, and thus can simply vote however they choose. Unlike a normal 51% attack, improper blocks(ones without voting for anyone), will still get accepted and paid like normal, so a coordinated attack does not need to be made. If people use rigged clients that never vote they'll get paid normally if less than 51% of hashpower is on a rigged client, and they'll cut off masternode payments completely when 51% of hashpower is on rigged clients.

    One possible solution could be to require a certain minimum amount of votes to be cast, otherwise the block is rejected. If a block must vote for more than half of the nodes it can vote for, it can avoid paying dead nodes, but would be unable to screw everyone. Rigged clients to prevent payments would still be possible, but they would only be able to prevent some rather than all.
Live Thread addon by sonnb