What Bitcoin clusters prove and what CoinJoin and Payjoin break

A Bitcoin cluster is something an analyst constructs, not something the blockchain records. When a tracing report says several addresses belong to one entity, that is a statistical inference, and its soundness depends on the specific transactions it was applied to. Collaborative transaction formats such as CoinJoin and Payjoin exist precisely to defeat the assumptions that inference relies on. This guide explains what clustering proves, when it holds, and how to test it in a report you are evaluating.

Why Addresses Are Not Accounts

Bitcoin has a public ledger of transactions, and a transaction, as Meiklejohn et al. defined it, transfers funds between public keys (Meiklejohn et al., A Fistful of Bitcoins, IMC 2013). Every transaction consumes already-existing outputs and creates new ones, and an output can be spent exactly once and in full, with any surplus going to fees or back to the spender.

To pay 0.4 bitcoin while holding a single output of 1 bitcoin, a wallet does not write a 0.4 bitcoin check. It spends the full output and creates two new ones: 0.4 bitcoin to the recipient and roughly 0.6 bitcoin, minus the fee, back to a fresh address it controls. That return output is the change, and recognizing change is one of the oldest techniques in blockchain analysis.

A Bitcoin address identifies a spending condition, often one involving a public key, and nothing stops one person from generating thousands of them; standard wallet design discourages reuse and issues a fresh address for each payment. A person's holdings therefore sit across many addresses with no on-chain marker connecting them. The blockchain records addresses, not people. An analyst must reconstruct the person, and clustering is that reconstruction.

What the Common-Input Heuristic Assumes

The most powerful clustering rule is the common-input heuristic: when one transaction spends two or more inputs, those inputs are presumed to be controlled by the same entity. The intuition is that spending an output requires satisfying its spending conditions, so a transaction assembling inputs from addresses 1A and 1B looks like one wallet pulling together its own funds.

The heuristic was stated and tested in that 2013 study. The authors clustered addresses by shared inputs and by behavior such as repeated payments to the same services, then re-identified clusters through controlled purchases, specifically to expose what they called "idioms of use" in real wallet software. The paper presents the common-input rule as Heuristic 1 and notes that earlier work had already used it.

The Assumptions, Stated

The rule depends on three assumptions:

1. A single wallet constructed the transaction and selected every input.
2. The inputs are authorized by one person or entity.
3. No one collaborated to place different parties' inputs in one transaction.

The third assumption is the vulnerable one, because the Bitcoin protocol does not require it. Signatures inside a transaction are independent of each other: the transaction is valid if every input carries a correct signature, and the network neither knows nor cares whether one, ten, or fifty people signed it.

Gregory Maxwell made exactly this point in August 2013 when he introduced the term CoinJoin in a forum post (CoinJoin: Bitcoin privacy for the real world). Spending multiple addresses in one transaction, he wrote, is suggestive of common control but does not prove it, because users can agree on a set of inputs and outputs and then sign independently. Even when all three assumptions hold, a cluster is a group of addresses, not a person, and it says nothing about identity, which is a separate layer of analysis.

What the Change-Address Heuristic Assumes

Change detection is the second pillar. Because the full value of a transaction's inputs must be accounted for, a wallet that spends more than it pays must send the surplus somewhere, and the standard design is a change output back to an address the spender controls. The heuristic runs the design backward: given a transaction whose recipient output is known, the remaining output is change and belongs to the sender.

As a behavioral guess, it fails whenever behavior deviates. Meiklejohn et al. tested change-address definitions against the blockchain history then available, and their automated labeling flagged 555,348 candidate false positives, about 13 percent of labeled change addresses. A manual inspection of some of those candidates found many associated with Satoshi Dice and similar dice games, whose payouts return to the betting address and so look like reuse of a one-time change address. The lesson is that change is not marked on the blockchain. It is inferred from amount patterns, address freshness, and transaction shape, and each clue can be equivocal. Transactions with no change, round payments that resemble change, batched payments to several recipients, and payjoin all degrade the guess.

How CoinJoin Breaks the Common-Input Heuristic

CoinJoin combines Bitcoin payments from multiple spenders into a single transaction, making it more difficult for an outside observer to determine which spender paid which recipient. Participants agree on a shared set of inputs and outputs, often uniform output amounts, and sign only their own inputs; the transaction is invalid until every signature is present, and no participant will sign a version that does not pay them. The result is a transaction whose inputs are held by many different people, exactly the pattern the common-input heuristic reads as a single wallet.

Two consequences matter for litigation. First, a multi-input transaction can be collaborative, so an analyst should consider that possibility rather than treat common control as a given. Second, as Maxwell observed in 2013, if such transactions become widespread they improve the privacy even of people who never use them, because input co-spending stops being strong evidence of common control. A heuristic's reliability depends on the whole ecosystem, not just the transactions in your case.

Privacy Tools in Enforcement Cases

Public enforcement has put clustering, and the tools designed to defeat it, before juries. Bitcoin Fog was a cryptocurrency mixer. In March 2024 a federal jury in the District of Columbia convicted Roman Sterlingov of money laundering conspiracy and related counts for operating it. The service moved well over 1.2 million bitcoin from 2011 to 2021 (USAO-DC conviction press release). Prosecutors described tracing the funds through the blockchain (DOJ Office of Public Affairs). In November 2024 Sterlingov was sentenced to 150 months (USAO-DC sentencing press release).

In April 2024 prosecutors in the Southern District of New York charged the two co-founders of Samourai Wallet, alleging that the mixing service executed over $2 billion in unlawful transactions and laundered over $100 million in criminal proceeds (USAO-SDNY charging press release). Those charging figures were allegations. The same release describes Samourai's Whirlpool as coordinating batches of cryptocurrency exchanges among groups of users, the multi-input pattern the common-input heuristic reads as one wallet.

How Payjoin Breaks the Same Assumptions Without Mixing

Payjoin breaks the same heuristics with just two parties, while looking like an ordinary transaction. BIP 78, "A Simple Payjoin Proposal," assigned May 1, 2019, is a protocol for two parties to negotiate a coinjoin during a payment between them (BIP 78). In a normal payment the sender alone builds the transaction. In a payjoin the recipient adds one of its own inputs to the transaction that pays it and collects its own change, consolidating its coins while obscuring the sender's wallet structure.

The effect on clustering is blunt. A payjoin transaction contains inputs from two independent controllers, so applying the common-input heuristic merges the customer and the merchant into one cluster, and change identification becomes ambiguous because two possible change outputs belong to two different owners. BIP 78 is explicit about the design goal: it lets the sender invalidate the standard heuristics, and with the recipient's involvement the heuristics "can even be poisoned," meaning deliberately used to mislead blockchain analysis. The proposal also notes that by degrading the heuristics generally, it improves privacy for parties who never use it. The raw transaction does not label itself as a payjoin, so an analyst should not treat a routine-looking multi-input spend as proof of common control without considering the available context.

Hypothetical Example: A Cluster That Merges a Customer and a Merchant

Hypothetical example: A vendor report in a civil fraud case clusters addresses 1A, 1B, and 1C and states that the defendant controls all three. Transaction 1 has two inputs, 1A and 1B, and two outputs: 0.7 bitcoin to an exchange deposit address and 0.3 bitcoin back to 1B. The tool applies the common-input rule and assigns 1A and 1B to one cluster. Transaction 2 spends 0.3 bitcoin from 1B to 1C with no change output, and the change heuristic attaches 1C to the same wallet. The report now shows one defendant funneling funds from a three-address cluster into an exchange.

Change one fact: 1A belongs to a customer and 1B to a merchant who accepted a payjoin. The customer paid 0.7 bitcoin; the merchant contributed its own input and took its own change. Transaction 2 is the merchant moving its remaining funds to a second wallet. The actual facts show two unrelated people, and the defendant was never involved. The cluster is a false positive produced by applying a systemic heuristic to a transaction designed to defeat it, and every downstream conclusion about the defendant inherits the error.

From Cluster to Service to Person

A cluster is the first layer of attribution, not the last. Sound analysis distinguishes three layers:

1. Cluster: addresses linked by heuristics.
2. Service: contact with addresses attributable to exchanges or other businesses with identity records.
3. Person: account records, device evidence, or admissions tying the account to an individual.

A vendor's entity tag usually reflects layers 1 and 2. It is a cluster that the vendor has labeled with a name based on its own accumulated observations, and it is not identity. The blockchain alone cannot name a person; that step requires subpoenaed records and other off-chain evidence, as explained in Can Blockchain Transactions Be Traced?.

The February 2022 Bitfinex announcement illustrates how attribution actually lands. The Justice Department arrested Ilya Lichtenstein and Heather Morgan and charged a conspiracy to launder 119,754 bitcoin stolen in the 2016 Bitfinex hack. At the February 2022 arrest that stolen bitcoin was valued at about $4.5 billion, and the government announced a seizure of over $3.6 billion (USAO-DC press release). Both later pleaded guilty to money laundering conspiracy, and Lichtenstein was sentenced in November 2024 to 60 months (USAO-DC sentencing press release). The February 2022 IRS-CI affidavit states that agents traced the stolen funds on the Bitcoin blockchain as they moved across accounts and platforms. Naming the couple required off-chain material, including exchange account records in their names. A file in a Lichtenstein cloud account listing 2,000 addresses with their private keys was used to seize the remaining stolen wallet (Statement of Facts). On-chain analysis narrowed and corroborated the picture; the records that name people came from elsewhere.

What a Tracing Report Must Show to Withstand Scrutiny

Where a report rests on clustering, six things should be present, and their absence is a challenge lever:

1. Named heuristics, applied to identified transactions.
2. Transaction-level exhibits: hashes, inputs, outputs, and amounts for every linkage.
3. Confidence language. Clustering is probabilistic, and the report should say so instead of asserting that addresses "belong to" an entity.
4. Competing explanations. If a transaction could be a payjoin, a CoinJoin, a shared custody arrangement, or a batched payment, the report should explain why the inference survives in this specific case.
5. Verification of vendor labels. Which commercial platform tags were relied on, and what did the analyst verify independently?
6. A limitations section.

A report that offers only a dashboard screenshot and entity labels may invite a reliability challenge under Fed. R. Evid. 702 or, in Missouri state court, Mo. Rev. Stat. § 490.065. Two companion guides cover the attack and the common errors: How the Opposing Expert's Blockchain Analysis Can Be Challenged and Common Mistakes in Cryptocurrency Investigations. For building the affirmative case, ConsensusIntel's blockchain tracing services document methodology at the transaction level.

Deposition Questions for Cluster-Based Attribution

When a report's conclusions ride on clustering, these questions test the load-bearing joints:

1. Which heuristic placed each address in this cluster, and which transactions triggered it?
2. For each change output, what rule identified it, and what follows if that output belonged to the counterparty instead?
3. Did you test whether any transaction in the cluster is a CoinJoin or a payjoin under BIP 78, and if not, why not?
4. Did you validate this cluster against ground truth such as exchange records or admissions, or is it purely heuristic?
5. What is the false positive rate for this heuristic on modern wallet data, and did you measure it in this dataset?
6. If any two inputs in a clustered transaction were controlled by different people, which conclusions change?
7. Which entity tags came from a commercial platform, what did you verify independently, and can another analyst reproduce your method?
8. What off-chain evidence connects any address in this cluster to a named individual, and what does the blockchain evidence add beyond the cluster label?

Limitations

The heuristics described here were characterized on Bitcoin usage from the early 2010s, and the ecosystem has changed. Address reuse has fallen, wallets implement coin control, Lightning moves activity off the main chain, and collaborative protocols ship in mainstream software. Every such change degrades a heuristic's prior, and the degradation compounds: one misattributed address contaminates everything downstream of it in the transaction graph. Vendor methods are often proprietary, which can limit reproduction and testing. The fair summary is that clustering is a useful triage tool and a weak identity claim. Treat it as a lead to verify, not a fact to recite.

Frequently Asked Questions

Q: Does a cluster label mean the same person controlled every address?

A: No. A cluster is an inference that addresses share a controller, usually built from common-input and change patterns, and the inference can fail. A payjoin merges a customer and a merchant into one cluster; a CoinJoin merges many unrelated people; a shared custody wallet can group several people together. Identity is a separate question answered with off-chain records such as exchange account data, device evidence, or admissions, not with the cluster label.

Q: What is the difference between CoinJoin and Payjoin?

A: CoinJoin combines payments from many spenders into one transaction, often with uniform outputs, so an observer cannot reliably map payer to payee. Payjoin, standardized in BIP 78, is a two-party variant: during an ordinary payment, the recipient adds its own input, so the transaction can defeat input-based clustering for that payment.

Q: Do CoinJoin and Payjoin make blockchain tracing useless?

A: No. They break specific heuristics; the ledger, the amounts, the timing, and the points where funds touch exchanges remain visible. Attribution of an address to a person almost always depends on off-chain records. The practical effect is on confidence: a report that cannot exclude collaborative transactions in its dataset should state that its cluster labels are weaker than they look.

Q: If the other side relies on a commercial analytics tool, can I obtain its methodology?

A: The tool's outputs are disclosed with the report, but vendors often treat the underlying heuristics as trade secrets, and you may never see the code. The discovery fight should therefore focus on what the expert did with the output: which heuristics were applied, which transactions were tested, what ground truth was checked, and what was verified independently of the vendor. If the expert cannot defend those layers, you do not need the vendor's source code to make the point.

Every case is different, and no article can substitute for the facts of yours. If you are evaluating a tracing report that rests on clustering, contact ConsensusIntel for a conversation about the specific transactions. A short review of the exhibits usually reveals whether the cluster labels survive contact with the data.