Automatic CheckpointsThis 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 FixThe 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 WorksWe’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 UpdateAt 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 auditAssuming all goes well with RC5, we will do a bit more testing and then open source the project.
