Ah, it took some time but he has finally signed it .

If anyone knows how to make JSON-RPC calls through Rust (or C), I'd be able to (a) do my own 'sendtoaddress' equivalent, and (b) check for double-spends, excessive fees, negative fees, etc, and flag these as errors.

Right now I only check things intrinsic to the transactions -- for merge-unsigned, I ensure there are no duplicate inputs; for merge-signed, I ensure that all transactions are identical modulo scriptSigs.

It's not terribly important to do lockunspent -- if somebody double-spends, the coinjoin will be invalid. Presumably they wanted to do the coinjoin, so they've just screwed themselves. So any double-spend blocking is purely a usability feature.

Hey, um, stupid question, and I'm just too drowsy to wrap my head around it, but if I use CounJoin on blockchain.info, where I have one input and one output, and sent 5 BTC through, with 5 BTC coming out on the other end, isn't it still fairly easy to track my 5 BTC,simply because that's the amount that went in and came out?

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 don't re-assemble them into the original amounts. Why would you want to do that?

Then that's what bc.i does. That's not the protocol described in this thread.

Assuming you use a single input of the exact size then it will be recombined into the same output value. But the client will deliberately select more inputs than necessary in order to make determining the input value more difficult. The server will also add multiple outputs of the same size as your inputs.

Even if you are restricting outputs to power of two sizes, as in the original coinjoin proposal, the same issue is still a problem. Address A sends 2 * 0.1 BTC + 1 * 1 BTC outputs then Address BTC receives 2 * 0.1 BTC + 1 * 1 BTC soon after it is easy to connect the dots.

Mixing in the background rather than on demand is probably the best way to solve this.

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.

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.

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?