Development Update - 6/6/2014 - Masternode Payments

eduffield

Core Developer
Mar 9, 2014
1,084
5,320
183
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 by a moderator:

fernando

Powered by Dash
Dash Core Team
Moderator
Foundation Member
May 9, 2014
1,527
2,058
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.
 

Stray

Member
May 27, 2014
43
14
48
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.
 
  • Like
Reactions: derk

fernando

Powered by Dash
Dash Core Team
Moderator
Foundation Member
May 9, 2014
1,527
2,058
283
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.
Yes to both. We are already planning and we will be ready!!!
 
  • Like
Reactions: derk

eltito

Active Member
Apr 21, 2014
157
185
103
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.
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.
 
  • Like
Reactions: derk and tifozi

TanteStefana

Grizzled Member
Foundation Member
Mar 9, 2014
2,863
1,854
1,283
Great explanation of the voting system! I kinda got it with the conversation on the other thread, but it hurt my brain, :eek::tongue::D This wrapped it up nice and simple, LOL
 

fusecavator

Member
Jun 4, 2014
40
38
58
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.
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?
 
  • Like
Reactions: flare

flare

Administrator
Dash Core Team
Moderator
May 18, 2014
2,286
2,404
1,183
Germany
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?
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?
 

Raico

Well-known Member
Foundation Member
Dash Support Group
May 28, 2014
138
142
193
Nice ~!
Thanks everyone for your contribution.
 

ImI

New Member
May 27, 2014
14
1
3
Hi there,

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

TanteStefana

Grizzled Member
Foundation Member
Mar 9, 2014
2,863
1,854
1,283
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?
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 by a moderator:

flare

Administrator
Dash Core Team
Moderator
May 18, 2014
2,286
2,404
1,183
Germany
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...
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 :D
 

vertoe

Three of Nine
Mar 28, 2014
2,573
1,652
1,283
Unimatrix Zero One
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 :D
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.
 

fusecavator

Member
Jun 4, 2014
40
38
58
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.
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.