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.

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.

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.

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.

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.

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.

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.

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

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.