Hey AnonyMint, welcome back. Your questions have been some of the best that weve gotten and really have helped the design of DarkSend, I really do appreciate your input.
CoinJoin can't work. Period. I had another debate in the CoinJoin thread a few weeks ago with gmaxwell and I won. Go read it for yourself.
The problem is you can't prevent someone from denial-of-service attacking by refusing to sign the second stage of the operation. They can block all DarkSends this way.
There is not any anonymity offered by DarkSend, because the shorts will simply attack it once the coin becomes valuable and DarkSends won't get processed. The system will jam. And the price will plummet.
Earlier in the development someone attacked DarkSend this way and broke it for a day or so. I ended up coming up with what I call collateral transactions. A collateral transaction is a transaction that is only sent to the master node and if broadcast will transfer money from the node in question to the master node.
The main problem is CoinJoin happens in 3 main stages:
1.) ACCEPTING INPUTS (inputs are the money Im sending)
2.) ACCEPTING OUTPUTS (outputs are who Im sending to)
3.) SIGN INPUTS (everyone signs their input separately then sends them)
In stage 2, what if someone fails to send their output?
In stage 3, what if someone fails to sign?
So with blind signing (footnote 1) when a user adds an output, you know its one of your users but you dont know which. So if a user fails to provide outputs, the whole session must restart and no one can be punished.
I've thought about multiple designs for DarkSend, many of which do have the issue youre talking about:
Design A: Users provide inputs and collateral, then later will provide outputs. The master node must know which user didnt provide the outputs to be able to charge him. If we use blind signing we cant charge the bad actor fees.
Design B: Users provide inputs, outputs and collateral at once. In this case the master node knows who is sending money to who, but later it can tell who didnt sign.
Ive chosen to use design B (users will add inputs and outputs at the same time) because its the only design that cant be attacked in the way youre saying.
//Accepting inputs
1. User A provides (Input, txCollateral, Output1, Output2)
2. User B provides (Input, txCollateral, Output1, Output2)
3. User C provides (Input, txCollateral, Output1, Output2)
//Signing
1. User A provides (Input, txCollateral)
2. User B fails to provide to sign
3. User C provides (Input, txCollateral)
//Fees
1. User B is charged
So to be clear, the master must know who is sending money to who. But ONLY the master node will need to know this. Beyond that the blockchain is still anonymous, and master nodes can be decentralized among the users of the network.
(1) More about blind signing:
http://ojs.academypublisher.com/index.php/jnw/article/viewFile/0508921928/2053