Bitcoin Forum
May 24, 2017, 03:47:41 PM *
News: Latest stable version of Bitcoin Core: 0.14.1  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 [19] 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 »
  Print  
Author Topic: CoinJoin: Bitcoin privacy for the real world  (Read 250082 times)
Qoheleth
Legendary
*
Offline Offline

Activity: 882


Spurn wild goose chases. Seek that which endures.


View Profile WWW
January 18, 2014, 09:44:04 AM
 #361

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?

If there is something that will make Bitcoin succeed, it is growth of utility - greater quantity and variety of goods and services offered for BTC. If there is something that will make Bitcoin fail, it is the culture of naive fools and conmen, the former convinced that BTC is a magic box that will turn them into millionaires, and the latter arriving by the busload to devour them.
1495640861
Hero Member
*
Offline Offline

Posts: 1495640861

View Profile Personal Message (Offline)

Ignore
1495640861
Reply with quote  #2

1495640861
Report to moderator
1495640861
Hero Member
*
Offline Offline

Posts: 1495640861

View Profile Personal Message (Offline)

Ignore
1495640861
Reply with quote  #2

1495640861
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1495640861
Hero Member
*
Offline Offline

Posts: 1495640861

View Profile Personal Message (Offline)

Ignore
1495640861
Reply with quote  #2

1495640861
Report to moderator
1495640861
Hero Member
*
Offline Offline

Posts: 1495640861

View Profile Personal Message (Offline)

Ignore
1495640861
Reply with quote  #2

1495640861
Report to moderator
Cryddit
Legendary
*
Offline Offline

Activity: 840


View Profile
January 18, 2014, 10:07:35 AM
 #362

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?

It's the way the protocol works.  You don't just have your balance lowed and some other balance somewhere raised; inbetween there is something called a 'transaction' specifying very specific things  which must be digitally signed.  

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.

If someone violates the protocol and sends some other guy's transaction to you to sign, your bitcoin client will look at it and say, "hey, I don't even own this particular txout that this transaction is trying to spend, and this isn't my transaction ID, and the timestamp is wrong, and the change address isn't any I've ever given out.  Heck, the change address is not even one I have a key to spend.  WTF?"  

Meanwhile, if someone tries to use a transaction that you have signed, but with a changed payee, it won't match the signature you put on it because the changed payee would make it have a different transaction ID.  It would be a transaction that doesn't match its signature, and he couldn't put it on the blockchain because every other client would reject it.

themgp
Jr. Member
*
Offline Offline

Activity: 56


View Profile
January 18, 2014, 10:09:01 AM
 #363

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?

A possible solution:

Each participant must have all the information from all participants to create the transaction for themselves (i.e. know all inputs and outputs).  If both Participant A and Participant B create unique identifiers for their outputs (both for 1BTC, both to address 1HB5XMLmzFVj8ALj6mfBsbifRoD4miY36v, but each with a unique identifier, X and Y, respectively), then when the Controller C specifies the full inputs and outputs to create the Transaction, it will also need to indicate the unique output identifiers.

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.

Participant A and B then send the correct signatures to the Controller who recreates the same transaction from the inputs and outputs, but now with the signatures of Participant A and B.
themgp
Jr. Member
*
Offline Offline

Activity: 56


View Profile
January 18, 2014, 10:12:19 AM
 #364

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.

There is no way in a transaction to determine what is "my output" and "your output".  That is what makes coin join work, but also brings up the problem originally posed.
Cryddit
Legendary
*
Offline Offline

Activity: 840


View Profile
January 18, 2014, 10:28:06 AM
 #365

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.

There is no way in a transaction to determine what is "my output" and "your output".  That is what makes coin join work, but also brings up the problem originally posed.

Your output is the one that you have the key to spend.  What's hard about that?  There may be no way for anyone *else* to tell whose output is whose, but you are the guy who created that key pair, you still have the private key, and you know damn well whether a given output has the corresponding public key.  In a coinjoin everyone can identify their own outputs.  But they can't distinguish anyone else's, and no third-party observer can distinguish them at all.
themgp
Jr. Member
*
Offline Offline

Activity: 56


View Profile
January 18, 2014, 10:33:19 AM
 #366

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.

There is no way in a transaction to determine what is "my output" and "your output".  That is what makes coin join work, but also brings up the problem originally posed.

Your output is the one that you have the key to spend.  What's hard about that?  There may be no way for anyone *else* to tell whose output is whose, but you are the guy who created that key pair, you still have the private key, and you know damn well whether a given output has the corresponding public key.  In a coinjoin everyone can identify their own outputs.  But they can't distinguish anyone else's, and no third-party observer can distinguish them at all.

We might be talking about different outputs.  The original question was not about the TxOut that is an input to the CoinJoin transaction, but instead the outputs of the CoinJoin Transaction itself. AFAIK, there is no way for me to get Wikileak's private key. Smiley
prezbo
Sr. Member
****
Offline Offline

Activity: 430


View Profile
January 18, 2014, 10:49:56 AM
 #367

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.
prezbo
Sr. Member
****
Offline Offline

Activity: 430


View Profile
January 18, 2014, 11:59:26 AM
 #368

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.

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.
Crowex
Member
**
Offline Offline

Activity: 111


View Profile
January 18, 2014, 03:25:56 PM
 #369

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
****
Offline Offline

Activity: 430


View Profile
January 18, 2014, 04:16:34 PM
 #370

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
**
Offline Offline

Activity: 111


View Profile
January 18, 2014, 04:36:02 PM
 #371

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
****
Offline Offline

Activity: 430


View Profile
January 18, 2014, 04:58:32 PM
 #372

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 <rnd number> 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
**
Offline Offline

Activity: 111


View Profile
January 18, 2014, 05:07:10 PM
 #373

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.
maaku
Legendary
*
expert
Offline Offline

Activity: 905


View Profile
January 18, 2014, 05:55:31 PM
 #374

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.

I'm an independent developer working on bitcoin-core, making my living off community donations.
If you like my work, please consider donating yourself: 13snZ4ZyCzaL7358SmgvHGC9AxskqumNxP
prezbo
Sr. Member
****
Offline Offline

Activity: 430


View Profile
January 18, 2014, 06:03:21 PM
 #375

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
*
expert
Offline Offline

Activity: 905


View Profile
January 18, 2014, 06:08:42 PM
 #376

https://github.com/maaku/coinjoin

I'm an independent developer working on bitcoin-core, making my living off community donations.
If you like my work, please consider donating yourself: 13snZ4ZyCzaL7358SmgvHGC9AxskqumNxP
prezbo
Sr. Member
****
Offline Offline

Activity: 430


View Profile
January 18, 2014, 06:24:32 PM
 #377


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.
Murphant
Jr. Member
*
Offline Offline

Activity: 35


View Profile
January 18, 2014, 09:39:36 PM
 #378

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.

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
****
Offline Offline

Activity: 430


View Profile
January 18, 2014, 09:58:48 PM
 #379

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
*
Offline Offline

Activity: 35


View Profile
January 18, 2014, 10:05:53 PM
 #380

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.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 [19] 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!