Topic: [ANN][DASH] Dash (dash.org) | First Self-Funding Self-Governing Crypto Currency - page 6170. (Read 9723776 times)

I think the answer is in making similar-sized payments (denomination of XX DRK) + using a time delay for batching multiple transactions together.

A third party will see accounts being reduced and increased by similar sizes. For example 100 people will be losing 10 DRKs and 100 people will be gaining 10 DRKs. So you don't really know who sent to who.

That's kind of condescending. You could have just said, "an attacker can query the blockchain rather than constantly monitoring balances", and then answered his question. I thought it was a good question -- how does darksend protect against a timing analysis?

Because it doesn't know who had them in the first place. It doesn't know if it's the same person sending to self.

Darksend moves in blocks of fixed size and provides change back on new addresses.

The blockchain keeps track of all of that anyway, why does a person have to be NSA? It's all in the blockchain...  Why monitor? I don't get it. I think you just have a fundamental lack of understanding in how any crypto coin works. I'm not even sure where to start in trying to help you understand. Not an insult... You just don't have enough basic knowledge to have this conversation.

It then compares the changes that occurred in those addresses in the last 2.5min [from its previous check] and knows exactly who transferred coins to whom.

As far as the network is concerned, wallets do not exist, only addresses.  Your wallet just holds all of your addresses and the private keys associated with them.

Back to your original question about timing analysis, look at the bottom figure on page 3 of the whitepaper.  Each user will be placing the same # of coins into the pool (100 for example) - they will also provide a "spare change" address - coins that they don't want to spend but will come back to them.  This is a NEW address that has not been associated with them up to this point.

So lets say 3 people each put in 100 coins

A -> 100 sending 2 coins to D
B -> 100 sending 24 coins to E
C -> 100 sending 56 coins to F

The outputs will be

2 coins to D
98 coins to G
24 coins to E
76 coins to H
56 coins to F
46 coins to I

Now from this we can determine that the current holder of address G sent two coins to D, but it's impossible to determine whether G belongs to the same person as A, B, or C.

A new problem arises though, in that the coins are now sitting on address G, and it can be determined that the holder of those coins sent 2 coins to address D.  There would need to be another level of mixing to ensure that those 98 coins are washed another time - maybe Evan can clarify whether this mixing step happens or if I am misunderstanding something.

The risk is if address G sends money to something like coinbase (or some other site that has your personal info) -> that would expose them as the sender of 2 coins to address D.

Evan can you clarify?