themgp



Offline



Activity: 56

Merit: 0







NewbieActivity: 56Merit: 0 Re: CoinJoin: Bitcoin privacy for the real world February 11, 2014, 06:12:45 AM #405 Quote from: Cryddit on February 09, 2014, 04:21:31 PM



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.

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'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



Offline



Activity: 924

Merit: 1055







LegendaryActivity: 924Merit: 1055 Re: CoinJoin: Bitcoin privacy for the real world February 11, 2014, 11:22:57 PM #406 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?









Cryddit



Offline



Activity: 924

Merit: 1055







LegendaryActivity: 924Merit: 1055 Re: CoinJoin: Bitcoin privacy for the real world February 12, 2014, 01:31:25 AM #408 Quote from: marcus_of_augustus on February 12, 2014, 12:28:25 AM 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.)

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.



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



Offline



Activity: 56

Merit: 0







NewbieActivity: 56Merit: 0 Re: CoinJoin: Bitcoin privacy for the real world February 16, 2014, 10:24:23 PM #409



You can view an animated GIF with two participants mixing their coins on the Coinmux homepage



Here is a full-sized direct link to the animated GIF



And of course, all of the code is available on Github at:



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

piotr_n



Offline



Activity: 2040

Merit: 1062





aka tonikt







LegendaryActivity: 2040Merit: 1062aka tonikt Re: CoinJoin: Bitcoin privacy for the real world February 20, 2014, 11:25:06 PM #415

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. 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 RussiaThe onlyCoinJoin 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 logs2) 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 PGP fingerprint: AB9E A551 E262 A87A 13BB 9059 1BE7 B545 CDF3 FD0E

okashira



Offline



Activity: 45

Merit: 0







NewbieActivity: 45Merit: 0 Re: CoinJoin: Bitcoin privacy for the real world February 20, 2014, 11:28:30 PM #416 Quote from: piotr_n on February 20, 2014, 11:25:06 PM

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.

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 RussiaThe onlyCoinJoin 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 logs2) 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. Is that exactly what Darkcoin is doing? Decentralized and encrypted coinjoin.

themgp



Offline



Activity: 56

Merit: 0







NewbieActivity: 56Merit: 0 Re: CoinJoin: Bitcoin privacy for the real world February 20, 2014, 11:48:05 PM #418 Quote from: piotr_n on February 20, 2014, 11:25:06 PM

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.

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 RussiaThe onlyCoinJoin 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 logs2) 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 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



Offline



Activity: 2040

Merit: 1062





aka tonikt







LegendaryActivity: 2040Merit: 1062aka tonikt Re: CoinJoin: Bitcoin privacy for the real world February 21, 2014, 12:04:34 AM

Last edit: February 21, 2014, 12:22:19 AM by piotr_n #419 Quote from: ShadowOfHarbringer on February 20, 2014, 11:34:44 PM 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. 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 itStill 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. 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 PGP fingerprint: AB9E A551 E262 A87A 13BB 9059 1BE7 B545 CDF3 FD0E