CoinJoin: Bitcoin privacy for the real world - page 29.

ShadowOfHarbringer

legendary

Activity: 1470

Merit: 1006

Bringing Legendary Har® to you since 1952

Quote from: Carlton Banks on November 14, 2013, 03:01:41 PM

Quote from: ShadowOfHarbringer on November 14, 2013, 02:54:14 PM

Apparently people are plotting behind the scenes to put whitelisting, blacklisting and redlisting and other terrible ideas into Bitcoin.

Perhaps we should seriously speed up initiatives like CoinJoin, CoinSwap and CoinControl so people start massively mixing coins and make such efforts unfeasible.

This assumes that you opt-in to the listing with your real world ID, then obscure the source of your funds with anonymity schemes as you've denoted. But with CoinJoin, this could get you banned from the listings people, and potentially get all the CoinJoiners you collaborated with blacklisted too.

I think the best way is to encourage miners to ban the clean addresses from tx processing. If that doesn't succeed, use or develop another coin.

Another option is to make CoinJoin/CoinSwap really popular. Perhaps make the client suggest mixing like by adding "mix coins with other's users coin" checkbox in the send coins GUI.

This way regulators will have no other way than to accept Bitcoin the way it is - mixed and untraceable.

Carlton Banks

legendary

Activity: 3430

Merit: 3080

Quote from: ShadowOfHarbringer on November 14, 2013, 02:54:14 PM

Apparently people are plotting behind the scenes to put whitelisting, blacklisting and redlisting and other terrible ideas into Bitcoin.

Perhaps we should seriously speed up initiatives like CoinJoin, CoinSwap and CoinControl so people start massively mixing coins and make such efforts unfeasible.

This assumes that you opt-in to the listing with your real world ID, then obscure the source of your funds with anonymity schemes as you've denoted. But with CoinJoin, this could get you banned from the listings people, and potentially get all the CoinJoiners you collaborated with blacklisted too.

I think the best way is to encourage miners to ban the clean addresses from tx processing. If that doesn't succeed, use or develop another coin.

ShadowOfHarbringer

legendary

Activity: 1470

Merit: 1006

Bringing Legendary Har® to you since 1952

Apparently people are plotting behind the scenes to put whitelisting, blacklisting and redlisting and other terrible ideas into Bitcoin.

Perhaps we should seriously speed up initiatives like CoinJoin, CoinSwap and CoinControl so people start massively mixing coins and make such efforts unfeasible.

jquinn

newbie

Activity: 42

Merit: 0

I'm trying to get a fundraiser rolling on reddit.

http://www.reddit.com/r/Bitcoin/comments/1qmhkh/coinjoin_fundraising_drive/

Donated a $100.

justusranvier

legendary

Activity: 1400

Merit: 1013

Quote from: maaku on November 14, 2013, 12:01:52 PM

Quote from: justusranvier on November 14, 2013, 05:41:52 AM

Quote from: gmaxwell on November 14, 2013, 05:36:38 AM

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?

Consider a hypothetical CoinJoin transaction with several inputs and two outputs, A and B.

Output A is 5.21875 BTC and Output B is 3.4375.

In order for an attacker to break the mixing he must answer the question, "which combination of inputs add up to each output", and that question could likely have only one solution. If there is only one solution, the mixing has no value other than forcing the attacker to spend a bit of CPU power on it.

If the participants in the mix instead choose to only use integer powers of 2, they can break their desired outputs down like this:

Output A can be broken down as follows:
1 x 2²
1 x 2⁰
1 x 2^-3
1 x 2^-4
1 x 2^-5

Output B can be broken down as follows:

1 x 2¹
1 x 2⁰
1 x 2^-2
1 x 2^-3
1 x 2^-4

So now the transaction has 10 outputs: 4 BTC, 1 BTC, 1 BTC, 250 mBTC, 125 mBTC, 125 mBTC, 62.5 mBTC, 62.5 mBTC, 31.25 mBTC.

The odds of finding an unambiguous mapping of inputs to outputs should be far lower in the second case.

Carlton Banks

legendary

Activity: 3430

Merit: 3080

Quote from: maaku on November 14, 2013, 12:52:50 PM

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

I don't reuse addresses. I was proposing a hypothetical situation. Greenlisting schemes suppose that everyone will be happy to reuse one address that is linked to a real world identity. Get with the program.

dserrano5

legendary

Activity: 1974

Merit: 1029

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

maaku

legendary

Activity: 905

Merit: 1012

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

Carlton Banks

legendary

Activity: 3430

Merit: 3080

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

legendary

Activity: 905

Merit: 1012

Quote from: justusranvier on November 14, 2013, 05:41:52 AM

Quote from: gmaxwell on November 14, 2013, 05:36:38 AM

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?

oakpacific

hero member

Activity: 784

Merit: 1000

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.

justusranvier

legendary

Activity: 1400

Merit: 1013

Quote from: gmaxwell on November 14, 2013, 05:36:38 AM

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.

gmaxwell

staff

Activity: 4284

Merit: 8808

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

jedunnigan

sr. member

Activity: 279

Merit: 250

Quote from: justusranvier on November 14, 2013, 02:09:28 AM

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:

Quote

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.

justusranvier

legendary

Activity: 1400

Merit: 1013

Quote from: maaku on November 14, 2013, 02:20:20 AM

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.

oakpacific

hero member

Activity: 784

Merit: 1000

Quote from: justusranvier on November 14, 2013, 02:06:22 AM

Quote from: oakpacific on November 14, 2013, 02:03:25 AM

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?

maaku

legendary

Activity: 905

Merit: 1012

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...

justusranvier

legendary

Activity: 1400

Merit: 1013

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.

justusranvier

legendary

Activity: 1400

Merit: 1013

Quote from: oakpacific on November 14, 2013, 02:03:25 AM

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.

oakpacific

hero member

Activity: 784

Merit: 1000

Quote from: justusranvier on November 13, 2013, 04:54:06 PM

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?

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