I spent a fair amount of time thinking about the discussion with dime, humanitee, luigi1111, camosoul and others yesterday about the anonymity of Darksend. I suspected that the logic behind darksend as currently implemented was not sound, and I thought it would be best to determine how exactly darksend was working, and do an in-depth analysis of a mixing cycle and the transactions that follow mixing.
...
Best,
Sim
...
Best,
Sim
Wow! This is great. About 400+ pages ago I talked about having a different kind of pool for change outputs only. Put in all of your change outputs and you'll get new fresh clean inputs of 10DRK. The client could automatically do this after each darksend, which would also get you new inputs for the next round.
I'm currently embedded in patching stratum and p2pool to support the masternode payments, which is why I haven't been around. It takes a lot of work to make something so different from anything else out there, dare I say, revolutionary?
On second thought, I'm not sure this solves the problem. My understanding is that you want to accumulate the dirty change in the wallet until it breaches a certain amount (say 10 for example), then it is washed in a "change only" wash with a bunch of "10" transactions. The problem I see is that even the clean coins could be linked to the original transaction. Just to explain:
John darksends 2 coins from A to C, gets 8 back as change on address X
a few days later..
John darksends 8 coins from B to D, gets 2 back as change on address Y
Y+X are submitted to the change mixing pool (10 coins), and come out "clean" at address Z.
The problem is that the coins at address Z are not clean really, they are "suspect", they could have possibly participated in any darksends that generated the dirty coins that composed the "change washing" pool.
Now when Johns wants to spend coins from A, B, and Z in the same transaction.
So if John wants to send coins from A+B+Z in one transaction, the fact that Z participated in a pool that contained X and Y is enough to expose A and B as the original participants in the darksend transaction.
Really it leaves us at the same position that we were at previously after the original darksends.
I hope that made sense.
I came up with a way better solution to this issue than my previous idea. Plus it's already supported by DarkSend, I'll just enforce it in RC3
John darksends 2.5 coins from A to C, gets 7.5 back as change on address X, Y, V, Z (X = 5DRK, Y = 1DRK, V = 1DRK, Z=0.5DRK )
Joe darksends 3 coins from E to G, gets 7 back as change on address W, K, J (W = 5DRK, K = 1DRK, J = 1DRK)
Suzie darksends 3.5 coins from K to Q, gets 6.5 back as change on address F, G, H (F = 5DRK, G = 1DRK, H = 0.5DRK)
Change is denominated into units of 5, 1, 0.5, 0.25, 0.1, 0.05, and 0.01 DRK. I'll introduce the precision limitation back again of 0.01DRK. So if you get 7.5 DRK of change back, you'll end up with 5DRK+1DRK+1DRK+0.5DRK.
You could still possible do taint analysis on denominations only used once, but this would be solved with multiple rounds in DarkSend.
