CoinJoin: Bitcoin privacy for the real world

[themgp]

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.

[1715138643]

1715138643

[1715138643]

1715138643

[1715138643]

1715138643

[themgp]

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.

I just saw this: https://geti2p.net/en/docs/applications/supported#decentralized-file-storage (though i can't view eepsites right now since i don't have I2P installed).  I2P definitely goes back on my investigation list.

[Trader Steve]

Question: Does anybody know how Blockchain.info implements their CoinJoin?

[Trader Steve]

Question: Does anybody know how Blockchain.info implements their CoinJoin?

https://github.com/blockchain/Sharedcoin it is written in JavaEE

Thanks!

[themgp]

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.  

http://en.wikipedia.org/wiki/Dining_cryptographers_problem

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.

[Cryddit]

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?

[marcus_of_augustus]

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

[Cryddit]

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.

[themgp]

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.

Here is a full-sized direct link to the animated GIF http://coinmux.com/images/animated-coinmux.gif.

And of course, all of the code is available on Github at: http://github.com/michaelgpearce/coinmux.

[cypherdoc]

Question: Does anybody know how Blockchain.info implements their CoinJoin?

https://github.com/blockchain/Sharedcoin it is written in JavaEE

Thanks!

how well is it working?

[philipmicklon]

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.

And of course, all of the code is available on Github at: http://github.com/michaelgpearce/coinmux.

It looks awesome! Keep up the good work!

[themgp]

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.

And of course, all of the code is available on Github at: http://github.com/michaelgpearce/coinmux.

It looks awesome! Keep up the good work!

Thanks! I forgot what a pain in the ass making a desktop app is. This was a good reminder.

[piotr_n]

What about adding this into server based clients with matching via the server? (Electrum, Blockchain.info, Mycelium...)

And make them to not store the logs?
That would probably be the quickest way to get whoever run these servers arrested by US nazi law enforcement (aka national security services) - at some airport somewhere in the world...

[Rassah]

What about adding this into server based clients with matching via the server? (Electrum, Blockchain.info, Mycelium...)

And make them to not store the logs?
That would probably be the quickest way to get whoever run these servers arrested by US nazi law enforcement (aka national security services) - at some airport somewhere in the world...

I think Mycelium has CoinJoin as one of the things on their future To Do list. If not, I'll add it 

[piotr_n]

Yeah, but I'm just saying that it's pretty worthless if they store the logs.
And if they don't store the logs... well, that's probably illegal, at least in US and Russia

The only safe CoinJoin solution I see is p2p based, with some tricky encryption.

But still I think this will never beat services like bitcoinfog, assuming that they indeed remove the logs as they claim.
I mean: you deposit your money and withdraw ~98% of it, while your deposit is still unspent - destroying a log at this moment leaves absolutely no traces and it's actually a perfect "privacy for the real world".
Though it has two big disadvantages, over p2p coin mixing:
1) You need to trust the service to really destroy the logs
2) It doesn't come for free.

So I also find CoinJoin as a nice and possibly useful project, but IMHO centralizing it around a server would just defeat the purpose.
Not to mention that it would be dangerous for whoever runs this server.

[okashira]

Yeah, but I'm just saying that it's pretty worthless if they store the logs.
And if they don't store the logs... well, that's probably illegal, at least in US and Russia

The only safe CoinJoin solution I see is p2p based, with some tricky encryption.

But still I think this will never beat services like bitcoinfog, assuming that they indeed remove the logs as they claim.
I mean: you deposit your money and withdraw ~98% of it, while your deposit is still unspent - destroying a log at this moment leaves absolutely no traces and it's actually a perfect "privacy for the real world".
Though it has two big disadvantages, over p2p coin mixing:
1) You need to trust the service to really destroy the logs
2) It doesn't come for free.

So I also find CoinJoin as a nice and possibly useful project, but IMHO centralizing it would just defeat the purpose.

Is that exactly what Darkcoin is doing? Decentralized and encrypted coinjoin.

[ShadowOfHarbringer]

Yeah, but I'm just saying that it's pretty worthless if they store the logs.
And if they don't store the logs... well, that's probably illegal, at least in US and Russia

The only safe CoinJoin solution I see is p2p based, with some tricky encryption.

But still I think this will never beat services like bitcoinfog, assuming that they indeed remove the logs as they claim.
I mean: you deposit your money and withdraw ~98% of it, while your deposit is still unspent - destroying a log at this moment leaves absolutely no traces and it's actually a perfect "privacy for the real world".
Though it has two big disadvantages, over p2p coin mixing:
1) You need to trust the service to really destroy the logs
2) It doesn't come for free.

So I also find CoinJoin as a nice and possibly useful project, but IMHO centralizing it around a server would just defeat the purpose.
Not to mention that it would be dangerous for whoever runs this server.

Piotr_n, you seem to be an intelligent and experienced low level (C++ or lower) programmer.

Wouldn't it suit you better simply to write your own CoinJoin implementation instead of just talking about it ?

After studying your posts on these forums, I am fairly certain that you have the skill. The question is, whether you want to do something with it, or just keep discussing the topic ?

[themgp]

Yeah, but I'm just saying that it's pretty worthless if they store the logs.
And if they don't store the logs... well, that's probably illegal, at least in US and Russia

The only safe CoinJoin solution I see is p2p based, with some tricky encryption.

But still I think this will never beat services like bitcoinfog, assuming that they indeed remove the logs as they claim.
I mean: you deposit your money and withdraw ~98% of it, while your deposit is still unspent - destroying a log at this moment leaves absolutely no traces and it's actually a perfect "privacy for the real world".
Though it has two big disadvantages, over p2p coin mixing:
1) You need to trust the service to really destroy the logs
2) It doesn't come for free.

So I also find CoinJoin as a nice and possibly useful project, but IMHO centralizing it around a server would just defeat the purpose.
Not to mention that it would be dangerous for whoever runs this server.

The CoinJoin client I wrote, Coinmux https://github.com/michaelgpearce/coinmux is P2P and open source.  Its still in its early development phase though.  Having spent the last 10 years building web applications, building a true P2P application is definitely more difficult than building a server-side solution (which you have to trust).

[piotr_n]

After studying your posts on these forums, I am fairly certain that you have the skill. The question is, whether you want to do something with it, or just keep discussing the topic ?

Honestly, I just don't need it, so I don't really feel the urge to create such a thing.

If the solution was easy I would have probably done it even when not needing it, but in such case someone else would have already done it before me. The problem is that it doesn't seem so much straight forward. At the other hand providing feedback on the forum is easy - this I can do by the way of having another beer before sleep, nothing hard about it

Still I believe it can be done and since it can be done, someone will do it one day - it is just a matter of time.
But to design it well, you first need to define what kind of privacy this technology is supposed to target.
I mean you can identify a different kind of threads.
The first one is of course that all the internet traffic is recorded.
The second: that the peers with who you are sharing your transaction may (and surely will, after you launch the project) be malicious - e.g I can imagine a network of bots flooding the p2p system with many txs to themselves, just to learn about your transactions.
A third... probably also something.

But if you just want to do a "p2p CoinJoin", without caring about any of these things, then you might just as well look for people to share your tx with at IRC; you all make a joined tx and each party signs manually its part. There already is a software that can do it - not only mine, for what I know.

[Cryddit]

It's possible to implement coinjoin that can be trusted, even if nobody deletes the logs.  You can secure it against the ability to associate inputs or outputs with each other, or with IP addresses, to an opponent using blockchain evidence, server logs, or realtime packet sniffing. 

The "tricky cryptography" is a stream cipher with multiple keys, each key being known to exactly two participants  (aka, a dc-net).  There is a requirement that there must be more than one honest participant in the "join" whose stream key is unknown to the opponent.   An opponent listening to packet traffic can associate inputs/outputs with any participant whose key that opponent has compromised, so if there is only one honest participant whose key is uncompromised, the opponent can associate inputs/outputs with that participant by process of elimination.

I'll implement it if nobody else has by the time I get around to it, but it isn't my highest priority right now; I have a higher-paying bounty to pursue in programming, which is (arguably) even more important to Bitcoin in terms of adoption and remaining decentralized, and that is to limit the size of the blockchain download needed to run a full node.