Bitcoin Forum
November 15, 2019, 07:20:15 AM *
News: Help collect the most notable posts made over the last 10 years.
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 [21] 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 »
  Print  
Author Topic: CoinJoin: Bitcoin privacy for the real world  (Read 291287 times)
themgp
Newbie
*
Offline Offline

Activity: 56
Merit: 0


View Profile
February 08, 2014, 04:46:08 AM
 #401

Good stuff - I hope it will explode

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.
The Bitcoin Forum is turning 10 years old! Join the community in sharing and exploring the notable posts made over the years.
1573802415
Hero Member
*
Offline Offline

Posts: 1573802415

View Profile Personal Message (Offline)

Ignore
1573802415
Reply with quote  #2

1573802415
Report to moderator
1573802415
Hero Member
*
Offline Offline

Posts: 1573802415

View Profile Personal Message (Offline)

Ignore
1573802415
Reply with quote  #2

1573802415
Report to moderator
1573802415
Hero Member
*
Offline Offline

Posts: 1573802415

View Profile Personal Message (Offline)

Ignore
1573802415
Reply with quote  #2

1573802415
Report to moderator
Cryddit
Legendary
*
Offline Offline

Activity: 910
Merit: 1042


View Profile
February 09, 2014, 04:21:31 PM
 #402

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.  
themgp
Newbie
*
Offline Offline

Activity: 56
Merit: 0


View Profile
February 09, 2014, 09:36:16 PM
 #403

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.
randomguy7
Hero Member
*****
Offline Offline

Activity: 528
Merit: 500


View Profile
February 09, 2014, 11:13:18 PM
 #404

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

Activity: 56
Merit: 0


View Profile
February 10, 2014, 12:44:25 AM
 #405

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

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.
themgp
Newbie
*
Offline Offline

Activity: 56
Merit: 0


View Profile
February 10, 2014, 12:48:39 AM
 #406

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

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. Smiley
Trader Steve
Hero Member
*****
Offline Offline

Activity: 833
Merit: 1000


"How do you eat an elephant? One bit at a time..."


View Profile
February 10, 2014, 04:50:56 AM
 #407


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

gweedo
Legendary
*
Offline Offline

Activity: 1274
Merit: 1000


View Profile
February 10, 2014, 04:57:04 AM
 #408


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

https://github.com/blockchain/Sharedcoin it is written in JavaEE
Trader Steve
Hero Member
*****
Offline Offline

Activity: 833
Merit: 1000


"How do you eat an elephant? One bit at a time..."


View Profile
February 10, 2014, 05:53:16 AM
 #409


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

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

Thanks!
themgp
Newbie
*
Offline Offline

Activity: 56
Merit: 0


View Profile
February 11, 2014, 06:12:45 AM
 #410

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
Legendary
*
Offline Offline

Activity: 910
Merit: 1042


View Profile
February 11, 2014, 11:22:57 PM
 #411

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
Legendary
*
Offline Offline

Activity: 2996
Merit: 1173



View Profile
February 12, 2014, 12:28:25 AM
 #412

Quote
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
Legendary
*
Offline Offline

Activity: 910
Merit: 1042


View Profile
February 12, 2014, 01:31:25 AM
 #413

Quote
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
Newbie
*
Offline Offline

Activity: 56
Merit: 0


View Profile
February 16, 2014, 10:24:23 PM
 #414

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
Legendary
*
Offline Offline

Activity: 1764
Merit: 1002



View Profile
February 17, 2014, 12:49:25 AM
 #415


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
Full Member
***
Offline Offline

Activity: 176
Merit: 100


View Profile
February 17, 2014, 05:15:23 AM
 #416

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
Newbie
*
Offline Offline

Activity: 56
Merit: 0


View Profile
February 17, 2014, 08:40:03 AM
 #417

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. Smiley
piotr_n
Legendary
*
Offline Offline

Activity: 2016
Merit: 1054


aka tonikt


View Profile WWW
February 18, 2014, 01:26:05 PM
Last edit: February 18, 2014, 02:06:48 PM by piotr_n
 #418

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

Check out gocoin - my original project of full bitcoin node & cold wallet written in Go.
PGP fingerprint: AB9E A551 E262 A87A 13BB  9059 1BE7 B545 CDF3 FD0E
Rassah
Legendary
*
Offline Offline

Activity: 1680
Merit: 1028



View Profile WWW
February 20, 2014, 10:19:08 PM
 #419

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

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

piotr_n
Legendary
*
Offline Offline

Activity: 2016
Merit: 1054


aka tonikt


View Profile WWW
February 20, 2014, 11:25:06 PM
 #420

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 Smiley

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.

Check out gocoin - my original project of full bitcoin node & cold wallet written in Go.
PGP fingerprint: AB9E A551 E262 A87A 13BB  9059 1BE7 B545 CDF3 FD0E
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 [21] 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!