eduffield
Core Developer
Masternode Payment Consensus Protocol
The Masternode voting system launched with RC3 has been removed from the codebase and replaced with an entirely new consensus protocol. Development is completed for the new consensus protocol and it has been working very well in all of our tests.
In a previous statement, we laid out the details of how this new system functions (link: http://goo.gl/pDG9W3) - but in case you missed it:
“[In] each round [of voting], a winning Masternode is chosen to carry out Darksend transactions. This process is carried out by the individual nodes across the network independently using the Masternode election algorithm. This algorithm chooses a winning node for Darksend, but there is also a runner up, third, forth, fifth place, etc.
Utilizing this code, we can make a deterministic list of the “top 10 Masternodes” with the winning scores. These will be the same nodes across the network and they will vote on who they believe should get paid for that round. The winning Masternode will be the one with the most votes (up to 10 votes) and the network will reject blocks not containing that payment entry.”
Unit Test Revamp
Deathray1977 has been all over the code base lately helping us get our unit tests in order. Unit tests allow us to test individual bits of code for functionality, either in advance of merging those bits of code with the rest of the project or for use in debugging. This adds a great deal of efficiency to the entire coding process, which will allow us to bring more high-quality features online faster.
Wallet GUI Improvements
DRKLord has launched a project to overhaul the GUI and add new functionality to the Darkcoin wallet. One example is the addition of new code that will allow the wallet to display current exchange rates on various exchanges.
Please check out DRKLord’s thread on darkcointalk.org and give him some feedback on what changes you would like to see. (link: http://goo.gl/1yFUEb)
RC4 Anonymity Design: “Darksend+”
We’re excited to announce a new iteration of Darksend: Darksend+.
With the original Darksend implementation, one Masternode was tasked with handling both inputs and outputs for a given set of Darksend transactions, returning change to the sender. Various techniques were employed to obfuscate the link between sender and receiver - to great effect - but the Masternode itself was still able to link inputs with outputs.
Darksend+ goes a step further.
The process is now split between two separate Masternodes. Masternode 1 receives an amount of DRK (input) from the sender that is unrelated to the amount intended for the receiver. From that input, Masternode 1 breaks down the total into homogeneous denominations (1, 2, 5, 10, etc.) and sends (output) each denominated chunk of DRK back to the sender’s wallet using randomly generated change addresses.
The sender’s client selects appropriate denominations from those change addresses, totalling the amount of DRK that the sender wishes to send to the receiver, then forwards those denominations to Masternode 2. Masternode 2 mixes those denominations with inputs from other users and sends the desired amount to the intended receivers. This creates a much more anonymous solution than we’ve had in the past.
Because all of the outputs from Masternode 1 are returned to the sender in denominated amounts on randomly generated change addresses, Masternode 1 cannot know the address of the receiver.
Because all of the inputs to Masternode 2 originate from random change addresses, Masternode 2 is unable to determine the addresses from which the original funds were sent. The sender’s primary address and the receiver’s primary wallet address are never simultaneously known by either Masternode 1 or Masternode 2.
There is no direct link between the sender and receiver (by wallet address) at any point in the transaction. This also removes the potential for a transaction to be unmasked by a user accidentally combining change “dust” with funds from their primary wallet address.
This entire process will be automated and transparent to the end user.
Development on the Darksend+ is ongoing and we’re on target for a late July release.
New Additions to the development team
Over the past few weeks, flare has been critical to finding bugs in the RC3 and fine tuning the development process to ensure we have high quality releases. We’re happy to announce Holger Schinzel (flare) is officially joining the team. Holger brings 7 years of experience in IT quality management and testing in the medical devices field.
The Masternode voting system launched with RC3 has been removed from the codebase and replaced with an entirely new consensus protocol. Development is completed for the new consensus protocol and it has been working very well in all of our tests.
In a previous statement, we laid out the details of how this new system functions (link: http://goo.gl/pDG9W3) - but in case you missed it:
“[In] each round [of voting], a winning Masternode is chosen to carry out Darksend transactions. This process is carried out by the individual nodes across the network independently using the Masternode election algorithm. This algorithm chooses a winning node for Darksend, but there is also a runner up, third, forth, fifth place, etc.
Utilizing this code, we can make a deterministic list of the “top 10 Masternodes” with the winning scores. These will be the same nodes across the network and they will vote on who they believe should get paid for that round. The winning Masternode will be the one with the most votes (up to 10 votes) and the network will reject blocks not containing that payment entry.”
Unit Test Revamp
Deathray1977 has been all over the code base lately helping us get our unit tests in order. Unit tests allow us to test individual bits of code for functionality, either in advance of merging those bits of code with the rest of the project or for use in debugging. This adds a great deal of efficiency to the entire coding process, which will allow us to bring more high-quality features online faster.
Wallet GUI Improvements
DRKLord has launched a project to overhaul the GUI and add new functionality to the Darkcoin wallet. One example is the addition of new code that will allow the wallet to display current exchange rates on various exchanges.
Please check out DRKLord’s thread on darkcointalk.org and give him some feedback on what changes you would like to see. (link: http://goo.gl/1yFUEb)
RC4 Anonymity Design: “Darksend+”
We’re excited to announce a new iteration of Darksend: Darksend+.
With the original Darksend implementation, one Masternode was tasked with handling both inputs and outputs for a given set of Darksend transactions, returning change to the sender. Various techniques were employed to obfuscate the link between sender and receiver - to great effect - but the Masternode itself was still able to link inputs with outputs.
Darksend+ goes a step further.
The process is now split between two separate Masternodes. Masternode 1 receives an amount of DRK (input) from the sender that is unrelated to the amount intended for the receiver. From that input, Masternode 1 breaks down the total into homogeneous denominations (1, 2, 5, 10, etc.) and sends (output) each denominated chunk of DRK back to the sender’s wallet using randomly generated change addresses.
The sender’s client selects appropriate denominations from those change addresses, totalling the amount of DRK that the sender wishes to send to the receiver, then forwards those denominations to Masternode 2. Masternode 2 mixes those denominations with inputs from other users and sends the desired amount to the intended receivers. This creates a much more anonymous solution than we’ve had in the past.
Because all of the outputs from Masternode 1 are returned to the sender in denominated amounts on randomly generated change addresses, Masternode 1 cannot know the address of the receiver.
Because all of the inputs to Masternode 2 originate from random change addresses, Masternode 2 is unable to determine the addresses from which the original funds were sent. The sender’s primary address and the receiver’s primary wallet address are never simultaneously known by either Masternode 1 or Masternode 2.
There is no direct link between the sender and receiver (by wallet address) at any point in the transaction. This also removes the potential for a transaction to be unmasked by a user accidentally combining change “dust” with funds from their primary wallet address.
This entire process will be automated and transparent to the end user.
Development on the Darksend+ is ongoing and we’re on target for a late July release.
New Additions to the development team
Over the past few weeks, flare has been critical to finding bugs in the RC3 and fine tuning the development process to ensure we have high quality releases. We’re happy to announce Holger Schinzel (flare) is officially joining the team. Holger brings 7 years of experience in IT quality management and testing in the medical devices field.
