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?

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

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

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.

Quote

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

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

Quote

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

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.

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

Bump for this thread because it is important for Bitcoin

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.

I'm an independent developer working on bitcoin-core, making my living off community donations.If you like my work, please consider donating yourself: 13snZ4ZyCzaL7358SmgvHGC9AxskqumNxP

Have any Bitcoin core developers said anything about adding CoinJoin into the protocol? Bump for this thread because it is important for Bitcoin

It doesn't need to be added to the protocol, thats part of the point.

If instead you mean the integrated Bitcoin-qt wallet, Wumpus and I have both commented that we'd like to see it there. I'd like to see more external implementation done first. Inside the wallet is good for getting users, but it's not good for protocol R&D.

In order to stand behind my signature below and support this effort I offer the following matching donation (inspired by Theymos):

I will donate 5 BTC as soon as the total in the fund goes over 36 BTC.

Done.

Our family was terrorized by Homeland Security. Read all about it here: http://www.jmwagner.com/ and http://www.burtw.com/ Any donations to help us recover from the $300,000 in legal fees and forced donations to the Federal Asset Forfeiture slush fund are greatly appreciated!

Our family was terrorized by Homeland Security. Read all about it here: http://www.jmwagner.com/ and http://www.burtw.com/ Any donations to help us recover from the $300,000 in legal fees and forced donations to the Federal Asset Forfeiture slush fund are greatly appreciated!

How does it work?Coins send with shared send will be matched up with another user. When a match is found your coins will be swapped breaking the transaction chain from your own wallet. Coins will be swapped with multiple users making the chain even harder to follow.

I found this very interesting (also from the same FAQ):

Quote

How can you guarantee that the transaction chain will be broken?There is no guess work involved, each shared transaction analyzes up to 50,000 outputs or 250 levels deep in the blockchain to ensure the coins sent to the destination address are 100% untainted with the original coins.

The source code for taint analysis calculations can be found on the Blockchain Github Project

Our family was terrorized by Homeland Security. Read all about it here: http://www.jmwagner.com/ and http://www.burtw.com/ Any donations to help us recover from the $300,000 in legal fees and forced donations to the Federal Asset Forfeiture slush fund are greatly appreciated!

As far as I can tell from the posts up thread the blockchain.info Shared Send system is a basic implementation of the centralized version of the proposal.

It's actually a plain mixing service that was implemented a long time ago, way before CoinJoin was proposed. They have a separate CoinJoin style transaction option that does use CoinJoin, but as far as I know, requires you to use a blockchain.info wallet, since CoinJoin has special nonstandard transactions. Fees are different, too, with 0.5% for Send-Shared, and a standard 0.0001BTC transaction fee for CoinJoin (with multiple mixes suggested, each one costing an extra 0.0001BTC)

As far as I can tell from the posts up thread the blockchain.info Shared Send system is a basic implementation of the centralized version of the proposal.

It's actually a plain mixing service that was implemented a long time ago, way before CoinJoin was proposed. They have a separate CoinJoin style transaction option that does use CoinJoin, but as far as I know, requires you to use a blockchain.info wallet, since CoinJoin has special nonstandard transactions. Fees are different, too, with 0.5% for Send-Shared, and a standard 0.0001BTC transaction fee for CoinJoin (with multiple mixes suggested, each one costing an extra 0.0001BTC)

Thanks for the info. I did not realize the two were different.

Our family was terrorized by Homeland Security. Read all about it here: http://www.jmwagner.com/ and http://www.burtw.com/ Any donations to help us recover from the $300,000 in legal fees and forced donations to the Federal Asset Forfeiture slush fund are greatly appreciated!

As far as I can tell from the posts up thread the blockchain.info Shared Send system is a basic implementation of the centralized version of the proposal.

It's actually a plain mixing service that was implemented a long time ago, way before CoinJoin was proposed. They have a separate CoinJoin style transaction option that does use CoinJoin, but as far as I know, requires you to use a blockchain.info wallet, since CoinJoin has special nonstandard transactions. Fees are different, too, with 0.5% for Send-Shared, and a standard 0.0001BTC transaction fee for CoinJoin (with multiple mixes suggested, each one costing an extra 0.0001BTC)

When there are two outputs to the same address with the same value (for example, two people want to donate 1 btc each to wikileaks), what prevents the service owner from swapping one of them with their own address?