Timing correlation and slow mode

[AdamISZ]

For attempting to mix in with the larger anonymity set, it is obviously unhelpful that in the simplest form, a coinswap will consist of 2 pairs of transactions of (a) the same size and (b) being broadcast at approximately the same time.

It's worth observing that even though this correlation is obviously a big deal, it's only so for the more sophisticated snoopers; any snooping currently based on history and not taking a global blockchain view would be broken; and also in case of very high volumes the correlations get harder rapidly, depending on (a).

W.r.t (a), amount correlation is deferred to another issue, w.r.t. (b):

Default behaviour should probably be to stagger the broadcasts in a somewhat random way. The protocol needn't be changed much: TX0 can broadcast as normal, TX1 can wait for a preset random delay (best to be agreed in advance in private in the CoinSwapPublicParameters), and Alice's see_tx0_tx1 can be recoded to accommodate this. The same can go for a delay between Alice's TX5 broadcast and Carol's TX4 broadcast; for this one, Alice can fortunately ignore the delay since she already has the funds; this reduces Alice's slowdown to one of the two delays.

This may well interact with #8 in the following sense: a slow mode will lock up Carol's liquidity for a longer time, so it may require higher fees.

I'd envision this being a fast option on command line, defaulting to False, with a warning about privacy in case it's disabled. More tricky is to think about what kind of random distribution is appropriate.

I've specifically marked this milestone 0.1 as I think a decent mainnet implementation really must have this at least to make timing correlation problematic, if not impossible for an attacker.

[AdamISZ]

Additional note: the simple proposal above would have the disadvantage of leaving fixed the orders of the two pairs (TX0, TX1), (TX5, TX4) which may be considered to give the attacker/snooper information unnecessarily. This could be obviated fairly simply by randomising the order of TX0 and TX1 but that would require checking against the backout scenarios (currently TX0 goes out before TX1 iirc).

[chris-belcher]

Some brief maths:

Today each block happens at 10 minute intervals and has about 2500 transactions inside. The anonymity set of coinswap is the number of all other transactions happening in bitcoin between TX0/TX1 and TX4/TX5. So the anonymity set goes up linearly with time. If we waited 144 blocks (one day) we get about 360,000 transactions that could be mistaken for us.

This is oversimplified of course. It assumes we use pallier crypto to make transactions use p2pkh. Also some transactions today have a structure that makes them obviously not coinswaps (such as this localbitcoins withdrawal), so they can be eliminated. Also I've assumed there's no amount correlation. I believe that can be fixed by having multiple transactions for each of TX0/TX1 and TX4/TX5 that together add up to the correct amounts. About to write an issue on this.

For the random distribution to get wait times from, I think just uniform distribution is fine. Anything else helps narrow down the search space for any spy adversary. (I know joinmarket's tumbler.py uses distributions for wait time but tbh I just made them up and they have no justification)

[AdamISZ]

Yes, larger times increases anonymity set, which is a strong upward incentive on times - assuming good randomization can be achieved. Security, same. The downward incentive is liquidity lock up, and practicality issues.

Multiple txs: this crossed my mind too, but I haven't even begun to look into it.

Further to the above: amount correlation: yes I mentioned above will want to open an issue on it. Feel free to do so first, especially if you have some fleshed out thoughts about it already (I don't!).

[AdamISZ]

For the random distribution to get wait times from, I think just uniform distribution is fine. Anything else helps narrow down the search space for any spy adversary

Seems sound. Keep structure to minimum.

[chris-belcher]

If it helps, you could argue liquidity lockup is a good thing from the point of view of makers because they can rent out their bitcoins for longer and earn more income. =D