Topic: CoinJoin: Bitcoin privacy for the real world - page 22. (Read 294672 times)

You don't need to add it to the protocol, CoinJoin operates just fine at a strictly higher level. But I suppose you mean adding support to the reference wallet for CoinJoin transactions? I would not be surprised to see that happen, but someone needs to write the code first.

Have any Bitcoin core developers said anything about adding CoinJoin into the protocol?

Bump for this thread because it is important for Bitcoin

I considered this, but there's the extra advantage that nobody knows for sure if a single entity in the loop is indeed a single entity.  Consider a figure 8, where node C is at the apex, and when he receives the transaction, it's passed around a similar set of other nodes and returning back to C, he forwards it on in the other loop.  You'd have to control a large number of nodes in such a network to be able to produce any real association.


Do you have any more information on how a reencryption mix works w.r.t. CoinJoin?


True - it's especially problematic as N goes larger.  Worst case, you have to assume everyone in the group is against you.  Limit yourself to a low number of rounds and try other peers if the # of rounds is exceeded.  You could theoretically build a list of trusted peers where previous successful CJs have been executed, too.  All this is just workaround for a fundamental problem, though.

Brought forward

If the parties immediately before and after you in the loop are conspiring (or sibyls) then they can always tell which inputs/outputs you added, so this is less private than some of the schemes proposed, in which N-2 malicious parties in an N way join cannot tell the 2 honest parties apart, for all N>2 (assuming you have underlying anonymous communication).

Your protocol sounds somewhat similar to a reencryption mix, except a reencryption mix doesn't need the chaff because the values are encrypted. A problem with using them for CJ is that protocols to prove faithful operation (e.g. to catch a party trying to break it) are computation and bandwidth intensive. One of their upsides (also— somewhat the case for yours) is that they are not so dependent on an underlying anonymity network (also the case for a MPC sort).

I think another potential issue in your protocol is that someone can just keep changing inputs/outputs forever to jam it, and you can't tell who is doing it (well, not anymore than you can tell who is who absent a jammer).

Would this strategy work?

Take N>3 coin joiners wishing to mix their coins and give them an order: A to B to C to D to E and back to A, forming a circle.

A is responsible for creating the first transaction. We proceed in rounds, each person receives the transaction from the person before them and forwards it to the next guy, where E returns it to A to form a circle.

Each person, upon receiving the transaction does the following:

If the received transaction is completely signed, then either forward the transaction onto the next guy or broadcast it to the bitcoin network. Forward randomly so the next in line can't figure out who signed last.

Otherwise, randomly add unspent inputs (from the blockchain utxo set) to the transaction and then add some random outputs. The inputs and outputs don't need to be owned by the person adding them, but eventually you need to include your final inputs and outputs. Next, select a few inputs added in a previous round and remove them (in the first round there will be nothing to remove). Do the same for outputs. Don't remove inputs or outputs that others added because they will assume you're trying to cheat and leave.  In a later round, say 2 or 3, optionally sign one of your real inputs. If a successive person changes the tx again, you'll have to resign in another, later round.

Continue rounds until all fake inputs and outputs have been removed and the remaining inputs have been signed.

The obvious downsides include having to resign multiple times, the potential for lots of rounds, and not scaling well to large values of N. Any other thoughts?

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.

Great service!

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.

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.


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

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.

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.

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.

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

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.

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

Not if it's part of a protocol.


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.

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.

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.

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