Address Clustering

Anna uses new addresses for different receipts and later pays a shop from her wallet. A wallet is an application or device for receiving and sending bitcoin. An analyst sees money moving but must ask two separate questions: which funds were spent, and which addresses might be controlled by the same entity? The shop payment answers the first question. It is not itself a reason to group Anna with the shop. Address Clustering looks for other clues to common control, such as spending several receipts together. A payment diagram therefore shows actual transaction connections, while colored groups add an interpretation. Keeping the two apart is essential when reading these maps. [1] [5]

Previously received funds are recorded as UTXOs, unspent transaction outputs. Each output records an amount and the conditions for spending it. A new input points to one specific earlier output, not a universal “sender address” field. The tool retrieves the original scriptPubKey, the conditions under which that output can be spent. For supported types, an address is a convenient representation of those conditions; not every script has a conventional address. A careful explanation must distinguish whether it groups addresses or scripts and specify the network and block range. A block groups transactions into a batch added to the shared history. A technical identifier does not thereby become a person’s identity. [4] [6]

The Common-Input Ownership Heuristic assumes common control of several inputs in one transaction. Identifying change is a separate step: it looks for the output returning the unused remainder to the payer after the payment and fee. A correct guess can connect Anna’s new change address to her earlier receipts. Mistaking the shop payment for change instead links someone else’s funds. Two outputs alone do not settle which is which. They could represent two recipients or transfers between personal wallets. A previously unseen address is not, by itself, proof that it belongs to the payer. [1] [3]

A rounded amount, script type or reused address can be a clue, not an immutable rule. A wallet update can build transactions differently and cause an older model to fail. CoinJoin allows several participants to share a transaction; with Payjoin under BIP 78, the recipient can add their own inputs. Collaboration need not produce outputs with equal amounts. Historical accuracy therefore cannot be promised for today’s transactions without fresh evaluation. It also matters which cases the method leaves without a prediction. [2] [3]

Imagine two previously separate address groups. One incorrect link can merge them and spread the mistake to all their members. Programs often use union-find, a data structure for tracking connected groups, to perform merges efficiently. Its conventional form cannot remove an old link and automatically split the result correctly. For auditable analysis, the practical recommendation is to retain transactions, individual links and rule versions, not just the final address list. This follows from the error propagation described in the research: correction can require recomputation, rather than merely renaming the group. [2]

Malte Möser and Arvind Narayanan study how to prevent cluster collapse, the incorrect merging of many groups into a large one. Their constrained union-find rejects merges between groups linked by a predicted payment output. Returning to Anna, a prediction that she is paying the shop can prevent the two sides from later being merged. This safeguard does not know the truth independently: it relies on the payment prediction and can reject valid links. Fewer merges therefore do not automatically produce a complete or error-free picture of owners. [2]

Labeling one address with an exchange’s name and extending the label to a whole cluster are separate steps. A label needs a source, a period of validity and a traceable path of propagation. An exchange-controlled group may also serve many customers. Model validation should not rely only on data created using the same assumption. Incorrect merges, missed connections and sample coverage need separate evaluation. A large number of labeled addresses does not itself guarantee correct attribution. [1] [2]

Anna may move funds between two of her own wallets. If the model does not link them, it may count the movement as a payment between separate entities. Improved grouping can recognize it as an internal transfer, or self-churn, reducing estimated payment volume without changing the blockchain history. Likewise, a cluster’s balance consists of its still-unspent UTXOs at a specified block; adding up all past receipts would include money already spent. When comparing charts, check not only the date but also the model version, labels and data cutoff. [1] [2]