CoinJoin: Bitcoin privacy for the real world

[kjj]

1. All parties who want to coinjoin create a raw transaction using createrawtransaction. They submit these to one individual, who enters them into CoinJoiner by running

./coinjoin-merge-unsigned

Then just copy/paste the transactions in, one on each line, followed by a blank line. The output will be an unsigned merged transaction.

Interesting approach.  This has some very nice advantages.  For example, we could add a flag to sendtoaddress that makes it return the unsigned tx hex.  Thus we take advantage of the coin selector built into the node, etc.

[dserrano5]

CoinJoin needs to be nicely implemented in Bitcoin-Qt before any of these ridiculous blacklist proposals take off. So for the next 30 days, I will match donations to the CoinJoin bounty fund (3M8XGFBKwkf7miBzpkU3x2DoWwAVrD1mhk), up to a maximum of 5 BTC.

Way to go!

I'm upping my offer from 0.50 to 0.75 but please tell Pieter to sign his pubkey in the second message of this thread.

Ah, it took some time but he has finally signed it .

[wumpus]

Interesting approach.  This has some very nice advantages.  For example, we could add a flag to sendtoaddress that makes it return the unsigned tx hex.  Thus we take advantage of the coin selector built into the node, etc.

It'd also need to mark the inputs as spent so that further transactions don't double-spend.
This could be done using `lockunspent` but these are not saved when bitcoind is restarted.

[andytoshi]

Interesting approach.  This has some very nice advantages.  For example, we could add a flag to sendtoaddress that makes it return the unsigned tx hex.  Thus we take advantage of the coin selector built into the node, etc.

It'd also need to mark the inputs as spent so that further transactions don't double-spend.
This could be done using `lockunspent` but these are not saved when bitcoind is restarted.

If anyone knows how to make JSON-RPC calls through Rust (or C), I'd be able to (a) do my own 'sendtoaddress' equivalent, and (b) check for double-spends, excessive fees, negative fees, etc, and flag these as errors.

Right now I only check things intrinsic to the transactions -- for merge-unsigned, I ensure there are no duplicate inputs; for merge-signed, I ensure that all transactions are identical modulo scriptSigs.

It's not terribly important to do lockunspent -- if somebody double-spends, the coinjoin will be invalid. Presumably they wanted to do the coinjoin, so they've just screwed themselves. So any double-spend blocking is purely a usability feature.

[genjix]

https://medium.com/p/7f95a386692f

last paragraph

[Rassah]

Hey, um, stupid question, and I'm just too drowsy to wrap my head around it, but if I use CounJoin on blockchain.info, where I have one input and one output, and sent 5 BTC through, with 5 BTC coming out on the other end, isn't it still fairly easy to track my 5 BTC,simply because that's the amount that went in and came out?

[dserrano5]

if I use CounJoin on blockchain.info, where I have one input and one output

If you only have one input, you're not joining any coins. The point is mixing unspent outputs from several people/addresses so external observers can't figure out where each output has gone.

[Rassah]

if I use CounJoin on blockchain.info, where I have one input and one output

If you only have one input, you're not joining any coins. The point is mixing unspent outputs from several people/addresses so external observers can't figure out where each output has gone.

I understand, but if we have 3 people, I put in 5BTC, someone else puts in 2BTC, and the third person puts in 3.5BTC, the coins all get broken up into random amounts and go through two stage mix, in the end, we still have 5BTC, 2BTC, and 3.5BTC, just in new addresses. Isn't that fairly easy to track? I know I'm missing something... What is it?

[Carlton Banks]

if I use CounJoin on blockchain.info, where I have one input and one output

If you only have one input, you're not joining any coins. The point is mixing unspent outputs from several people/addresses so external observers can't figure out where each output has gone.

I understand, but if we have 3 people, I put in 5BTC, someone else puts in 2BTC, and the third person puts in 3.5BTC, the coins all get broken up into random amounts and go through two stage mix, in the end, we still have 5BTC, 2BTC, and 3.5BTC, just in new addresses. Isn't that fairly easy to track? I know I'm missing something... What is it?

The possibility that you could get 5 BTC sent to more than one address. Also, you could use the system to pay people too. So, you get your 5 BTC sent to 4 adddresess that belong to you, and the small fraction you are paying to someone else goes to their address. To the outside observer, do all 5 addresses belong to the original holder? Do they all belong to someone receiving a total of 5 BTC from the original holder? Or somewhere inbetween? Impossible to tell, and so analysing the transaction leaves you with lots of questions and no answers.

[maaku]

I understand, but if we have 3 people, I put in 5BTC, someone else puts in 2BTC, and the third person puts in 3.5BTC, the coins all get broken up into random amounts and go through two stage mix, in the end, we still have 5BTC, 2BTC, and 3.5BTC, just in new addresses. Isn't that fairly easy to track? I know I'm missing something... What is it?

You don't re-assemble them into the original amounts. Why would you want to do that?

[Rassah]

I understand, but if we have 3 people, I put in 5BTC, someone else puts in 2BTC, and the third person puts in 3.5BTC, the coins all get broken up into random amounts and go through two stage mix, in the end, we still have 5BTC, 2BTC, and 3.5BTC, just in new addresses. Isn't that fairly easy to track? I know I'm missing something... What is it?

You don't re-assemble them into the original amounts. Why would you want to do that?

That's what Blockchain.info does. You send from a single address, you give it an amount and a destination address, and it goes through 2+ CoinJoin steps, split up into random amounts from your source address, then after all the steps gets recombined into the amount you sent (minus transaction fee) into your destination address. Basically, it's as if your amount is exploded into random chunks, and then recombined into the same amount. Unless multiple steps involve multiple different coinjoiners, and much of what you get isn't tied to your own bitcoin at all, I'm not sure it's secure.

[maaku]

Then that's what bc.i does. That's not the protocol described in this thread.

[Carlton Banks]

So yes, blockchain.info has an implementation of CoinJoin, that doesn't do anything much useful. Unless it's configurable to do the job differently, of course.

[piuk]

That's what Blockchain.info does. You send from a single address, you give it an amount and a destination address, and it goes through 2+ CoinJoin steps, split up into random amounts from your source address, then after all the steps gets recombined into the amount you sent (minus transaction fee) into your destination address. Basically, it's as if your amount is exploded into random chunks, and then recombined into the same amount. Unless multiple steps involve multiple different coinjoiners, and much of what you get isn't tied to your own bitcoin at all, I'm not sure it's secure.

Assuming you use a single input of the exact size then it will be recombined into the same output value. But the client will deliberately select more inputs than necessary in order to make determining the input value more difficult. The server will also add multiple outputs of the same size as your inputs.

Even if you are restricting outputs to power of two sizes, as in the original coinjoin proposal, the same issue is still a problem. Address A sends 2 * 0.1 BTC + 1 * 1 BTC outputs then Address BTC receives 2 * 0.1 BTC + 1 * 1 BTC soon after it is easy to connect the dots.

Mixing in the background rather than on demand is probably the best way to solve this.

[justusranvier]

I don't see how CoinJoin can possibly ever be effective in a situation of address reuse.

Is Blockchain.info ever going to stop doing that?

[Rassah]

I don't see how CoinJoin can possibly ever be effective in a situation of address reuse.

Is Blockchain.info ever going to stop doing that?

I think they already have. Their default bitcoin transactions send change to new addresses, as does their CoinJoin.

I'm only using blockchain.info's coinjoin it to offload and split up my larger bitcoin purchases into cold storage. Hopefully it was sufficient enough for the last few deposits I made.

[justusranvier]

Their default bitcoin transactions send change to new addresses, as does their CoinJoin.

When did that happen? That's a major change that deserves a large announcement. Are they using BIP32 to derive the new addresses?

[TierNolan]

I understand, but if we have 3 people, I put in 5BTC, someone else puts in 2BTC, and the third person puts in 3.5BTC, the coins all get broken up into random amounts and go through two stage mix, in the end, we still have 5BTC, 2BTC, and 3.5BTC, just in new addresses. Isn't that fairly easy to track? I know I'm missing something... What is it?

You need to agree on a common amount.

Inputs (5, 2, 3.5)
Outputs
2
2
2
3 (your change)
1.5 (change for the 3.5 BTC guy)

You get one of the 2 BTC coins and your 3 BTC change coin.  Your software would need to remember that the 3 BTC change coin was not mixed, but the 2BTC one was.

In fact, you could split your 3 coin into two 1.5 BTC coins, so it would be slightly mixed.  You would get 2 of the 3 1.5 BTC outputs.

If there was only 2 into the mix, there would generally be two inputs and three outputs, so the guy who paid more gets (unmixed) change.

[phillipsjk]

I got into a argument with somebody on IRC in #bitcoin over the suitability of coinjoin transactions for annoymised verifiable e-voting. justanotheruser's argument was that he could always verify that his choice got a "vote". My argument was that since the voters don't share their votes with each other, it is possible to mis-allocate votes without detection (as long as you are not too greedy).

This has implications for "normal" coinjoin transactions as well:
If:

• There are more than two participants
• Two or more participants try to send coins to the same address without directly communicating with each other. (This includes trying to send mining fees)

Then:

• It is possible for a bad actor to misdirect some of those funds for their own purposes.
• For the attack to work,  the original output must have at least as much funds as any one participant sent.

This works because non-communicating participants can only ever check that their own outputs look correct. One way to mitigate this is to phase out address reuse: which has not yet happened in practice.

[gmaxwell]

Excellent point!

As you note one workaround is don't reuse addresses— always good advice and here it doesn't have to be "phased out" in general but just by participants— but it's always better to be secure even if software is used dumbly.

I can suggest a trivial protocol addition that solves this without making the CJ transactions distinguishable or degrading privacy, but my solutions have some overhead. I'm curious if anyone can come up with a better way of doing it that doesn't have the overhead.

The general idea is that the merging party can just make a list (blindly) mapping their inputs to outputs, give the list to all players, and commit to the list so that all players know they got the same list.

Here is how it works:

The merging party makes a list with an entry for each output in the transaction. The entries have a nonce provided by each user either when they provide their input (or submitted their blindsigned tokens if blind signed tokens are in use). When they ask the users to sign they give the users the list and the users check and see that they are the credited party for every output they think they should be. Because they are just nonces they don't deanonymize users.

But to prevent the merging party from giving a different list to each user they must commit to it. I have two way to accomplish that:

The first is that we could require that a particular index in the outputs pay to an address which commits to the list: The merging party computes a new public key as an existing pubkey plus the H(list)*G, like a pay to contract, and a previously designated output pays to the resulting address. Given the list and original public key, everyone can check that that output commits to the same list. (And if two different users are given different lists, their signatures will not be merge-able since they would have signed different outputs).

(This designed output could belong to the merger or players could volunteer to have their output address placed in the designated position and to instead receive their payment at a pay-to-commit address. This is a little lame though, because it requires that there be at least one player that will tolerate receiving coins at a non-deterministic key.)

The second way to commit that I've come up with is to add an additional round to the protocol where you make a dummy transaction modified so that it won't ever be valid, e.g. using the list hash as an addition vin. Everyone signs this transaction and then only once they've seen this commitment signed by all the inputs will they sign the real transaction.

Needing an extra communications round or a non-deterministic output is kinda weak. Can better be done?