pull down to refresh

CoinJoin Probing Attack: Analysis and Countermeasuresjoinmarket-ng.github.io/coinjoin-simulator
2279 sats \ 2 comments \ @supratic 1 May bitcoin

The Problem: Privacy in CoinJoinThe Problem: Privacy in CoinJoin

CoinJoin is a collaborative Bitcoin transaction where multiple participants combine their inputs and outputs into a single transaction. When done correctly, an outside observer cannot determine which input funded which output, providing transaction privacy.

Key TakeawaysKey Takeaways

  1. CoinJoin probing is a real privacy threat. Without countermeasures, a moderately resourced attacker can deanonymize the majority of honest takers through the information cascade from probing.
  2. Three countermeasures are individually effective: capping UTXOs per offer, isolating flagged UTXOs, and sticky disclosure each eliminate deanonymization on their own. They work by limiting or poisoning the information the attacker collects.
  3. Initiation fees are necessary but not sufficient. They raise the attacker's cost but do not stop the information leakage that enables deanonymization. Fees complement information-limiting measures.
  4. The recommended policy combines all layers. It achieves zero deanonymization even under sustained, pre-probed, high-intensity attacks. The defense is robust across all tested scenarios.
  5. Recovery is slow without mitigations. After a 2-week attack ends, the baseline needs ~12 more days to recover. With the recommended policy, there is nothing to recover from.

Simulation source and raw data: https://github.com/joinmarket-ng/coinjoin-simulator | Curated dataset: publish_summary.json

write
compose
related posts
0 sats \ 0 replies \ @unknown_ 1 May freebie

If probing can cascade into large-scale deanonymization, does this imply that CoinJoin privacy is inherently unstable under sustained adversarial pressure?

Even with countermeasures like sticky disclosure and UTXO isolation, are we just increasing attack costs rather than eliminating structural leakage?

Curious how this compares to alternative privacy approaches that don't rely on coordination.

1 sat \ 0 replies \ @366aad5d38 2 May -30 sats

Probing attacks on CoinJoin coordinators are interesting because the attack surface scales with the very property that makes the protocol useful — open participation.

The structural problem is that every probe request is also a valid join request. A coordinator can rate-limit per identity, but in a permissionless setting identity is cheap to mint. Reputation systems push the cost up but don't change the asymmetry; one attacker controls many "users", each individually below the noise floor.

Two countermeasure directions worth distinguishing:

  1. Coordinator-side mitigations — proof-of-work tickets, blinded credentials, or stake commitments. These raise the per-probe cost but penalize legitimate small participants the most, since they pay the same toll on every join.
  2. Round-design mitigations — receiver-anonymous outputs, ephemeral coordinators, or covenant-based atomic mixing. These shrink the leakage window rather than gating entry. The tradeoff is operator complexity and harder dispute resolution when a round stalls.

The cleaner long-term path is probably round-design rather than coordinator-side, because cost gates only delay a determined adversary while structural mitigations actually reduce the information leaked per round. Curious whether the paper quantifies that distinction or treats both buckets symmetrically.