Quote from: prezbo on January 18, 2014, 09:58:48 PM

Quote from: Murphant on January 18, 2014, 09:39:36 PM

Suppose that both Alice (address A) and Mallory (address M) want to buy an item from seller Steve. Alice and Mallory create a CoinJoin transaction (A,M) -> (S,M') where M' is another address controlled by Mallory. Alice signs the transaction as she sees that the correct amount is sent to Steve and expects to receive her service. However, Mallory may also later claim that he sent the money to Steve and that he should receive the service. From Steve's point of view, both claims are equally valid.

This is not exactly what I meant.

Alice uses input A and sends 1 btc to address S. Bob uses input B and sends 1 btc to address S. Correct coinjoin transaction would look like [A, B] -> [(S,1), (S,1)], but here service could change it to [A, B] -> [(S,1), (X,1)], where X is services' address. Since Alice isn't aware of Bob's transaction and vice versa none would suspect the (S,1) output is not theirs, thus signing the transaction. As I said I don't really understand how maaku solves this problem. As I see it the only way to solve it is for users to provide some kind of a nonce with the outputs that can later be checked.

I was imagining more of a decentralized CoinJoin where people got together to create the transaction instead of asking a service to do it, but both situations are similar. In the centralized case, maaku's solution does not seem to work as it requires communication between the participants. However, sellers not reusing addresses that receive payments does solve the problem even in the centralized case as Alice and Bob cannot simultaneously think that they are paying Steve.