I am currently working on a Java library which facilitates decentralized CoinJoin-ing using a BitcoinJ backend.

As of this moment the library only works with fixed CoinJoin participants, I have yet to implement participant discovery (that's next on the list).It also is very insecure at the moment, as I hacked together some sections in order to test general principles. It will be some time before the code is solid enough to not be embarrassing :\

This is a test CoinJoin transaction between only 2 users. In this example I set the change and output address to be the same. The general caveats of a CoinJoin transaction still apply: each change address is clearly linked with an output address, and therefore by using blockchain analysis it may still be possible to link addresses. True anonymity requires minimal address reuse and tools for managing taint.

For now, though, I just send an unconfirmed transaction to a new address of fixed size, then use that unconfirmed transaction as part of the CoinJoin. Needless to say, for this scheme 0 confirmation coinjoins should not be accepted! Regardless, I am trying to write the library to be adaptable as possible to different types of CoinJoins, including coinjoins where each user has multiple inputs, casual coinjoins, and coinjoins without any change address.

Currently peer discovery is implemented with a centralized server. The server waits for N users to connect, then sends a message containing the IP Address and port of all participants. This approach is vulnerable to denial of service and is a single point of failure, but on the up-side any compliant server can be used. I still believe distributed peer discovery is ideal, but that can always be added later.

The centralized method is also NAT-friendly if Tor is used. Here is an idea for anonymous peer discovery and communication:

1. Each participant starts a Tor Hidden Service.2. Using Tor, each participant connects to a peer discovery server, which is itself a Hidden Service. It announces the ID of its Hidden Service and open port.3. The server then sends each participant a list of the Hidden Services. The participants then connect to these Servers and proceed with the decentralized CoinJoin process.

+ No traffic ever leaves the Tor network+ No port forwarding / NAT traversal is required (in this sense it is more user-friendly than a non-anonymous

It should be noted that in order to prevent inputs and outputs from being linked by participants more complicated measures such as the blind signatures discussed on the first page must be used.

This is very safe, however it is not very private. It is essentially not possible to "lose" your coins doing this, however it has been proven that these types of transactions can be traced by inspecting the blockchain.

This is very safe, however it is not very private. It is essentially not possible to "lose" your coins doing this, however it has been proven that these types of transactions can be traced by inspecting the blockchain.

Don't confuse blockchain.info's completely broken "Shared Send"— they provide no privacy at all for reasons unrelated with this thread. The privacy implications of well constructed CoinJoins are discussed in some depth in the initial post and some other posts in this thread.

It makes no assumptions about how peers communicate but instead provides ascii-armored raw transactions similar to the PGP format which can be shared on any text-based protocol such as a Tor hidden service forums, Bitmessage chans, I2P eepsites, Freenet pages or something like that.

Currently peer discovery is implemented with a centralized server. The server waits for N users to connect, then sends a message containing the IP Address and port of all participants. This approach is vulnerable to denial of service and is a single point of failure, but on the up-side any compliant server can be used. I still believe distributed peer discovery is ideal, but that can always be added later.

The centralized method is also NAT-friendly if Tor is used. Here is an idea for anonymous peer discovery and communication:

1. Each participant starts a Tor Hidden Service.2. Using Tor, each participant connects to a peer discovery server, which is itself a Hidden Service. It announces the ID of its Hidden Service and open port.3. The server then sends each participant a list of the Hidden Services. The participants then connect to these Servers and proceed with the decentralized CoinJoin process.

+ No traffic ever leaves the Tor network+ No port forwarding / NAT traversal is required (in this sense it is more user-friendly than a non-anonymous

It should be noted that in order to prevent inputs and outputs from being linked by participants more complicated measures such as the blind signatures discussed on the first page must be used.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.