Hey jack-ass! The guy posting above you? I was there when he TOLD Evan he was barking up the wrong tree.
Hey AnonyMint, welcome back. Your questions have been some of the best that we’ve 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 I’m sending)
2.) ACCEPTING OUTPUTS (outputs are who I’m 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 it’s one of your users but you don’t 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 you’re talking about:
Design A: Users provide inputs and collateral, then later will provide outputs. The master node must know which user didn’t provide the outputs to be able to charge him. If we use blind signing we can’t 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 didn’t sign.
I’ve chosen to use design B (users will add inputs and outputs at the same time) because it’s the only design that can’t be attacked in the way you’re 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
might want to listen to him.
