CoinJoin: Bitcoin privacy for the real world

[maaku]

Have any Bitcoin core developers said anything about adding CoinJoin into the protocol?

Bump for this thread because it is important for Bitcoin

You don't need to add it to the protocol, CoinJoin operates just fine at a strictly higher level. But I suppose you mean adding support to the reference wallet for CoinJoin transactions? I would not be surprised to see that happen, but someone needs to write the code first.

[gmaxwell]

Have any Bitcoin core developers said anything about adding CoinJoin into the protocol?
Bump for this thread because it is important for Bitcoin

It doesn't need to be added to the protocol, thats part of the point.

If instead you mean the integrated Bitcoin-qt wallet, Wumpus and I have both commented that we'd like to see it there. I'd like to see more external implementation done first.  Inside the wallet is good for getting users, but it's not good for protocol R&D.

[BurtW]

Bitcoin has been very good to me over these last few years.  I would hate to see it killed by these various validation proposals.

As of this posting the bounty pool at: https://blockchain.info/address/3M8XGFBKwkf7miBzpkU3x2DoWwAVrD1mhk contains a bit over 31 BTC.

In order to stand behind my signature below and support this effort I offer the following matching donation (inspired by Theymos):

I will donate 5 BTC as soon as the total in the fund goes over 36 BTC.

Done.

[solex]

Fantastic BurtW!

[BurtW]

$34K should get this done (I hope).

[Voodah]

Is Blockchain.info's Shared Send part of their closed source stuff?

Is it implemented along these guidelines?

[ShadowOfHarbringer]

Is Blockchain.info's Shared Send part of their closed source stuff?

Is it implemented along these guidelines?

I join the question.

[BurtW]

As far as I can tell from the posts up thread the blockchain.info Shared Send system is a basic implementation of the centralized version of the proposal.

You can use it without a blockchain.info wallet, and read all about it here:  

https://blockchain.info/wallet/send-shared

From the FAQ on that page:

How does it work?
Coins send with shared send will be matched up with another user. When a match is found your coins will be swapped breaking the transaction chain from your own wallet. Coins will be swapped with multiple users making the chain even harder to follow.

I found this very interesting (also from the same FAQ):

How can you guarantee that the transaction chain will be broken?
There is no guess work involved, each shared transaction analyzes up to 50,000 outputs or 250 levels deep in the blockchain to ensure the coins sent to the destination address are 100% untainted with the original coins.

The source code for taint analysis calculations can be found on the Blockchain Github Project

[Rassah]

As far as I can tell from the posts up thread the blockchain.info Shared Send system is a basic implementation of the centralized version of the proposal.

It's actually a plain mixing service that was implemented a long time ago, way before CoinJoin was proposed. They have a separate CoinJoin style transaction option that does use CoinJoin, but as far as I know, requires you to use a blockchain.info wallet, since CoinJoin has special nonstandard transactions. Fees are different, too, with 0.5% for Send-Shared, and a standard 0.0001BTC transaction fee for CoinJoin (with multiple mixes suggested, each one costing an extra 0.0001BTC)

[BurtW]

As far as I can tell from the posts up thread the blockchain.info Shared Send system is a basic implementation of the centralized version of the proposal.

It's actually a plain mixing service that was implemented a long time ago, way before CoinJoin was proposed. They have a separate CoinJoin style transaction option that does use CoinJoin, but as far as I know, requires you to use a blockchain.info wallet, since CoinJoin has special nonstandard transactions. Fees are different, too, with 0.5% for Send-Shared, and a standard 0.0001BTC transaction fee for CoinJoin (with multiple mixes suggested, each one costing an extra 0.0001BTC)

Thanks for the info.  I did not realize the two were different.

[andytoshi]

since CoinJoin has special nonstandard transactions.

Coinjoin does not need nonstandard transactions, nor should it use them -- it is NP-hard to determine whether an ordinary bitcoin transaction might be a coinjoin.

[Voodah]

As far as I can tell from the posts up thread the blockchain.info Shared Send system is a basic implementation of the centralized version of the proposal.

It's actually a plain mixing service that was implemented a long time ago, way before CoinJoin was proposed. They have a separate CoinJoin style transaction option that does use CoinJoin, but as far as I know, requires you to use a blockchain.info wallet, since CoinJoin has special nonstandard transactions. Fees are different, too, with 0.5% for Send-Shared, and a standard 0.0001BTC transaction fee for CoinJoin (with multiple mixes suggested, each one costing an extra 0.0001BTC)

Interesting, and yes, fees.

Their Shared Coin has a per repetition fee as well.

[Rassah]

Their Shared Coin has a per repetition fee as well.

The 0.5% fee is the fee they charge for the service. The Shared Coin fee is a transaction fee that goes to the miners.

[prezbo]

When there are two outputs to the same address with the same value (for example, two people want to donate 1 btc each to wikileaks), what prevents the service owner from swapping one of them with their own address?

[maaku]

You would never sign it.

[Qoheleth]

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?

[Cryddit]

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]

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]

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]

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.