CoinJoin: Bitcoin privacy for the real world

[marcus_of_augustus]

So let me try and figure this out this is a little out of my league but here it goes:

Effectively you are creating a mixing service within the Bitcoin network itself? Making privacy better because no one can track where you sent your Bitcoin because it is split up and combined with other peoples transactions. Surely this has already been done by several mixing services?

Wouldn't this create more legal problems for Bitcoin? If this is what you want to achieve surely it's illegal because this can be abused very easily.

It also has technical benefits for the network in terms of reduced overheads.

btw, bitcoin is legal, it has no "legal problems". You are probably confused by the enormous legal complexities of handling government fiat.

[1713449528]

1713449528

[1713449528]

1713449528

[MarisaFea]

So let me try and figure this out this is a little out of my league but here it goes:

Effectively you are creating a mixing service within the Bitcoin network itself? Making privacy better because no one can track where you sent your Bitcoin because it is split up and combined with other peoples transactions. Surely this has already been done by several mixing services?

Wouldn't this create more legal problems for Bitcoin? If this is what you want to achieve surely it's illegal because this can be abused very easily.

It also has technical benefits for the network in terms of reduced overheads.

btw, bitcoin is legal, it has no "legal problems". You are probably confused by the enormous legal complexities of handling government fiat.

I was talking about how people compare Bitcoin users to criminals we all know it happens because of laundry for one example. Then this would just give those accusers more leverage because with this enabled technically everyone would be breaking the law.


Making Bitcoin illegal in every country if this is enabled. Unless I'm not fully grasping something I think that's what this is all about and could cause a few problems.

I can see why this would be beneficial to the network and the general user of Bitcoin but I can also see it enabling thieves even more.

[justusranvier]

I was talking about how people compare Bitcoin users to criminals we all know it happens because of laundry for one example. Then this would just give those accusers more leverage because with this enabled technically everyone would be breaking the law.

You're gonna *love* my next blog post...

[MarisaFea]

I was talking about how people compare Bitcoin users to criminals we all know it happens because of laundry for one example. Then this would just give those accusers more leverage because with this enabled technically everyone would be breaking the law.

You're gonna *love* my next blog post...

Link it to me and I'll tell you if I "love" it or not


/ot

I'm really trying to figure this out and try to address some of my concerns and I believe this would result in a lot of accusations flying out.

[marcus_of_augustus]

... like cash enables thieves "even more" ...  

money needs to be functional as an economic unit ... rather than fulfill every utopian fantasy bestowed upon it

[MarisaFea]

... like cash enables thieves "even more" ...  

money needs to be functional as an economic unit ... rather than fulfill every utopian fantasy bestowed upon it

Well that's always been my defense when explaining Bitcoin to people and they point out the issues with recent happening with mt gox and money laundering. Bitcoin does nothing less than cash does related to the legal side of things.

But, I'm just saying this sort of thing is adding fuel to the engine and could potentially make things a lot worse.

[justusranvier]

I was talking about how people compare Bitcoin users to criminals we all know it happens because of laundry for one example. Then this would just give those accusers more leverage because with this enabled technically everyone would be breaking the law.

You're gonna *love* my next blog post...

Link it to me and I'll tell you if I "love" it or not


/ot

I'm really trying to figure this out and try to address some of my concerns and I believe this would result in a lot of accusations flying out.

I'm going to explain how Bitcoin can be used as a defencive weapon that allows the younger generation to avoid paying the debts bestowed upon them by the older generation, and how if they wield it correctly they'll collapse the fiat debt ponzi scheme, the tax base, and the US Dollar itself, with specific instructions for how to get started.

It's going to do great things for the public perception of Bitcoin.

[doldgigger]

1. Each participant starts a Tor Hidden Service.

This would require all nodes to run Tor! Why not do the CoinJoin negotiation over BTC's network protocol, which the nodes participate in anyway? This way, those who use BTC through Tor also do the negotiation through Tor, but no one has to.

[AdNarim]

1. Each participant starts a Tor Hidden Service.

This would require all nodes to run Tor! Why not do the CoinJoin negotiation over BTC's network protocol, which the nodes participate in anyway? This way, those who use BTC through Tor also do the negotiation through Tor, but no one has to.

There is little benefit to negotiation over the Bitcoin network protocol for traditional CoinJoin's besides eliminating the need for an additional networking layer.

On the downside, adding additional messages to the network protocol is likely an irksome process, and is not very flexible. A separate network may be rapidly iterated upon, and other shared transactions other that traditional CoinJoins may be added.

In regards to Tor, for Java there exists the Orchid library, which allows Tor to be easily integrated within Java applications. The main benefit of using Tor Hidden Services (to me at least, if I am understanding things correctly) is not really anonymity, but rather NAT traversal. Without Tor, you have to keep a port open to allow users to connect to you node and perform a decentralized CoinJoin. Tor hidden services connect to Tor Relays, and therefore do not require any ports to be open. As long as the NAT/firewall allows outgoing Tor connections, everything works out.

EDIT:
I forgot to mention, a downside of using Tor is that TomP2P and all other Java DHT libraries that I know of require ports to be open to ensure the integrity of DHT (if no nodes are hosting the DHT information, what's the point?). As such, in order to make the DHT robust the code would have to be extended to facilitate Tor Hidden services. This doesn't even address the fact that using a DHT to facilitate CoinJoining between number of users n>2 is a real pain.

Hence, decentralizing peer discovery is a job for another day week month.

[Rassah]

FYI, Mycelium's development roadmap is

1) Implement HD wallets (about 95%+ done, and works fine in testnet Dev build, but still need to update LocalTrader and other minor things to work with it)
2) Move the entire infrastructure to Tor, meaning our nodes will be run as hidden servers, only accessible through Tor, and Mycelium Wallet will have Tor built in (hopefully this won't cause problems in blocked countries, like China or Iran)
3) Implement CoinJoin, using our nodes that are used for address lookup and broadcasts, to collect and broadcast mixing requests. Likely enable this as a default feature. We'll have to figure out if we'll need to follow the DarkWallet model of letting some users leave their coins to mix, or if we have enough transaction volume to do it on the fly. Maybe we'll even link with DarkWallet servers, and use the people looking to mix there.

[dillpicklechips]

3) Implement CoinJoin, using our nodes that are used for address lookup and broadcasts, to collect and broadcast mixing requests. Likely enable this as a default feature. We'll have to figure out if we'll need to follow the DarkWallet model of letting some users leave their coins to mix, or if we have enough transaction volume to do it on the fly. Maybe we'll even link with DarkWallet servers, and use the people looking to mix there.

The larger the pool the better and it might make it easier for ad hoc transactions if everyone cooperated on using popular servers.

[evanito]

This is cool to know, but I speculate that the average user wouldn't want this functionality. Of course those with security concerns or those trying to hide coins would absolutely love this service.

[Rassah]

This is cool to know, but I speculate that the average user wouldn't want this functionality. Of course those with security concerns or those trying to hide coins would absolutely love this service.

That's why some wallet makers will be implementing this as the default transaction method. Average users won't even know they are doing it.

[dillpicklechips]

Cross posting a coinjoin conversation:

As part of ongoing efforts of the Monero Project, a small program has been generated that allows you to do 1-of-N ring signatures using a secp256k1 keypair and a keyring of public keys. The program signs both binaries and text files.

https://github.com/monero-project/urs

To build and install, use this command after installation of Go:

Code:

go get -u -v github.com/monero-project/urs/...

According to the paper, unique ring signatures are anonymous except in the case of signing the same message multiple times (in which case X and Y in the signature appear to be the same).

http://csiflabs.cs.ucdavis.edu/~hbzhang/romring.pdf

A potential usage might be to sign gitian asserts from a trusted keyring anonymously that contains well known members of the Bitcoin project. Another usage would be for members of a trusted community of Bitcoin users to anonymously vote for some proposal by signing it separately and publishing their signatures.

Thanks to Hein Meling for the initial URS implementation, Conformal Systems for their immensely useful libraries, and gmaxwell for inspiration.

Another interesting use could be a type of ring signature coinjoin? A group gets together and determines the inputs. The ring signatures are used for each person to pick their outputs and can even have multiple outputs of different values. Once the group has enough messages specifying the output addresses the coinjoin transaction is created and signed. If any party of the group cheats the output values will total to be too high and the transaction is discarded.

This is a good idea. In the original coinjoin thread gmaxwell described a blinding scheme wherein users would initially provide their outputs in blinded form, have them blindsigned by the central server (or the "leader" node in a p2p setup) (or all participating parties, which is bandwidth-heavy), then reconnect anonymously to unblind them. For a p2p setup this means that somebody has to produce the blind signatures: either a leader must be selected, which adds complexity to the protocol, or every party signs every output, which leads to O(n^2) scaling.

With a ring signature on the other hand, each party would anonymously sign only their own outputs -- all nodes participate equally, with O(n) signatures. (Of course, the ring signatures are O(n) in size, so you might say this is still O(n^2) scaling. But since every signature uses the same keyring, this doesn't need to be passed around. Just the signature itself plus a blinding factor Q (one per signature, no need to use different ones per key in this case) as described in an earlier post.)

[dillpicklechips]

Some links from reddit.

https://www.youtube.com/watch?v=YDGUUtDqNV0
Coinshuffle: Trustless, Peer-to-Peer Bitcoin Mixing


Links:
Demos
http://shuffle.devbtc.com
http://simulator.devbtc.com
Github
https://github.com/bryanvu/coinshuffle-server
https://github.com/bryanvu/coinshuffle-sim
https://github.com/bryanvu/bitcoinjslib-wallet

[Trader Steve]

Some links from reddit.

https://www.youtube.com/watch?v=YDGUUtDqNV0
Coinshuffle: Trustless, Peer-to-Peer Bitcoin Mixing


Links:
Demos
http://shuffle.devbtc.com
http://simulator.devbtc.com
Github
https://github.com/bryanvu/coinshuffle-server
https://github.com/bryanvu/coinshuffle-sim
https://github.com/bryanvu/bitcoinjslib-wallet

I cannot code but I would love to see this project develop. If anybody wants to develop a wallet I'm sure there are many people like myself that would donate to help make it happen.

[Trader Steve]

FYI, Mycelium's development roadmap is

1) Implement HD wallets (about 95%+ done, and works fine in testnet Dev build, but still need to update LocalTrader and other minor things to work with it)
2) Move the entire infrastructure to Tor, meaning our nodes will be run as hidden servers, only accessible through Tor, and Mycelium Wallet will have Tor built in (hopefully this won't cause problems in blocked countries, like China or Iran)
3) Implement CoinJoin, using our nodes that are used for address lookup and broadcasts, to collect and broadcast mixing requests. Likely enable this as a default feature. We'll have to figure out if we'll need to follow the DarkWallet model of letting some users leave their coins to mix, or if we have enough transaction volume to do it on the fly. Maybe we'll even link with DarkWallet servers, and use the people looking to mix there.

Fantastic!

[dillpicklechips]

For CoinShuffle:
Are denominations best? I'm just wondering if each user specified multiple output addresses in separate encrypted containers would the amounts provide some type of clue to the originator?

I'm thinking of CoinShuffle while doing payments. If an item costs 1.2 btc then the wallet could do a CoinShuffle for 2 btc sending one output to the actual payment and the change to an address they control.

[belcher]

I posted this relevant text to the darkwallet mailing list.

Summary:
One party waits for a mix (by enabling mixing on a pocket). Another wants to mix on demand.

Allow waiting party to specify a mixing fee that will be paid to its change address by the other side.

I suggest this will create a mixing market and increase mixing volume.


----------------------------------------------------------


A proposal for an improvement to darkwallet's coinjoin system.

Darkwallet's coinjoin works with two parties. One party will wait around with bitcoins they wish to mix. Another party will connect with them whenever they want to do a transactions and the two parties will do a coinjoin. By analogy with exchange matching engines, I will call the first party the coinjoin maker and the second the coinjoin taker.

The idea is that there will be people acting as makers who will slowly mix their coins for the benefit of the takers who want to immediately mix.

Here is an example of a darkwallet coinjoin transaction
https://blockchain.info/tx/c38aac9910f327700e0f199972eed8ea7c6b1920e965f9cb48a92973e7325046

As you can see, the change addresses can be linked with the inputs but the address with outputs of 0.01btc cannot be linked. Mixing is achieved.
The maker/taker model solves the problem of having to wait around for someone who wants to coinjoin exactly the same amount as you.

There are a few small problems with this. I will propose an improvement.

First, the only people motivated enough to mix will be people who already have desire privacy. So, for the example of someone wanting to privately buy contraception and hide the fact from their parents, mixing may result in their coins being mixed with drug money. It is easy to imagine this ecosystem being split between 'clean' coins mostly owned by investors and 'dirty' coins owned by 'undesirables' of society. It's easy to imagine a blacklist system being made which these two groups are seperated and cannot cross the barrier of blacklists, which would be highly damaging to bitcoin fungiblility.

Secondly, there is little incentive to act as a coinjoin maker when you could just be a coinjoin taker and get your mixing done without any waiting.

Thirdly, a small number of coinjoin makers leaves open the possiblity of three-letter agencies offering coinjoin making, and using that role to deanonymize darkwallet coinjoins.

Proposal: Pay the coinjoin makers. They will put up offers to do coinjoin along with a fee they ask. The coinjoin transaction would be built up in a similar way to the above example, with the coinjoin maker fee being added to the associated change address and taken away from the coinjoin taker's change address.

An implication of this is that darkwallet coinjoin mixing will become like an almost-riskless savings account. We already see that holders of bitcoin are willing to earn just 0.006% per day by lending btc on the bitfinex exchange, and that contains a substantial risk that bitfinex will go disappear or be hacked taking all the bitcoins with it.
Darkwallet coinjoin with a maker's fees would be far less risky, the bitcoin private keys would never leave the owner's computer. This would likely result in investors pouring in. The huge relative supply of bitcoins along with the drought of other worthy bitcoin investments is likely to drive down the fees of mixing as the investors bid each other down.

The coinjoin takers will have access to tens of thousands of clean, untainted bitcoins to mix with at a very low price. The makers will have access to a very low risk investment for their bitcoins. Bitcoin fungiblility as a whole will benefit because the entire economy and flow of money will be more interrelated, making blacklists completely unfeasable. The market for coinjoin makers may end up so deep and liquid that three-party or even four-party coinjoins may become managable to organise.


~Belcher
PGP fingerprint: 0A8B 038F 5E10 CC27 89BF  CFFF EF73 4EA6 77F3 1129

[2586]

Proposal: Pay the coinjoin makers. They will put up offers to do coinjoin along with a fee they ask. The coinjoin transaction would be built up in a similar way to the above example, with the coinjoin maker fee being added to the associated change address and taken away from the coinjoin taker's change address.

Doesn't seem like a terrible idea. I do wonder though, could this potentially compromise the privacy of coinjoin makers based on the unique fee amounts that they charge? If I'm charging 0.5773% per transaction, that might make it easy to identify which transactions I'm involved in. Or does this not matter?

If it does, perhaps some sort of fee standardization or fuzzing should be included. Makers could be required to choose a specific fee tier (1%, 0.5%, 0.1%, 0.05%, etc). Alternatively, makers could choose a range in which to make offers (such as 0.1%-0.9%), and randomly change their offer every time their offer is taken or every 10 minutes that it sits untaken.