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

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.

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.

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.

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.

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.

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?

You would never sign it.

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?

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.

Interesting, and yes, fees.

Their Shared Coin has a per repetition fee as well.

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.

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

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)

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:


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

I join the question.

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

Is it implemented along these guidelines?

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

Fantastic BurtW!

Done.

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.