Bitcoin Forum
June 24, 2017, 09:04:16 PM *
News: Latest stable version of Bitcoin Core: 0.14.2  [Torrent].
 
   Home   Help Search Donate Login Register  
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 »
  Print  
Author Topic: CoinJoin: Bitcoin privacy for the real world  (Read 252394 times)
Rassah
Legendary
*
Offline Offline

Activity: 1680


Director of Bitcoin100


View Profile
December 13, 2013, 06:57:04 AM
 #321

I don't see how CoinJoin can possibly ever be effective in a situation of address reuse.

Is Blockchain.info ever going to stop doing that?

I think they already have. Their default bitcoin transactions send change to new addresses, as does their CoinJoin.

I'm only using blockchain.info's coinjoin it to offload and split up my larger bitcoin purchases into cold storage. Hopefully it was sufficient enough for the last few deposits I made.

Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1498338256
Hero Member
*
Offline Offline

Posts: 1498338256

View Profile Personal Message (Offline)

Ignore
1498338256
Reply with quote  #2

1498338256
Report to moderator
1498338256
Hero Member
*
Offline Offline

Posts: 1498338256

View Profile Personal Message (Offline)

Ignore
1498338256
Reply with quote  #2

1498338256
Report to moderator
1498338256
Hero Member
*
Offline Offline

Posts: 1498338256

View Profile Personal Message (Offline)

Ignore
1498338256
Reply with quote  #2

1498338256
Report to moderator
justusranvier
Legendary
*
Offline Offline

Activity: 1400



View Profile WWW
December 13, 2013, 08:19:02 AM
 #322

Their default bitcoin transactions send change to new addresses, as does their CoinJoin.
When did that happen? That's a major change that deserves a large announcement. Are they using BIP32 to derive the new addresses?
TierNolan
Legendary
*
Offline Offline

Activity: 1078


View Profile
December 13, 2013, 11:44:22 AM
 #323

I understand, but if we have 3 people, I put in 5BTC, someone else puts in 2BTC, and the third person puts in 3.5BTC, the coins all get broken up into random amounts and go through two stage mix, in the end, we still have 5BTC, 2BTC, and 3.5BTC, just in new addresses. Isn't that fairly easy to track? I know I'm missing something... What is it?

You need to agree on a common amount.

Inputs (5, 2, 3.5)
Outputs
2
2
2
3 (your change)
1.5 (change for the 3.5 BTC guy)

You get one of the 2 BTC coins and your 3 BTC change coin.  Your software would need to remember that the 3 BTC change coin was not mixed, but the 2BTC one was.

In fact, you could split your 3 coin into two 1.5 BTC coins, so it would be slightly mixed.  You would get 2 of the 3 1.5 BTC outputs.

If there was only 2 into the mix, there would generally be two inputs and three outputs, so the guy who paid more gets (unmixed) change.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
phillipsjk
Legendary
*
Offline Offline

Activity: 1008

Let the chips fall where they may.


View Profile WWW
December 15, 2013, 09:32:15 PM
 #324

I got into a argument with somebody on IRC in #bitcoin over the suitability of coinjoin transactions for annoymised verifiable e-voting. justanotheruser's argument was that he could always verify that his choice got a "vote". My argument was that since the voters don't share their votes with each other, it is possible to mis-allocate votes without detection (as long as you are not too greedy).

This has implications for "normal" coinjoin transactions as well:
If:
  • There are more than two participants
  • Two or more participants try to send coins to the same address without directly communicating with each other. (This includes trying to send mining fees)
Then:
  • It is possible for a bad actor to misdirect some of those funds for their own purposes.
  • For the attack to work,  the original output must have at least as much funds as any one participant sent.

This works because non-communicating participants can only ever check that their own outputs look correct. One way to mitigate this is to phase out address reuse: which has not yet happened in practice.

James' OpenPGP public key fingerprint: EB14 9E5B F80C 1F2D 3EBE  0A2F B3DE 81FF 7B9D 5160
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2226



View Profile
December 15, 2013, 09:40:32 PM
 #325

Excellent point!

As you note one workaround is don't reuse addresses— always good advice and here it doesn't have to be "phased out" in general but just by participants— but it's always better to be secure even if software is used dumbly.

I can suggest a trivial protocol addition that solves this without making the CJ transactions distinguishable or degrading privacy, but my solutions have some overhead. I'm curious if anyone can come up with a better way of doing it that doesn't have the overhead.

The general idea is that the merging party can just make a list (blindly) mapping their inputs to outputs, give the list to all players, and commit to the list so that all players know they got the same list.

Here is how it works:

The merging party makes a list with an entry for each output in the transaction. The entries have a nonce provided by each user either when they provide their input (or submitted their blindsigned tokens if blind signed tokens are in use). When they ask the users to sign they give the users the list and the users check and see that they are the credited party for every output they think they should be. Because they are just nonces they don't deanonymize users.

But to prevent the merging party from giving a different list to each user they must commit to it. I have two way to accomplish that:

The first is that we could require that a particular index in the outputs pay to an address which commits to the list: The merging party computes a new public key as an existing pubkey plus the H(list)*G, like a pay to contract, and a previously designated output pays to the resulting address. Given the list and original public key, everyone can check that that output commits to the same list. (And if two different users are given different lists, their signatures will not be merge-able since they would have signed different outputs).

(This designed output could belong to the merger or players could volunteer to have their output address placed in the designated position and to instead receive their payment at a pay-to-commit address. This is a little lame though, because it requires that there be at least one player that will tolerate receiving coins at a non-deterministic key.)

The second way to commit that I've come up with is to add an additional round to the protocol where you make a dummy transaction modified so that it won't ever be valid, e.g. using the list hash as an addition vin. Everyone signs this transaction and then only once they've seen this commitment signed by all the inputs will they sign the real transaction.

Needing an extra communications round or a non-deterministic output is kinda weak. Can better be done?

Bitcoin will not be compromised
mmeijeri
Hero Member
*****
Offline Offline

Activity: 714

Martijn Meijering


View Profile
December 15, 2013, 10:38:51 PM
 #326

Couldn't you just eject all but one of the partial transactions that use the same addresses from the current CoinJoin operation, maybe based on the lowest value of some appropriate hash?

ROI is not a verb, the term you're looking for is 'to break even'.
phillipsjk
Legendary
*
Offline Offline

Activity: 1008

Let the chips fall where they may.


View Profile WWW
December 16, 2013, 08:28:31 AM
 #327

Couldn't you just eject all but one of the partial transactions that use the same addresses from the current CoinJoin operation, maybe based on the lowest value of some appropriate hash?
Who does the rejecting, and why should they be trusted?

I think an implication of GMaxwell's work-arounds is that such outputs can't be merged (which I think would be the ideal case).

James' OpenPGP public key fingerprint: EB14 9E5B F80C 1F2D 3EBE  0A2F B3DE 81FF 7B9D 5160
mmeijeri
Hero Member
*****
Offline Offline

Activity: 714

Martijn Meijering


View Profile
December 16, 2013, 08:58:28 AM
 #328

Who does the rejecting, and why should they be trusted?

If it's an algorithmic decision, it doesn't matter, does it? But it was just something that popped into my mind, it's not a well thought out proposal.

ROI is not a verb, the term you're looking for is 'to break even'.
phillipsjk
Legendary
*
Offline Offline

Activity: 1008

Let the chips fall where they may.


View Profile WWW
December 16, 2013, 09:17:21 AM
 #329

The vulnerability is that the participants don't communicate their intentions with each other for fear of losing their privacy. (Address re-use has privacy implications on its own).

Algorithms are written by people. So they can be made to do thing you don't want. GMaxwell was making suggestions describing how people can share their intentions, without losing their privacy.

Edit: if we solve e-voting (as a side-effect), that would be a big achievement on its own.

James' OpenPGP public key fingerprint: EB14 9E5B F80C 1F2D 3EBE  0A2F B3DE 81FF 7B9D 5160
mmeijeri
Hero Member
*****
Offline Offline

Activity: 714

Martijn Meijering


View Profile
December 16, 2013, 09:21:43 AM
 #330

Algorithms are written by people. So they can be made to do thing you don't want.

Not if it's part of a protocol.

Quote
GMaxwell was making suggestions describing how people can share their intentions, without losing their privacy.

Sure, I'm not saying his suggestion wouldn't be superior, just that this might be a quick initial fix. If there aren't other problems with it that is. There very well might be.

ROI is not a verb, the term you're looking for is 'to break even'.
phillipsjk
Legendary
*
Offline Offline

Activity: 1008

Let the chips fall where they may.


View Profile WWW
December 16, 2013, 09:23:46 AM
 #331

Algorithms are written by people. So they can be made to do thing you don't want.

Not if it's part of a protocol.


The protocol would have to describe how the participants become aware of the conflicting outputs (and how cheating by the mixer is prevented).

James' OpenPGP public key fingerprint: EB14 9E5B F80C 1F2D 3EBE  0A2F B3DE 81FF 7B9D 5160
piotr_n
Legendary
*
Offline Offline

Activity: 1666


aka tonikt


View Profile WWW
December 16, 2013, 04:40:47 PM
 #332

I really don't understand all the applause and excitement on how "CoinJoin" is supposed to increase the users' privacy.

Are you kidding me?
This is not any new technology - personally I would not even call it an invention...
IMHO, it is rather a legal advise to use a plausible deniability in a possible cases against you.

At first it had been assumed (by some incompetent people) that all the inputs of a single transaction must always come from the same wallet (thus the same person).
What the author of the OP has invented is literally nothing - he only stated that technically inputs of a single transaction might just as well come from a completely different wallets - and this gives anyone a plausible deniability in any legal case (against him) that would be based on the assumption that all the inputs of a certain transaction came from his wallet.

In reality, assuming that you never disclose the content of your wallet (and if you did, CoinJoin won't help you anyway), you do not even need to find other parties to conduct CoinJoin!
You can just as well "CoinJoin" your own coins, as long as you are going to claim that they weren't all yours - and there will be no distinguishable difference whatsoever, from a CoinJoin tx made by a multiple parties.

CoinJoin does not create any additional privacy - it is actually less private than regular translations, since the process involves letting other people to know which coins are yours.
At best, it only gives you a reason to claim in court that not all the inputs were yours. The core of the "solution" here is a legal advise based on a technical properties of the bitcoin protocol.

So, not that I want to scare him, but as much as gmaxwell did not want to offend his big brother by helping to develop a software that would enable CoinJoin, he actually already did the most important part of the job by giving all the people the excuse that is the core of the invention here.

Therefore, since I am not so afraid of his brother, let me promptly point it out once again and remember: whenever anyone tells you that they traced your coins by "joined inputs" - just deny it and say that it was a CoinJoin transaction and not all the inputs were yours. Especially if it wasn't a CoinJoin transaction. 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
waxwing
Sr. Member
****
Offline Offline

Activity: 468


View Profile
December 16, 2013, 05:35:10 PM
 #333

Good point piotr_n. It makes you think about the game-theoretic infinite regresses going on here. I would really appreciate it if some people write plausible code into wallets for CoinJoin, because next time I am in despotic country X and the local thugs are rubberhosing my private keys out of me, I'd like them to be slightly less convinced that both those inputs were mine Smiley

PGP fingerprint 4668 9728 A9F6 4B39 1FA8 71B7 B3AE 09F1 E9A3 197A (use email to contact)
piotr_n
Legendary
*
Offline Offline

Activity: 1666


aka tonikt


View Profile WWW
December 16, 2013, 05:40:32 PM
 #334

Good point piotr_n. It makes you think about the game-theoretic infinite regresses going on here. I would really appreciate it if some people write plausible code into wallets for CoinJoin, because next time I am in despotic country X and the local thugs are rubberhosing my private keys out of me, I'd like them to be slightly less convinced that both those inputs were mine Smiley
If it makes you feel better my Gocoin already supports it, though I won't be going into details because as I said: it's pretty useless and all we need to make it even more plausible is a software that can do it, not the people to do it with, nor actually doing it.

Actually even the satoshi client supports it, ever since they added the create/sign raw transaction APIs.

So if you will ever need a court witness to demonstrate how easy it is to make a CoinJoin transaction, you know how to find me. 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
phillipsjk
Legendary
*
Offline Offline

Activity: 1008

Let the chips fall where they may.


View Profile WWW
December 16, 2013, 05:58:29 PM
 #335

Are you kidding me?
This is not any new technology - personally I would not even call it an invention...
IMHO, it is rather a legal advise to use a plausible deniability in a possible cases against you.

...

CoinJoin does not create any additional privacy - it is actually less private than regular translations, since the process involves letting other people to know which coins are yours.
At best, it only gives you a reason to claim in court that not all the inputs were yours. The core of the "solution" here is a legal advise based on a technical properties of the bitcoin protocol.

Privacy is not only for plausible deniability in a legal case against you: as waxwing alluded to, it is also designed to give plausible deniability if local thugs figure out you frequent a Bitcoin accepting shop and likely have a fat wallet.

I am not convinced doing coinjoin transactions with yourself gives the same deniability. You would first have to split your funds (a good idea anyway with the relentless climb in value), then mix them. However, without other parties, the spitting and mixing with no external links will look obvious on a graph of transactions.

James' OpenPGP public key fingerprint: EB14 9E5B F80C 1F2D 3EBE  0A2F B3DE 81FF 7B9D 5160
kjj
Legendary
*
Offline Offline

Activity: 1302



View Profile
December 16, 2013, 06:00:55 PM
 #336

IMHO, it is rather a legal advise to use a plausible deniability in a possible legal cases against you.

...

CoinJoin does not give you any additional anonymity. At best, it only gives you a reason to claim in court that not all the inputs were yours. The core of the "solution" here is a legal advise based on a technical properties of the bitcoin protocol.

Coinjoin will be worthless in court.  Your case is not going to prosecution when the sole evidence is a bitcoin transaction.  Instead, that transaction is going to be used as the basis for collecting gobs and gobs of further evidence.  At that point, the coinjoin isn't going to help you in court, it is going to hurt you, since it will be evidence that you knew what you were doing was wrong and tried to bury the evidence.

We need massive large scale joining for two reasons.  One, if joining is routine, then you doing it isn't going to be evidence of wrongdoing anymore.

Two is to muddy the waters for mass surveillance.  Right now, it is nearly trivial to trace transactions back and forth until it lands on a discoverable point.  Assume for the moment that the NSA has total visibility into some exchange's HTTPS traffic and can see every deposit address they provide to users.  When your chain of transactions lands on one of those addresses, the FBI knows they just need to request the customer info for whichever account uses that address, and they've got you.

Now imagine the world with coinjoin.  Your coins break up and land in a dozen joint transactions.  From there, each one hits a dozen more, and a dozen more, and so on.  Now there are thousands or millions of things to track, and almost all of them will not be yours.

p2pcoin: a USB/CD/PXE p2pool miner - 1N8ZXx2cuMzqBYSK72X4DAy1UdDbZQNPLf - todo
I routinely ignore posters with paid advertising in their sigs.  You should too.
piuk
Hero Member
*****
expert
Offline Offline

Activity: 910



View Profile WWW
December 20, 2013, 12:17:37 AM
 #337

Sharedcoin transactions on blockchain.info lowered to 0.0001 BTC per repetition. On average 1.8 unique participants are joining in together each transaction, so over several repetitions there is a very good chance your transaction will be directly mixed with other users not just the sharedcoin server.

When did that happen? That's a major change that deserves a large announcement. Are they using BIP32 to derive the new addresses?

It's just for Sharedcoin transactions and not BIP32 yet but I hope that will be available soon.

justusranvier
Legendary
*
Offline Offline

Activity: 1400



View Profile WWW
December 20, 2013, 12:21:57 AM
 #338

It's just for Sharedcoin transactions and not BIP32 yet but I hope that will be available soon.
That blockchain.info encourages address reuse is really the only significant complaint I have with your service.

Fixing that would be a great thing for privacy.
Trader Steve
Hero Member
*****
Offline Offline

Activity: 825


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


View Profile
December 20, 2013, 12:41:43 AM
 #339

Sharedcoin transactions on blockchain.info lowered to 0.0001 BTC per repetition. On average 1.8 unique participants are joining in together each transaction, so over several repetitions there is a very good chance your transaction will be directly mixed with other users not just the sharedcoin server.

When did that happen? That's a major change that deserves a large announcement. Are they using BIP32 to derive the new addresses?

It's just for Sharedcoin transactions and not BIP32 yet but I hope that will be available soon.

Great service!
andytoshi
Full Member
***
Offline Offline

Activity: 169

-


View Profile
December 23, 2013, 02:42:52 AM
 #340

For those willing to futz around with raw transactions, I have a simple centralized coinjoiner available here:

https://www.wpsoftware.net/coinjoin/

Basically, once you submit a transaction this opens a 15-minute window for others to submit a transaction. After the 15 minutes are up, the transactions are merged and everybody signs the merged transaction. Once all the signatures are received, the joiner submits the transaction.

Thanks very much to my testers, in particular gmaxwell and midnightmagic, for their excellent suggestions and bug-finding.
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 »
  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!