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
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.
Now, we make a pool with X+X1+W+W1+S+S1.
X will always be less than 10DRK, there for we need another input to bring it to 10DRK total. This way no one can tell who is receiving which inputs, thus cleaning them in the inverse way DarkSend works.