CoinJoin: Bitcoin privacy for the real world

[maaku]

what happens if the facilitator is compromised?

Depends on which implementation you are talking about. In gmaxwell's protocol and my crowd-fund proposal, outputs are blinded so neither the facilitator nor any of the participants know which outputs belong to any of the others. So the facilitator doesn't have to be trusted, other than to complete the protocol. Genjix's server doesn't use blind signing & anonymous revelation, so I'd imagine you'd be able to trace ownership from the facilitator's logs (I haven't looked at his code, however).

[1713998281]

1713998281

[1713998281]

1713998281

[1713998281]

1713998281

[1713998281]

1713998281

[piuk]

Blockchain.info's coinjoin implementation (Shared coin) is now available in the wallet interface by default.
 


It uses a hybrid approach mixing with other clients and a pool provided by the server. The advantage to this approach is a) there is no long wait time needed for other clients to join in your transaction (hence easier to bootstrap if usage is low initially) b) the server always has a large pool available which can be used to reduce transaction taint more effectively. Browser extension coming soon.

Depends on which implementation you are talking about. In gmaxwell's protocol and my crowd-fund proposal, outputs are blinded so neither the facilitator nor any of the participants know which outputs belong to any of the others. So the facilitator doesn't have to be trusted, other than to complete the protocol.

I think there is a flaw in the blind signing solution. The client doesn't know how many other genuine participants have joined in a transaction so if the server was malicious it could lie, add its own outputs, and force one participant per transaction. With only one genuine participant in the transaction even if the outputs are blind signed it simple to connect the correct inputs.

[Peter Todd]

Blockchain.info's coinjoin implementation (Shared coin) is now available in the wallet interface by default.

Thank you! This is great news.

Depends on which implementation you are talking about. In gmaxwell's protocol and my crowd-fund proposal, outputs are blinded so neither the facilitator nor any of the participants know which outputs belong to any of the others. So the facilitator doesn't have to be trusted, other than to complete the protocol.

I think there is a flaw in the blind signing solution. The client doesn't know how many other genuine participants have joined in a transaction so if the server was malicious it could lie, add its own outputs, and force one participant per transaction. With only one genuine participant in the transaction even if the outputs are blind signed it simple to connect the correct inputs.

I replied to maaku's crowd-fund proposal with similar concerns. In the general case I think blind-signing is a overly complex cryptographic solution looking for a problem. What you describe is just a particularly bad example of how it doesn't actually give you any anti-sybil protection if you don't know who the counterparts to the transaction are. I proposed that two-party mixes be used in the general case. The cryptography required is almost trivial and can be done with existing libraries used for their intended purpose, the user experience is good because the transactions can happen almost as fast as regular ones and it's easy to do the negotiations on the existing P2P network, and finally the anti-sybil resistance claimed is much more honest: we know we can't prevent sybil attacks, but we can make them cost a lot of transaction fees.

[maaku]

I think there is a flaw in the blind signing solution. The client doesn't know how many other genuine participants have joined in a transaction so if the server was malicious it could lie, add its own outputs, and force one participant per transaction. With only one genuine participant in the transaction even if the outputs are blind signed it simple to connect the correct inputs.

That's why you use multiple facilitators, and act as act as facilitator yourself 1/N of the time. The implementation I'm working on is fully p2p.

[Peter Todd]

I think there is a flaw in the blind signing solution. The client doesn't know how many other genuine participants have joined in a transaction so if the server was malicious it could lie, add its own outputs, and force one participant per transaction. With only one genuine participant in the transaction even if the outputs are blind signed it simple to connect the correct inputs.

That's why you use multiple facilitators, and act as act as facilitator yourself 1/N of the time. The implementation I'm working on is fully p2p.

That's no better than the two-party case though - you have no idea if anyone else in the p2p network, facilitator or not, is real or part of a sybil attack, and it's still going to be slower to complete a transaction than the two-party alternative.

[Peter Todd]

Blockchain.info's coinjoin implementation (Shared coin) is now available in the wallet interface by default.

For transactions where I'm not in a rush - and am willing to leave my bc.i client running - think you could add an advanced option where you give the wallet a destination address and a timeout and it waits until someone else is available to do a coinjoin?

[dserrano5]

Blockchain.info's coinjoin implementation (Shared coin) is now available in the wallet interface by default.

Way to go piuk! It's a centralised effort but it's better to have a centralised coinjoin than no coinjoin at all.

[molecular]

Blockchain.info's coinjoin implementation (Shared coin) is now available in the wallet interface by default.

Way to go piuk! It's a centralised effort but it's better to have a centralised coinjoin than no coinjoin at all.

I totally agree. However I think it should be made transparent that with this solution, the facilitator can map inputs to outputs easily and you have to trust him with retaining your own personal privacy.

One question piuk: does your servers in any way store records that would allow this mapping to be conducted by some entity gaining access to your databases?

[justusranvier]

One question piuk: does your servers in any way store records that would allow this mapping to be conducted by some entity gaining access to your databases?

You should never asks this question of any service.

Why? Because the answer you receive doesn't matter because you have no way to independently to verify the truth of a response.

A dishonest operator can lie.

An honest operator might not start out keeping logs, but could be ordered to do so and forbidden from telling you the truth via the threat of going to jail.

An honest operator might not realize they are keeping logs because their system has been compromised.

Under no circumstances can you trust someone's word about not keeping logs. This applies to VPN providers, bitcoin mixers, email hosts, or any other privacy-sensitive service. If it's conceivably possible that they are keeping privacy-destroying logs then you must assume they are, and act accordingly.

[CIYAM]

Under no circumstances can you trust someone's word about not keeping logs. This applies to VPN providers, bitcoin mixers, email hosts, or any other privacy-sensitive service. If it's conceivably possible that they are keeping privacy-destroying logs then you must assume they are, and act accordingly.

I hate to do this (in fact it might be the first time I actually have) but:

+1

[Peter Todd]

Under no circumstances can you trust someone's word about not keeping logs. This applies to VPN providers, bitcoin mixers, email hosts, or any other privacy-sensitive service. If it's conceivably possible that they are keeping privacy-destroying logs then you must assume they are, and act accordingly.

piuk, and my, point is that decentralized P2P systems with anonymous counterparties aren't necessarily any better because you can't know if your counterparties to the coinjoin are the NSA/FBI/whatever.

At least with a central service if they are honest you're well protected. With P2P stuff every transaction you make may or may not be deanonymized.

Best to use both if you really need to be able to count on the privacy... and hopefully someone will come up with a off-chain transfer system on some Tor site that implements chaum tokens.

[genjix]

to make coinjoin work properly we first need decentralised identity and reputation systems to protect against that. otherwise just making it p2p for the fun of it is not doing anything.

[justusranvier]

piuk, and my, point is that decentralized P2P systems with anonymous counterparties aren't necessarily any better because you can't know if your counterparties to the coinjoin are the NSA/FBI/whatever.

It turns into a numbers game. If x% of the participants are evil, then you need to mix 1/x times.

Best to use both if you really need to be able to count on the privacy... and hopefully someone will come up with a off-chain transfer system on some Tor site that implements chaum tokens.

I agree the ideal solution is a cryptographic protocol in which nobody can cheat, even if all the participants are evil.

[justusranvier]

otherwise just making it p2p for the fun of it is not doing anything.

Actually it is doing something - providing a type of plausible deniability.

Suppose CoinJoin transactions become a frequent occurrence in the blockchain. I can now spend funds from my wallet using transactions that appear to be CoinJoins, but are actually only my funds. I might only need to use "real" CoinJoin transactions some small percentage of the time.

[Trader Steve]

Best to use both if you really need to be able to count on the privacy... and hopefully someone will come up with a off-chain transfer system on some Tor site that implements chaum tokens.

Could Open Transactions play a role in any of this?

https://github.com/FellowTraveler/Open-Transactions

[molecular]

One question piuk: does your servers in any way store records that would allow this mapping to be conducted by some entity gaining access to your databases?

You should never asks this question of any service.

Why? Because the answer you receive doesn't matter because you have no way to independently to verify the truth of a response.

A dishonest operator can lie.

An honest operator might not start out keeping logs, but could be ordered to do so and forbidden from telling you the truth via the threat of going to jail.

An honest operator might not realize they are keeping logs because their system has been compromised.

Under no circumstances can you trust someone's word about not keeping logs. This applies to VPN providers, bitcoin mixers, email hosts, or any other privacy-sensitive service. If it's conceivably possible that they are keeping privacy-destroying logs then you must assume they are, and act accordingly.

There's the possiblity he will just say: yes, we keep logs. In that case the question would've made sense.

[molecular]

otherwise just making it p2p for the fun of it is not doing anything.

Actually it is doing something - providing a type of plausible deniability.

Suppose CoinJoin transactions become a frequent occurrence in the blockchain. I can now spend funds from my wallet using transactions that appear to be CoinJoins, but are actually only my funds. I might only need to use "real" CoinJoin transactions some small percentage of the time.

Exactly.

There's this huge upside to widespread use of coinjoin transactions (no matter how they've been assembled) in general (even affecting people that don't ever use coinjoin), because it torpedoes the assumption that all inputs of a transaction are owned by a single entity that can currently pretty reliably be used to cluster addresses, which is the most common (valid) argument used when arguing that bitcoin isn't as private as many think.

[Anon136]

I think there is a flaw in the blind signing solution. The client doesn't know how many other genuine participants have joined in a transaction so if the server was malicious it could lie, add its own outputs, and force one participant per transaction. With only one genuine participant in the transaction even if the outputs are blind signed it simple to connect the correct inputs.

That's why you use multiple facilitators, and act as act as facilitator yourself 1/N of the time. The implementation I'm working on is fully p2p.

That's no better than the two-party case though - you have no idea if anyone else in the p2p network, facilitator or not, is real or part of a sybil attack, and it's still going to be slower to complete a transaction than the two-party alternative.

how did we solve this with bitcoin? you could solve it here the exact same way. have the facilitators be the 6 most recent miners to contribute new blocks to the blockchain. or atleast the 6 most recent who agree to provide the service.

maaku if you read this also please tell me what you think.

[maaku]

Anon136, there is no need to reduce the set of facilitators in any way, even by distributed consensus. But miners could certainly publish lists of perceived reliable facilitators in their blocks, helping others to find them. There's a proposal along these lines for peer lists that is currently circulating the development mailing list.

[Anon136]

Anon136, there is no need to reduce the set of facilitators in any way, even by distributed consensus. But miners could certainly publish lists of perceived reliable facilitators in their blocks, helping others to find them. There's a proposal along these lines for peer lists that is currently circulating the development mailing list.

what if the majority of the facilitators were actually a single malicious actor using multiple ip exit nodes? have you devised a mechanism for preventing him from being able to deduce information about transactions in this manner? or have you devised an alternative mechanism for insuring that no such actor is ever able to gain that much influence?