CoinJoin: Bitcoin privacy for the real world - page 20.

Crowex

member

Activity: 111

Merit: 10

Quote from: maaku on January 18, 2014, 09:06:00 PM

Quote

maaku's solution does not seem to work as it requires communication between the participants

No, the server can include this signed information in the message it sends to participants.

The solution is simple: each participants sign what outputs they want to see on the chain.

Are they signing a set of all outputs randomly mixed up? This wouldn't solve the problem.
Or are they signing their individual outputs? There is no anonymity now.

Quote

No participant signs the transaction unless they receive invoices separately signed by every single input which cumulatively add up to the transaction.

I can't see how this helps to solve the problem.

Quote

Cryptographic blinding is used to make sure that users can specify hidden outputs not subject to this check.

I'm not really sure what you're saying here. If you're talking about a blind signature protocol can you be more specific about how it can work in this case.

Quote

the example was a donation address, it would be difficult to imagine this changing for each donation

Quote

Google "bitcoin stealth address"

I didn't say that it wasn't possible to change the address for each donation. This could be done without stealth addresses. I just think that most people asking for donations will just put up an address and ask people to send coins to it.

kjj

legendary

Activity: 1302

Merit: 1026

Rather than adding more steps and layers to the system, I propose ignoring the chance of the joiner operator skimming merges.

If it bothers anyone, they can send their donation to a new address in their own wallet, then send that to the donation address in the normal way. This operation could even be scripted. (Your wallet searches google for your payment address. If there are no results, it is more or less impossible for another coin join user to be sending to that address. If there are results for it outside of the explorer sites, it automatically switches into 2-stage mode.)

maaku

legendary

Activity: 905

Merit: 1012

Quote

maaku's solution does not seem to work as it requires communication between the participants

No, the server can include this signed information in the message it sends to participants.

The solution is simple: each participants sign what outputs they want to see on the chain. No participant signs the transaction unless they receive invoices separately signed by every single input which cumulatively add up to the transaction. Cryptographic blinding is used to make sure that users can specify hidden outputs not subject to this check.

Quote

the example was a donation address, it would be difficult to imagine this changing for each donation

Google "bitcoin stealth address"

Crowex

member

Activity: 111

Merit: 10

Quote from: prezbo on January 18, 2014, 05:07:48 PM

Quote from: Murphant on January 18, 2014, 05:05:53 PM

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.

That is true, but the protocol shouldn't limit users in such a way. But you are correct, in a world with perfect information this is not a problem.

the example was a donation address, it would be difficult to imagine this changing for each donation

Quote

As I said I don't really understand how maaku solves this problem

nor me, his approach seems to be more de-centralised, but I can't quite grasp how he can guarantee that this problem can't occur

piotr_n

legendary

Activity: 2053

Merit: 1356

aka tonikt

Of course you cannot trust any service more than to provide you the entire transaction you get to sign - not only its hash.
Then you make sure that at least one of its outputs satisfies your input.
And then you get to know more about a possible connections between the txs inputs and output. Which inforamtion, who knows, maybe you'll be able to sell one day in a future so you may want to keep it

Its really not as cool as you think, unless you build a huge and anonymous infrastrtuctere for it.
Who's going to do it? Jesus is dead for all I know. We're talking about tor at least, otherwise it dont make no sense. And what: SR style, or p2p? Is there even a p2p in tor? Who's going to pay for it to profit from it? Or it won't happen...

Anyway, understand that the weakest link here is the ip that sends your money to the network. Sharing the tx with your pals or strangers picked by some system to increase privacy - give me a break

prezbo

sr. member

Activity: 430

Merit: 250

Quote from: Murphant on January 18, 2014, 05:05:53 PM

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.

That is true, but the protocol shouldn't limit users in such a way. But you are correct, in a world with perfect information this is not a problem.

Murphant

jr. member

Activity: 38

Merit: 3

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

Quote from: Murphant on January 18, 2014, 04: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.

prezbo

sr. member

Activity: 430

Merit: 250

Quote from: Murphant on January 18, 2014, 04: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. Legit coinjoin transaction would look like [A, B] -> [(S,1), (S,1)], but here the service could change it to [A, B] -> [(S,1), (X,1)], where X is service's address. Since Alice isn't aware of Bob's transaction and vice versa none would suspect that 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.

Murphant

jr. member

Activity: 38

Merit: 3

The way I understand it, the problem can be phrased in the following way.

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.

I believe that maaku's solution would work as long as the join requests are signed and kept by each party. One downside of this is that it might reduce the anonymity of the system since each user can later prove the other user's intentions to a third party.

Quote from: maaku on January 18, 2014, 12:55:31 PM

Reference the original offers in the join request, so that anyone considering signing the transaction can make sure that not just the correct outputs, but also the correct number of outputs are present. My Python implementation does this.

Another, simpler solution would be to make sure to never send funds to a public address in a CoinJoin transaction and for sellers to always use fresh receiving addresses.

prezbo

sr. member

Activity: 430

Merit: 250

Quote from: maaku on January 18, 2014, 01:08:42 PM

https://github.com/maaku/coinjoin

thanks!

edit: hoped there would be a protocol draft of some sorts, unfortunately don't have the time to work it out how it works from the code.

maaku

legendary

Activity: 905

Merit: 1012

https://github.com/maaku/coinjoin

prezbo

sr. member

Activity: 430

Merit: 250

Quote from: maaku on January 18, 2014, 12:55:31 PM

Quote from: Qoheleth on January 18, 2014, 04:44:04 AM

But how would you know? If only one Wikileaks donation makes it into the final txn, wouldn't each participant just assume it was their donation? How could they tell otherwise?

Reference the original offers in the join request, so that anyone considering signing the transaction can make sure that not just the correct outputs, but also the correct number of outputs are present. My Python implementation does this.

Can you link to your implementation, please? I'd like to have a look because I don't fully understand.

maaku

legendary

Activity: 905

Merit: 1012

Quote from: Qoheleth on January 18, 2014, 04:44:04 AM

But how would you know? If only one Wikileaks donation makes it into the final txn, wouldn't each participant just assume it was their donation? How could they tell otherwise?

Reference the original offers in the join request, so that anyone considering signing the transaction can make sure that not just the correct outputs, but also the correct number of outputs are present. My Python implementation does this.

Crowex

member

Activity: 111

Merit: 10

I meant the users do choose their own identifiers, the dummy transaction is created with these.
I just thought the identifiers might be able mark out the transaction as a coin join transaction if they were part of the transaction which might not be desirable.
I'm not really familiar with OP_DROP, maybe it achieves the same thing.

prezbo

sr. member

Activity: 430

Merit: 250

Quote from: Crowex on January 18, 2014, 11:36:02 AM

I hope I've understood the problem correctly.

I just meant that if you didn't want to include the identifiers in the actual multi signature coin join transaction then everybody would sign a dummy transaction.
This dummy transaction would contain everybody's outputs with identifier so that they know that the controller hasn't redirected any duplicate payments to himself. The dummy transaction would not be broadcastable or valid but everybody would use it to agree to the tx_outs and tx_ins by everybody signing it.
Once they had agreed by all signing the controller could create a valid transaction with the same inputs and outputs but without identifiers and then they would all sign this.

..or maybe I've misunderstood something?

I see. The problem is if the service chooses the identifiers they would just send the two users different dummy transactions to sign, with such identifiers both would be convinced the donation is actually their own, so I think it has to be users who choose identifiers beforehand. I think just adding (random) id's to the outputs that are dropped off the stack using OP_DROP wold work though - so for each output I choose random number, add it (as OP_DROP), send inputs and outputs to the service, when I get the transaction back I check if the outputs match with what I sent, if they do I sign the transaction.

Crowex

member

Activity: 111

Merit: 10

I hope I've understood the problem correctly.

I just meant that if you didn't want to include the identifiers in the actual multi signature coin join transaction then everybody would sign a dummy transaction.
This dummy transaction would contain everybody's outputs with identifier so that they know that the controller hasn't redirected any duplicate payments to himself. The dummy transaction would not be broadcastable or valid but everybody would use it to agree to the tx_outs and tx_ins by everybody signing it.
Once they had agreed by all signing the controller could create a valid transaction with the same inputs and outputs but without identifiers and then they would all sign this.

..or maybe I've misunderstood something?

prezbo

sr. member

Activity: 430

Merit: 250

Quote from: Crowex on January 18, 2014, 10:25:56 AM

It's a bit more convoluted but if everybody signs a dummy transaction with identifiers for the outputs then you could just remove the identifiers and everybody signs again if the transaction is exactly the same in terms of tx_out and tx_in.

I don't quite understand, what exactly do you mean?

Crowex

member

Activity: 111

Merit: 10

It's a bit more convoluted but if everybody signs a dummy transaction with identifiers for the outputs then you could just remove the identifiers and everybody signs again if the transaction is exactly the same in terms of tx_out and tx_in.

prezbo

sr. member

Activity: 430

Merit: 250

Quote from: Cryddit on January 18, 2014, 05:07:35 AM

If you and someone else both send money to Wikileaks, you both sign your transactions. The transactions, even for identical amounts, are not identical. For one thing they will name different unspent txouts to spend; for another they'll have different timestamps. For a third thing they will specify different addresses for "change" to come back to. All of these things will be combined in a hash function to give your transaction a transaction ID which is unique.

I suggest you carefully read the first post of this thread. We aren't discussing the usual bitcoin transactions here but coinjoin specifics.

Quote from: themgp on January 18, 2014, 05:09:01 AM

When Participant A and Participant B create the Transaction from the information from Controller C, they will only create and sign a transaction where Controller C indicates the correct output amount, address, and identifier. Participant A will only sign a transaction that has an output with identifier X and Participant B will only sign a transaction with identifier Y.

I guess one could include an indentifier in the tx_out using OP_DROP, that might work.

prezbo

sr. member

Activity: 430

Merit: 250

Quote from: Qoheleth on January 18, 2014, 04:44:04 AM

Quote from: maaku on January 18, 2014, 04:31:28 AM

You would never sign it.

But how would you know? If only one Wikileaks donation makes it into the final txn, wouldn't each participant just assume it was their donation? How could they tell otherwise?

My reasoning exactly.

Topic: CoinJoin: Bitcoin privacy for the real world - page 20. (Read 294649 times)