Okay, I want to fully understand this. Step By Step, is this how the DarkSend Protocol is actually working?
1. A 'Master Node' for the current round is algorithmically selected on a (pseudo) random basis based on a hash of information in the blockchain. (so everybody who does it selects the same master node).
2. People who want to participate in a coinmix send the 'Master Node' 0.1 Dark (deposit), a redemption address and a 'redemption code' per input.
3. The 'Master Node' collects information from the participants about how much they want in outputs and creates a transaction (with no inputs yet).
4. 'Master Node' collects signatures from all participants agreeing to the set of all outputs, and updates the transaction.
5. All participants break connection and connect to the network via a new set of peers, making it harder to associate inputs with outputs via network monitoring.
6. Participants communicate transaction inputs to the master node and the master node updates the transaction again.
7. Participants now provide signatures (over the whole transaction) to 'spend' inputs. If all inputs are now valid, the transaction is published.
8. Everybody breaks connection again, reconnecting via a new set of peers,
9. If all inputs are now valid as spends, the transaction is published and protocol goes to step 11.
10. The master node creates a new version of the transaction not including the unsigned inputs, and protocol goes to step 3.
11. For each spent input, participants may now send a message to the master node, giving a nonce which, together with the input spent, forms a preimage for their redemption token. The master node responds by sending them 0.1 Dark.
If that's right, then the master node can connect inputs and outputs. Also, the master node can just take everybody's (or anybody's) deposit and stop. If the master node is honest, then there is no evidence left outside the master node about which inputs go with which outputs. If the master node is dishonest, then he can later (after the anonymized coins are spent) make an a ransom demand offering to connect inputs with outputs unless he is paid.
Surely the master node shouldn't be trusted this much, so I must have it wrong. Can someone please correct me?
You have the general idea down, but how signing works is completely off.
1. A 'Master Node' for the current round is algorithmically selected on a (pseudo) random basis based on a hash of information in the blockchain -- Perfect
2. The second stage users deposit their inputs. It's just the info to prove they have the money at this point with the collateral tx. Inputs are checked for validity here by the memory pool. You're not allowed in unless your input/collateral is OK.
3. The third stage a user will deposit their outputs they'd like to pay.
4. The forth stage a user signs their input away to ALL outputs present. This includes checks to make sure the transaction pays the party they want. Each input can be signed away COMPLETELY independently of the rest.
5. Signatures are broadcasted and compiled by the master
6. The transaction is verified and broaded if valid.
7. Everybody breaks connection again, reconnecting via a new set of peers,
"For each spent input, participants may now send a message to the master node, giving a nonce which, together with the input spent, forms a preimage for their redemption token. The master node responds by sending them 0.1 Dark. "
The implementation doesn't require a redemption token, nonce or anything like this. I don't know where you got that from.
The collateral transaction is made out from you to the master node. It can only be cashed by the masternode (it requires the signature of the master node to cash) and it's only valid for a few minutes.
"If that's right, then the master node can connect inputs and outputs."
That's true, the master node must be able to tie them together to anonymize the transaction. It's the same problem as mixing services too, except in our cause we pick a random node from the network, so it's much safer.
"Also, the master node can just take everybody's (or anybody's) deposit and stop."
That's not true, when you sign the input, you're signing it away to the outputs in the merged transaction. If it looks correct, then you'll sign. There's no risk because it requires your signature.