Hi Evan,
I think it is a good solution, but it has a couple small drawbacks - I want to make a couple additional proposals to address these issues:
Here are the drawbacks:
1) If John wants to darksend his whole balance of 102 he is granted little anonymity unless addtitional people step up and volunteer inputs of 102 coins. A mechanism to solicit the nodes participating in the pool to submit additional 102 coin inputs might need to be added. Alternatively (or in addition), nodes could be sent CHANGE of 102 coins to one of their change addresses. (this idea of sending known receive amounts to various change addresses might be useful in other situtations as well - I will try to think about this a bit more)
I suppose it is possible (in theory) that John could be inputting 102 coins into the pool and sending less, while someone else is inputting say 104 coins, sending 102 and receiving 2 back as change. I still think this is a problem though because
extremely strong inferences could be drawn pointing to John as the sender of 102 coins.
2) The problem of large spends exposing the sender is still an issue, denominated change will help create some fog, but VERY strong inferences of who sent what to whom could still be drawn if a "full change block" is spent in a single large spend, for example if Joe sends that 80DRK change block above to coinbase, it could be strongly inferred that he was the sender of 73 coins to mary, and now the feds have his personal info (coinbase). Although this doesn't prove that Joe sent mary 73 coins, it might be enough evidence to grant a warrant to search Joe's residence. So I would like to propose a strong countermeasure that will largely solve this problem.
First, in order to prevent "full change blocks" from giving away the sender, I think you should try to build in some logic that tries (if possible) to break these large change blocks up when making subsequent spends. The key here is that you would want to try to break up these denominated "change blocks" into smaller chunks that
might match one of the other "change chunks" from that pool.
For example:
- John adds 102DRK to the pool, sends 101DRK to Lisa and receives back 1DRK as change addresses E=1DRK
- Joe adds 153DRK to the pool, sends 73DRK to Mary and receives back 80DRK as change addresses F=50DRK, G=10DRK,H=10DRK,I=5DRK,J=5DRK
-Suzy adds 240DRK to the pool, sends 100DRK to Jane and receives back 140DRK on change addresses K=50DRK, L=50DRK, M=10DRK, N=10DRK, O=10DRK, P=5DRK, Q=5DRK
Later Suzy wants to darksend a different person "Jack" 104 coins
She sends Jack 80 coins (composed of addresses L=50DRK, M=10DRK, N=10DRK, P=5DRK, Q=5DRK) + 24 coins from her wallet that did NOT participate in the above pool.
This would give the appearance of outing Suzy as the person who sent 73DRK to Mary and received 80 back as change. But as you can see it was actually JOE that made this tranasction! Mary is faking it!
Of course we wouldn't want to tell suzy's wallet to try to make a chunk of 80 because then suzy would know that Joe sent 73 coins to mary, we want suzy's wallet to figure out all of the possible combinations, then just send one random one.
So:
Suzy's wallet would try to spoof "possible change blocks"of:
102-1 = 1 <- an actual change block!
102-73= 29
102-100 = 2
153-101= 52
153-73 = 80<- an actual change block!
153-100= 53
240-101=139
240-73=167
240-100=140<- an actual change block!
As you can see some of these combos actually match real change blocks, others do not. Suzy doesn't know which do and which do not, she tries to assemble whichever change block she can from the change that she has.
The beauty of this is that suzy is not privy to any information that is NOT already on the blockchain, but she DOES have enough info to spoof ALL of the possible "change blocks"
I think this does a lot to ablate the "dirty change blocks" problem.
In the end I think the "Dark Receive" address idea (addresses composed of many sub-addresses) is a superior solution, but the above does a hell of a lot to ablate the problems that we have been talking about.
Let me know what you think. Hopefully I didn't mess up the logic in my head
In spite of my non-formal-tech background, I like your solution VERY MUCH.
However, I couldn't figure out one aspect in the flow.
Can you ELI5 how the sender's wallet can look into past transactions on the blockchain, and determine 'possible change blocks'.
