Thanks! There's a bit of a trust issue with any new Bitcoin software project (especially with one that asks you to enter your private key!), so i'm having a hard time finding people to try it out. Hopefully time will be the solution to that. I'm planning on giving a presentation at the SF Bitcoin Meetup to increase CoinJoin and Coinmux awareness.

I think this is a great start, your protocol needs a little work and I am writing something off of it.

Thanks! There's a bit of a trust issue with any new Bitcoin software project (especially with one that asks you to enter your private key!), so i'm having a hard time finding people to try it out. Hopefully time will be the solution to that. I'm planning on giving a presentation at the SF Bitcoin Meetup to increase CoinJoin and Coinmux awareness.

I think this is a great start, your protocol needs a little work and I am writing something off of it.

Feel free to share your thoughts. I haven't gotten any feedback on the protocol yet.

Thanks! There's a bit of a trust issue with any new Bitcoin software project (especially with one that asks you to enter your private key!), so i'm having a hard time finding people to try it out. Hopefully time will be the solution to that.

Testnet is the proper solution to that. Let people test it using testnet coins and the problem about the bitcoin private key risk goes away.

Thanks! There's a bit of a trust issue with any new Bitcoin software project (especially with one that asks you to enter your private key!), so i'm having a hard time finding people to try it out. Hopefully time will be the solution to that.

Testnet is the proper solution to that. Let people test it using testnet coins and the problem about the bitcoin private key risk goes away.

I totally agree. It is set up right now to work off testnet by default (the user needs to set an environment variable to connect to Mainnet). Unfortunately, the testnet knowledgeable audience is a lot smaller, and CoinJoining needs multiple people running it at the same time. Hopefully in time, this will resolve itself.

And i'm not sure i really made this clear in my original posting, but the only thing needed to run Coinmux is Java and the Jar file available from http://github.com/michaelgpearce/coinmux. You don't need to have BitcoinQT installed and it does not require downloading the blockchain to your computer. I'm trying to make something that an average Bitcoin user will be able to understand and use.

After reviewing your coinmux code, I can identify a problem. And a solution.

The good: no evidence appears in the blockchain about whose inputs are associated with which output. That's part 1 of the solution.

The bad: Someone eavesdropping on the protocol messages, including a nonparticipant, can associate both inputs and outputs with IP addresses. Fixing this is completely necessary before coinmux is viable, especially since the primary attack on network privacy is via traffic analysis.

The solution: Implement a Dining Cryptographers Network among the participants, and you are immune to traffic analysis. Here's a wikipedia article about the Dining Cryptographers' problem which it's based on.

In a DCN, topologically the participants are arranged in a circle, where Alice is next to Zebulon and Bob, Bob is next to Alice and Carol, Carol is next to Bob and Estelle, etc.

Each adjacent *pair* of participants generates a shared key stream - which can be as simple as repeatedly incrementing a nonce and encrypting it to get each new block of the key stream. You can use Diffie-Hellman key agreement to create a shared secret to key the stream.

Then each participant publishes XOR of the keystreams he shares with his two adjacent participants and the message he wishes to broadcast. When all of these published messages are XOR'd together, the broadcast message magically appears because each keystream has been XOR'd with it twice thereby cancelling out the keystreams. Different participants can write on different parts of the block, creating different messages. And the participants can iteratively publish the block with updates, if they use a different hunk of their shared keystreams each time. I'm thinking that the obvious implementation here has the 'block' that's getting updated include the image of a transaction. The participants would each add their inputs and their outputs, then signatures (not valid if anybody changes outputs) in a later round.

The benefit is that nobody monitoring the protocol messages can tell where the messages (or the parts of messages, IE inputs and outputs) originated, even if they saw every last message and every published XOR. Not even the participants can tell anything about the origins of any part of the message written by someone else.

It has some limitations; For example if two people both try to write on the same blob of bits at the same time, then the 'message' that appears in that blob is binary garbage. So there are conventions about 'reserving' blocks in previous rounds, where you agree that whoever reserved the block can write things in it and others shouldn't, and ways to detect which participant has broken the convention so that they can be cut out of subsequent rounds, etc. Also, it requires O(n^2) overhead where n is the number of participants, so it doesn't scale well past a few dozen people per mux. It's kinda clunky.

But it does work, and it's completely trustless in that NOBODY can de-anonymize, or even distinguish, the participants.

The cryptographer in me says I should do this, while the engineer in me thinks this may be (too) difficult to implement. (And I'm a much stronger engineer than cryptographer!) I still haven't totally wrapped my head around it from an engineering perspective, I'll do that once I get the GUI for Coinmux working. But I am a believer in keeping Coinmux simple. Bitcoin has some warts, but its really pretty simple as far as crypto goes. I'd like to keep that same philosophy for Coinmux.

One of the easiest things I can do to limit who sees the the IP address of published messages is to encrypt them. Both the Director and Participants have a public key as part of their first message broadcast. Other than the Director's first announcement message and the Director's subsequent status updates, all other messages can be encrypted so only the involved parties can decrypt the messages. The IP address would still be leaked, but only those in the mix can make sense of what's going on. While not a cryptographically perfect solution, this would make traffic analysis more difficult and less useful. This may make put Coinmux in the "good enough to be useful" category. This wouldn't be great, but as an engineer, I realize everything has tradeoffs.

The Coinmux protocol itself was not designed to hide IP addresses/participants, only to facilitate communication. As i first imagined what the protocol would look like, I had always considered using Freenet for message communication and to provide anonymity at the "network layer." Coinmux was designed with a Freenet like system in mind with the following properties: untraceable message insertion, immutable messages, ability to post multiple messages to a known location/key, and all messages publicly retrievable from a known key. TomP2P allows for all of these except the untraceable message insertion. TomP2P was really only selected due to it being available as a Java library and ready to be embedded in an application. Well, that and it's faster than Freenet.

I'd rather try to solve this at the network layer than the protocol layer. This allows for the network layer to be easily changed (I have 3 implementations now - TomP2P, the filesystem, and a memory implementation used for testing). I am still actively considering switching to using Freenet as originally planned. Bitmessage is another option, though i believe their API is inadequate. Maybe there is a way to use Tor. Or maybe some new Altcoin becomes a viable option in the future. Or maybe i can push harder on TomP2P: is it possible to shuffle messages around the TomP2P peer network before inserting them to provide anonymity? The protocol doesn't care who inserted the message, only that it gets inserted. As it is right now, none of the options outside of TomP2P meet the requirement of "easy to use" as they require an additional application running.

Anyway, there are lots of different options and all of them have tradeoffs, but I am pretty open to anything that will work. I'll need to let what you wrote settle on my brain a little more.

Maybe you can use i2p (https://geti2p.net) for the network layer (comes with nice java bindings ).

I had looked at I2P for this project previously but ruled it out due to it not behaving as a data store (which Freenet and TomP2P both are). Looking at the I2P documentation again, they did mention someone adding Tahoe-LAFS support (https://geti2p.net/en/comparison/freenet), but I don't have any information about that.

I also looked at I2P before I knew about TomP2P. Since I2P supports both TCP and UDP (https://geti2p.net/en/comparison/tor), it may be possible to combine it with TomP2P. AFAIK, Tor does not support UDP so TomP2P + Tor is not possible.

Maybe you can use i2p (https://geti2p.net) for the network layer (comes with nice java bindings ).

I had looked at I2P for this project previously but ruled it out due to it not behaving as a data store (which Freenet and TomP2P both are). Looking at the I2P documentation again, they did mention someone adding Tahoe-LAFS support (https://geti2p.net/en/comparison/freenet), but I don't have any information about that.

I also looked at I2P before I knew about TomP2P. Since I2P supports both TCP and UDP (https://geti2p.net/en/comparison/tor), it may be possible to combine it with TomP2P. AFAIK, Tor does not support UDP so TomP2P + Tor is not possible.

After reviewing your coinmux code, I can identify a problem. And a solution.

The good: no evidence appears in the blockchain about whose inputs are associated with which output. That's part 1 of the solution.

The bad: Someone eavesdropping on the protocol messages, including a nonparticipant, can associate both inputs and outputs with IP addresses. Fixing this is completely necessary before coinmux is viable, especially since the primary attack on network privacy is via traffic analysis.

The solution: Implement a Dining Cryptographers Network among the participants, and you are immune to traffic analysis. Here's a wikipedia article about the Dining Cryptographers' problem which it's based on.

In a DCN, topologically the participants are arranged in a circle, where Alice is next to Zebulon and Bob, Bob is next to Alice and Carol, Carol is next to Bob and Estelle, etc.

Each adjacent *pair* of participants generates a shared key stream - which can be as simple as repeatedly incrementing a nonce and encrypting it to get each new block of the key stream. You can use Diffie-Hellman key agreement to create a shared secret to key the stream.

Then each participant publishes XOR of the keystreams he shares with his two adjacent participants and the message he wishes to broadcast. When all of these published messages are XOR'd together, the broadcast message magically appears because each keystream has been XOR'd with it twice thereby cancelling out the keystreams. Different participants can write on different parts of the block, creating different messages. And the participants can iteratively publish the block with updates, if they use a different hunk of their shared keystreams each time. I'm thinking that the obvious implementation here has the 'block' that's getting updated include the image of a transaction. The participants would each add their inputs and their outputs, then signatures (not valid if anybody changes outputs) in a later round.

The benefit is that nobody monitoring the protocol messages can tell where the messages (or the parts of messages, IE inputs and outputs) originated, even if they saw every last message and every published XOR. Not even the participants can tell anything about the origins of any part of the message written by someone else.

It has some limitations; For example if two people both try to write on the same blob of bits at the same time, then the 'message' that appears in that blob is binary garbage. So there are conventions about 'reserving' blocks in previous rounds, where you agree that whoever reserved the block can write things in it and others shouldn't, and ways to detect which participant has broken the convention so that they can be cut out of subsequent rounds, etc. Also, it requires O(n^2) overhead where n is the number of participants, so it doesn't scale well past a few dozen people per mux. It's kinda clunky.

But it does work, and it's completely trustless in that NOBODY can de-anonymize, or even distinguish, the participants.

I've thought through this some more. I could implement this, and it wouldn't be terribly difficult. In fact, I think I can even implement it without changing my current communication API (see my data store requirements in a previous post). My main problem with it is that it only solves one thing that i can't solve by simply encrypting every message published to the Director and a DCN doesn't solve a larger issue.

With using TomP2P and adding message encryption, the Director can still connect IP addresses to Inputs/Outputs but the Participants cannot. A DCN will solve this. But an outside observer would most likely still be able to connect IP addresses with the resulting published transaction just by watching the Coinmux network and watching the Bitcoin network. While the observer cannot directly correlate an IP to a specific Bitcoin output address, just knowing the transaction and the IP addresses involved is still a pretty big leaked piece of information.

If I use an anonymity network (i.e. Freenet), it would solve both issues. Neither the participants nor the director would be able to associate an IP address to a specific input/output, and an observer would not be able to associate a transaction to any IP addresses.

I like the DCN because it's elegant and comes with an honest-to-goodness proof of security against all traffic analysis. Even with just two honest participants, nobody else can tell which of them sent a message even if they can see (and even modify!) every message in the whole network.

I guess I trust anonymity networks less, because I consider them to be potentially fakeable; I can imagine code running on a network of servers that presents all honest participants an interface indistinguishable to them from an anonymity network while compromising their communication. In an anonymity network, you only need to compromise the two or three or four nodes that your messages are getting routed through. Or the routing tables that tell you where they are. Or the messages from the DNS servers that relay that information to you. Or ....

I've been reading about the lengths that eavesdroppers are going to, and that just seems like something they'd do. Or something which, if they haven't done it yet, they eventually will. Maybe I'm excessively cynical; I just think that if you leave a target surface, then sooner or later someone is going to exploit it. Massive sybil attacks, fake nodes, backbone router trojans, etc... They've drawn the line at nothing so far. The NSA even went so far as to put a zero-day exploit against the browser that TOR is used with at a fake site, intercepted traffic on backbone nodes, and redirected requests at it in realtime from computers where TOR traffic had been detected. And that's the government - the people who are supposed to be on our side. What the heck are straight-up crooks ready to do?

the people who are supposed to be on our side. What the heck are straight-up crooks ready to do?

You're assuming that the "straight out crooks" aren't the NSA? (All evidence to the contrary.)

I'm just saying that they can't possibly be the worst crooks out there. I mean, hell, I figure we know who the NSA are. If they were really the worst crooks out there we *WOULDN'T* know who they are.

They had public PR problems, boo-hoo, because they accidentally hired someone honest. My heart bleeds for them. But the absolute worst crooks wouldn't have that problem.

People keep forgetting that the NSA isn't the only thing like itself that exists in the world; probably not even the best. And people keep forgetting that among those things, the NSA is probably only about average in terms of its honesty and morality. And that just addresses government agencies, not even starting on whatever parasitic criminal organizations have infiltrated them. Hell, if the NSA is doing all the stuff in the Snowden files, and failed to even keep that a secret, I hate to imagine what NAPSS, BBN, GRU, SAVAK, Mossad etc, are up to.

Hey all. I released a new version of Coinmux that now has a graphical user interface. It still defaults to using the Testnet network, but you can now easily change that in the preferences menu if you are adventurous with your Bitcoin.

You can view an animated GIF with two participants mixing their coins on the Coinmux homepage http://www.coinmux.com.

Hey all. I released a new version of Coinmux that now has a graphical user interface. It still defaults to using the Testnet network, but you can now easily change that in the preferences menu if you are adventurous with your Bitcoin.

Hey all. I released a new version of Coinmux that now has a graphical user interface. It still defaults to using the Testnet network, but you can now easily change that in the preferences menu if you are adventurous with your Bitcoin.