Development Updates - July 15th

eduffield

Core Developer
Mar 9, 2014
1,084
5,319
183
DarkSend+

Over the last week or two, Darksend+ has made some significant advances. We’re happy to say that we’re closing in on a finished product.

We've opted to employ a strategy for Darksend+ that is slightly different than the one we outlined in our last update. This new strategy has several advantages, and we think it is a significant improvement over the previous iteration in terms of both privacy and efficiency. The Darkcoin client will now store pre-mixed, denominated Darkcoins in the user’s wallet, to be used instantly at any time the user desires. The mixing and denomination process is seamless, automatic, and requires no intervention on the part of the user. The 10 DRK limit previously in place with Darksend v1 will be permanently removed. With RC4, the amount that users can send via Darksend+ is limited only by the available balance in their wallet.

Here's how it works:

Every 10 blocks, user clients network-wide will send any unmixed, traceable Darkcoins in their possession through an anonymization phase. In this phase, Masternodes are used in chained succession to mix the coins they receive from the network and break them down into homogenous denominations. After being processed by a minimum of 2 Masternodes, the coins are either sent to the next Masternode in the chain or back to the user’s wallet at randomly generated change addresses.

Depending on the desired depth of security and privacy, users may select between 2 and 8 “hops” to successive Masternodes before their coins are sent back to the client. Hops are made every 10 blocks, so anonymization at a depth of 2 hops will take 10*2*2.5=50 minutes, 3 hops 10*3*2.5=75 minutes, and so on. The desired mixing depth can be selected in the client GUI.

At the end of the anonymization phase, the user’s coins are returned to their client at randomly generated change addresses. When the user wishes to make a transaction, the client forwards the intended amount from these anonymous change addresses directly to the intended receiver’s address. There is no direct involvement of of Masternodes in the final person-to-person transaction.

Proof of payment will work as it always has: a user can see the send transaction with the receiver’s address in their own wallet, and the blockchain will show that the receiver’s address received an input in the corresponding amount.

A breakdown of the improved Darksend+ process:



fernando on the darkcointalk.org forums created a chart outlining the probability of unmasking a Darksend by way of Masternode collusion at depths of both 2 and 8 Masternode hops:

2 hops: http://goo.gl/g1dQ3C
8 hops: http://goo.gl/TcWoF0

Masternode Payment Soft Fork Compliance

We’re pleased to announce that through efforts lead by GhostPlayer/yidakee - with the assistance of many, many others - we’ve been able to reach a very high degree Masternode payment compliance from pools mining Darkcoin. This has been an outstanding show of participation from our community and a reassuring display of willingness on the part of those pools to see our vision for Darkcoin come to fruition. Thank you to everyone involved.

Testnet Phase

Development on RC4 is nearing an end and we expect that we’ll be firing up testnet in the coming week. Depending on what we find, testing and QA should take 2 to 4 weeks.

Code Review

Kristov Atlas has agreed to be the first to review the Darksend code. Kristov will be evaluating anonymity and overall design of our technology and will report his findings publicly. We’ll be sending the code to him soon and we anticipate that we will hear back from Kristov by the end of the month.

Separating main.cpp logic for faster compiling / development

Deathray will soon be splitting our main.cpp from it’s monolithic state to speed up compiling in the future.

Masternode List Differences

Clients will now be able to ask the network for information on Masternodes they didn’t previously know existed. This is an improvement over the old protocol, where a ping from an unknown Masternode would just be ignored by the client. This and other improvements should improve the Masternode list consistency throughout the network.

Bootstrapping Process

Flare has been working on getting redundant DNS seed servers setup. Results are very promising: when you start the client, you’re now instantly connected to 8 peers, and downloading the entire blockchain takes just 5 to 15 minutes.

Gitian Build Process

We’ve switched to a secure build system called Gitian for building the Darkcoin binaries for Windows, Mac and Linux. This means you can download trusted binaries that can be verified by multiple builders.

Gitian uses a determinist build process to allow multiple parties to create identical binaries. After comparing the binaries, the builders can determine that they were not tampered with and sign them. This creates a system in which the compiling process is not depended on a single point of failure.
 

Lzeppelin

Member
Feb 27, 2014
283
57
88
To the moon! Seriously though it's great news I think the removal of all darksend limits makes this coin actually usable for it's intended purpose for the first time and the price will reflect this, before RC4 darksend was little more than a proof of concept. I can't wait until RC4!
 

Vyazhan

Member
Jun 23, 2014
62
20
48
I am thoroughly impressed by this work and can't wait to see it blossom :) Keep up this amazing show, can't wait to see where it's going!
 

karisu

Member
Jun 30, 2014
70
26
58
Awesome, I will point my miner to testnet if the time is ready and if it makes sense. Is there anything an outsider can do to help?
 

Ryan Taylor

Well-known Member
Dash Core Team
Foundation Member
Jul 3, 2014
539
1,631
263
Scottsdale, AZ, USA
Is Receiver A's address anonymous? It's not clear from the above description. For example, if Receiver A is a merchant, will you still be able to see how much DRK that merchant's address is receiving?
Also, are their any measures to ensure MNs are not selected for later rounds? For example, is MN1 also eligible to become MN2 10 blocks later, or MN3 10 blocks after that? Or does MN1 become ineligible for the next rounds to ensure it isn't selected again for later rounds? Disbarring individual MNs from serving twice in the chain would make a rouge MN attack much harder to achieve.
 

fernando

Powered by Dash
Dash Core Team
Moderator
Foundation Member
May 9, 2014
1,527
2,058
283
Awesome, I will point my miner to testnet if the time is ready and if it makes sense. Is there anything an outsider can do to help?
Of course you can, keep an eye on the Testing subforum. You can mine, run a masternode, mess with transactions... everyone is welcome!
 
  • Like
Reactions: flare and chaeplin

Brilliantrocket

New Member
May 12, 2014
11
4
3
Is Receiver A's address anonymous? It's not clear from the above description. For example, if Receiver A is a merchant, will you still be able to see how much DRK that merchant's address is receiving?
Also, are their any measures to ensure MNs are not selected for later rounds? For example, is MN1 also eligible to become MN2 10 blocks later, or MN3 10 blocks after that? Or does MN1 become ineligible for the next rounds to ensure it isn't selected again for later rounds? Disbarring individual MNs from serving twice in the chain would make a rouge MN attack much harder to achieve.
A nice feature for privacy conscious merchants would be a public display address that automatically darksends to a "private" address.
 
N

nj47

Guest
A nice feature for privacy conscious merchants would be a public display address that automatically darksends to a "private" address.
That would be trivial to setup on the software level. It is a feature used by so few I don't think it is necessary on the client level. Don't get me wrong, it is a great idea, but it makes more sense in a different part of the coin transaction cycle.
 

thelonecrouton

Well-known Member
Foundation Member
Apr 15, 2014
1,135
813
283
So, will no one address ever contain more than the largest possible denominated amount? And the client just groups them together appropriately for transactions, which are redenominated at the other end? Because that renders the whole blockchain entropic sludge and makes timing analysis impossible...
 

Abdulaziz

New Member
Jul 3, 2014
16
26
13
Awesome news, good to know Evan and the team are been transparent about their work. Having a man like Kristov Atlas review is a + as well.

Looking forward =]
 

jpr

Active Member
May 11, 2014
493
393
133
Kristov said something about not much time to do it now? Do we have his DRK address for donations?
 
  • Like
Reactions: ourlink

tifozi

New Member
Mar 23, 2014
18
8
3
Kristov said something about not much time to do it now? Do we have his DRK address for donations?
He announced today is his video review that he will set up an address in the near future, while he engages in the code review.
 

crowning

Well-known Member
May 29, 2014
1,415
1,997
183
Alpha Centauri Bc
[...]Every 10 blocks, user clients network-wide will send any unmixed, traceable Darkcoins in their possession through an anonymization phase. In this phase, Masternodes are used in chained succession to mix the coins they receive from the network and break them down into homogenous denominations. After being processed by a minimum of 2 Masternodes, the coins are either sent to the next Masternode in the chain or back to the user’s wallet at randomly generated change addresses.
What happens when one (or all) masternodes involved break down/get hacked/do intentionally bad things/... while _my_ coins are on their trip to anonymity?
 

fusecavator

Member
Jun 4, 2014
40
38
58
The desired mixing depth can be selected in the client GUI.
Could you make this semi-random? If you let everyone set whatever they want in the wallet from 2-8, almost all people will either select 2 for speed, or 8 for more stealth, and nothing in between. This would give a fairly decent assumption an attacker might be able to find a way to leverage when trying to trace coins. Instead offering "about 4-6" which would be actually done as pick a random number of what the user chose plus or minus 2 cycles would destroy that assumption.
 

JGCMiner

Moderator
Moderator
Jun 8, 2014
360
211
113
Could you make this semi-random? If you let everyone set whatever they want in the wallet from 2-8, almost all people will either select 2 for speed, or 8 for more stealth, and nothing in between. This would give a fairly decent assumption an attacker might be able to find a way to leverage when trying to trace coins. Instead offering "about 4-6" which would be actually done as pick a random number of what the user chose plus or minus 2 cycles would destroy that assumption.
This is a very good point. Let the user select from a set of ranges. For example -- Basic anonymity: 2-4, moderate anonymity: 3-6, and high anonymity: 6-8.

Then the client decides the mixing depth in a random fashion based on the selected range.
 

Stealth923

Well-known Member
Foundation Member
Mar 9, 2014
347
383
233
Cannot wait till RC4 is an understatement

Evan + Dev team you are amazing - thank you for changing the crypto landscape forever.
 

TanteStefana

Grizzled Member
Foundation Member
Mar 9, 2014
2,861
1,854
1,283
What happens with change. You can't predict how much will be needed for a future payment, so I have to guess you'll send out more coins than needed and get change back? Will this be yet another address? Or how does that work please?
 
S

snogcel

Guest
Very impressive!! Can't wait to watch this all unfold over the coming weeks. Really a groundbreaking approach and did not see this approach coming at all.

**I hate to be that guy - but there is a typo in the flowchart, on the upper left: "anonymizatoin" rather than "anonymization". :)
 

TanteStefana

Grizzled Member
Foundation Member
Mar 9, 2014
2,861
1,854
1,283
So, will no one address ever contain more than the largest possible denominated amount? And the client just groups them together appropriately for transactions, which are redenominated at the other end? Because that renders the whole blockchain entropic sludge and makes timing analysis impossible...
How is a timing analysis done? Does this make it easier to double spend without being caught? This might be important to bring up to Evan (in case he doesn't check here again)

I'm also wondering how much info this adds to the blockchain. Are all these transactions going to cause bloat?

I'm also still wondering how the change is handled?

I hope Evan heard Kristov's suggestion on using powers of 2 to denominate :)