Privacy & Analysis
How transactions are traced
Research referenceSource: Reid & Harrigan, An Analysis of Anonymity in the Bitcoin SystemNo market data is used on this page; the heuristics and their reported error rates follow the published literature.
The heuristics in use
The foundational result in this area is the 2011 analysis by Fergal Reid and Martin Harrigan, which showed that the public transaction graph could be partitioned into clusters of addresses that behave as single actors. Their method rested on two observations. The first is that a transaction spending multiple outputs must have been authorised by whoever holds the keys for all of them, so the inputs are likely to share an owner. The second is that change from a transaction tends to return to an address the sender still controls, which lets an analyst follow a payment forward through a chain of spends. Neither observation is a rule of the protocol; both are regularities of how wallets behave.
Common-input ownership is the workhorse. It is cheap to compute, it applies to every transaction with more than one input, and it is correct often enough to be useful. Its weakness is that it is defeated by any transaction that deliberately combines inputs from different parties, and it produces false merges whenever a service sweeps deposits from many customers into one transaction. An exchange consolidation is, from the heuristic's point of view, indistinguishable from a single holder moving their own funds.
Change detection is the second pillar and the more fragile one. A transaction that spends an output larger than the payment must return the remainder somewhere, and the analyst wants to know which output that is. The classic signals are the output whose script type matches the inputs, the output that is not a round number, and the output that is later spent alongside the sender's other coins. Each signal is a guess. Modern wallets that use a distinct change address type, or that randomise output order, remove several of them at once.
Timing and network-level signals
The ledger is not the only place an observer can look. When a transaction is first broadcast, the node that relays it is the node that created it, and the peer-to-peer network is a graph of connections. An adversary who runs many nodes and watches which peer first announces a transaction can often infer the originating IP address, and an IP address is frequently enough to identify a person. This is a network-level attack rather than a ledger analysis, and it is the reason Bitcoin Core relays transactions for all of its peers by default rather than only for its own wallet.
Timing on the ledger itself is weaker but still informative. A transaction broadcast at an unusual hour, or one that spends an output seconds after receiving it, narrows the set of plausible actors. Analysts combine these weak signals with the strong ones rather than relying on them alone, and the combination is what makes the output of a commercial analysis look more confident than any single input justifies.
The practical implication is that privacy has two fronts. Ledger hygiene — avoiding reuse, controlling which outputs are spent together — addresses the analysis heuristics. Network hygiene, such as broadcasting through Tor, addresses the relay observation. A wallet that is careful on one front and careless on the other has not achieved much. The limits of analysis page covers where both fronts can be defeated.
Error rates and what they mean
The published literature is explicit that clustering is probabilistic. Reid and Harrigan's original work reported that their two heuristics together accounted for a large share of the transaction graph but left a substantial remainder unattributed, and later studies have measured the precision of individual heuristics against known ground truth and found error rates that vary widely with the population being examined. A heuristic that is accurate on ordinary consumer wallets can be badly wrong on exchange traffic, because exchanges generate exactly the multi-input patterns the heuristic misreads.
This matters because the output of an analysis is usually presented as a cluster with a label, and the label carries an implicit claim of certainty that the method does not support. A cluster labelled as a particular service may contain unrelated users whose deposits were swept together. A cluster labelled as one person may contain two people who happened to co-sign a transaction. The correct reading of any such label is "the analysis believes", and the strength of that belief is not published alongside it.
The honest summary is that tracing works well enough to be a real privacy consideration and poorly enough that it should not be treated as ground truth. The anonymous versus pseudonymous page sets out why the distinction between a cluster and a person is the one that matters.
Sources
- Fergal Reid and Martin Harrigan, An Analysis of Anonymity in the Bitcoin System — the original clustering analysis and the two heuristics it rests on.
- Bitcoin.org, Protect your privacy — the project's own warning that a currently untraceable payment may become traceable later.
- Bitcoin Core, Privacy features — transaction relay for all peers, and why the default behaviour matters for network-level tracing.
Related reading
- Privacy & AnalysisWhat the public ledger reveals, and the practices that change it.
- Anonymous vs PseudonymousWhy Bitcoin is pseudonymous, and what an address actually identifies.
- Address ReuseWhy reusing an address links every payment to it, and what wallets do instead.
- Coin ControlHow choosing which outputs to spend changes what an observer can infer.
- Change AddressesWhy a transaction sends value back to the sender, and how change is identified.
- Transaction BatchingHow combining payments lowers the fee per payment, and what it reveals.