In regards to the pools of 10, 100 and 1000DRK, I believe the best solution is to get rid of the pools altogether and just require than the inputs to the pool be larger than the outputs.
For example:
- John adds 102DRK to the pool, sends 101DRK to Lisa and receives back 1DRK as change.
- Joe adds 153DRK to the pool, sends 73DRK to Mary and receives back 80DRK as change.
Change will still be denominated, so the 80 DRK would come back as 50,20 and 10DRK.
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
So say you used the coins sitting idle in the masternodes to match the inputs made and then when its time to make change and send the coins back to the masternode, you denominate both so that they match. John sends 102 DRK of which 100 goes to Mary; denominated of course. The masternode handling the transaction matches the 102 DRK input. John is due 2 DRK in change and the masternode wallet is due 102 DRK change. If the change denominations would match somehow; 2 DRK back to John, 100 DRK + 2 DRK back to the masternode; who sent who what. Bonus: 100 DRK change denomination back to the masternode also matches the 100 DRK output to Mary.
