CoinJoin: Bitcoin privacy for the real world

[maaku]

Yes, the facilitator gains no extra information about the transaction than is observable from the outside, if blind signing is used (see gmaxwell's posts at the beginning of this thread).

[1714142121]

1714142121

[1714142121]

1714142121

[1714142121]

1714142121

[Anon136]

thanks for clearing that up maaku.

*tangent warning* blind signatures are amazing. some people talk about how the future will be saved from tyranny through peaceful parenting. others through the political system. some through revolution. but my money is on the efforts of people like yourself and gmaxwell. idk if you ever stop to think about this, but just the hand full of you guys working on these sorts of technologies might be responsible for saving the entire human species from extinction or worse. i know that sounds dramatic but i really think its hard to overstate the importance of this sort of research.

[Trader Steve]

thanks for clearing that up maaku.

*tangent warning* blind signatures are amazing. some people talk about how the future will be saved from tyranny through peaceful parenting. others through the political system. some through revolution. but my money is on the efforts of people like yourself and gmaxwell. idk if you ever stop to think about this, but just the hand full of you guys working on these sorts of technologies might be responsible for saving the entire human species from extinction or worse. i know that sounds dramatic but i really think its hard to overstate the importance of this sort of research.

+1

[marcus_of_augustus]

Good stuff piuk ... someone needed to get the ball rolling and centralised 'trusted' CoinJoin is better than none.

Will be interested to see the statistics of how many people voluntarily choose to keep tx private when it is not so stigmatised and a simple, easy to use on/off toggle.

[gmaxwell]

Is destroying user's financial privacy and Bitcoin's fungiblity the next big business for someone to get rich quick on?

http://www.forbes.com/sites/kashmirhill/2013/11/13/sanitizing-bitcoin-coin-validation/

It doesn't have to be, but preventing this future requires substantial movement in the default behavior of everyday Bitcoin users, not just a minority of people with special interests.

[justusranvier]

Does the protocol have any way for participants to negotiate on output size restrictions?

Either make all the outputs the exact same size, or maybe restrict them to something like integer (positive and negative) powers of two?

[oakpacific]

Does the protocol have any way for participants to negotiate on output size restrictions?

Either make all the outputs the exact same size, or maybe restrict them to something like integer (positive and negative) powers of two?

I am thinking that if all the inputs and outputs are of the same size, there is no need for the server to know the mapping?

[justusranvier]

I am thinking that if all the inputs and outputs are of the same size, there is no need for the server to know the mapping?

That's fine for a theoretical exercise, but in the real world you're going to have a wallet with outputs of random sizes.

Then you're going to need to spend them on a real purchase, also of a random size.

For the protocol to be usable there's got to be a way to deal with that.

[justusranvier]

For this to work, there can not be an unambiguous mapping of input balances to output balances.

One way I can see to avoid that is a convention where outputs are always a standard size (integer powers of two, for example).

You put in a few random sized inputs, and get back several outputs of standard sizes so there's no way to tell which one belongs to what inputs.

[maaku]

justusranvier, I'm not sure I follow. Mixing is only occurring within a single transaction. Within that transaction, some subset of the outputs must be same-sized. But I do not think there is any reason that all transactions must use the same (set of) output sizes...

[oakpacific]

I am thinking that if all the inputs and outputs are of the same size, there is no need for the server to know the mapping?

That's fine for a theoretical exercise, but in the real world you're going to have a wallet with outputs of random sizes.

Then you're going to need to spend them on a real purchase, also of a random size.

For the protocol to be usable there's got to be a way to deal with that.

But it would work for drug dealers trying to cash out, right?

[justusranvier]

justusranvier, I'm not sure I follow. Mixing is only occurring within a single transaction. Within that transaction, some subset of the outputs must be same-sized. But I do not think there is any reason that all transactions must use the same (set of) output sizes...

If there's only one solution to the question of "which combinations of inputs add up to the individual output values" then the mixing isn't effective.

If I put in 5.2543 BTC worth of inputs and you put in 2.6098 BTC worth of inputs and we create a Coinjoin transaction it's possible for there to be only one combination of inputs which add up to each output. In that case the mixing could be trivially reversed, unless I'm missing something fundamental about CoinJoin.

[jedunnigan]

One way I can see to avoid that is a convention where outputs are always a standard size (integer powers of two, for example).

I like this idea, although enforcing it network-wide might have other implications (or maybe not, I'm not sure). A script could be written to easily condense a users outputs prior to a CJ tx, so gmaxwell's original design can be followed:

To use this to increase privacy, the N users would agree on a uniform output size and provide inputs amounting to at least that size.

I think Peter Todd wrote something that cleans out dust, you could just rework that to accomplish the above methinks.

[gmaxwell]

Even when the inputs can be trivially separated, a party trying to do automated analysis still gets their taint tracking degraded by widespread CJ usage since they won't be able to assume cases where two separable inputs happened was an indication that the two inputs were owned by the same party. Obviously, perfect output indistinguishably is best, but even when the outputs are fully distinguishable (and everywhere in between) there is value too.

In other news, there is a Bitcoin-QT issue for this now:
https://github.com/bitcoin/bitcoin/issues/3226

[justusranvier]

Obviously, perfect output indistinguishably is best, but even when the outputs are fully distinguishable (and everywhere in between) there is value too.

Why not right now encourage a standard that will more often result in the superior case?

I'm not particularly thrilled with merely degrading taint calculations when analytic capability is only going to improve over time.

[oakpacific]

I am thinking if we should conduct some field tests: get some people to use Coinjoin, and publish their transactions, others will employ every method they can come up with to try to determine which address has sent to which.

[maaku]

Obviously, perfect output indistinguishably is best, but even when the outputs are fully distinguishable (and everywhere in between) there is value too.

Why not right now encourage a standard that will more often result in the superior case?

I'm not particularly thrilled with merely degrading taint calculations when analytic capability is only going to improve over time.

I'm not really sure I follow. From my analysis there is zero benefit to mandating common output sizes across multiple transactions. gmaxwell, am I mistaken?

[Carlton Banks]

How do you stop the greenlisting authority from saying to you "that's a suspiciously high porportion of multi-output transactions going to your green address, BANNED"?

How do you stop the greenlisting authority from contacting the blacklisting authority and saying to them "Caught another one. Blacklist all these addresses from these transactions. Still remaining unpsent inputs? Too bad."?

[maaku]

Carlton, you don't reuse addresses. That was your mistake.

[dserrano5]

As I just said in another thread, we achieve that by automatically "blacklisting" all addresses.