156 / 691CHAINAL

Chain Surveillance

Blockchain monitoring and inference about real-world entities

Chain Surveillance combines public transactions with estimates of common control and external data; a conclusion is only as reliable as its weakest supported attribution step.

Chain Surveillance systematically monitors Bitcoin’s transaction graph to infer flows, address groups and their links to entities. It combines directly verifiable data with heuristics and external labels. A transaction record, common key control and a person’s identity are three different levels of claim.

A transaction specifies the previous outputs it spends and the new outputs, amounts and conditions it creates. The UTXO graph establishes output relationships, not a payer’s name or IP address. The protocol does not normally label outputs as payment or change, nor assign individual input satoshis to specific outputs. A colored flow trace in an analytical tool may incorporate an additional value-allocation rule that must be disclosed. [Bitcoin Developer Guide — Transactions]

The common-input ownership heuristic links a transaction’s inputs because an ordinary wallet uses its own coins. Inferred change may attach an output too. These are not consensus rules: CoinJoin and Payjoin allow inputs from different participants without sharing private keys. BIP 78 provides a concrete counterexample in which the receiver adds its inputs. A shared transaction therefore does not establish a single owner without additional assumptions. [Meiklejohn et al. — A Fistful of Bitcoins] [BIP 78 — A Simple Payjoin Proposal]

Service attribution can originate in a documented interaction, a published address or a counterparty record. Each label needs an author, supporting basis and applicable period. An exchange can control many clients’ coins, while one entity can use multiple clusters. A cluster therefore is not a count of people, and a service address does not automatically identify a particular customer or the purpose of each payment. [Meiklejohn et al. — A Fistful of Bitcoins]

Goldfeder et al.’s 2017 study examines links between purchase data, the blockchain and web identifiers. A practical model combines an amount, time window or payment address with a cookie or account. This is another information source, not identity stored in a transaction. Results from one historical sample are not today’s universal surveillance success rate. Previously retained metadata can nevertheless support later retrospective linkage. [Goldfeder et al. — When the cookie meets the blockchain]

An IP address can be logged during connections or transaction relay, but it is not a Bitcoin output field. A node also relays other people’s transactions, so the first observed peer need not be the original sender. Tor can reduce linkage between network traffic and an IP; it does not change published amounts or UTXO relationships. Assessment must distinguish what an observer saw on the network from what they inferred from the blockchain. [Bitcoin — Protect your privacy]

During transitive merging, a false edge can combine two large groups into an incorrect supercluster. Möser and Narayanan examine constraints on such cluster collapse and acknowledge assumptions and biases in derived reference data. For your own evaluation, report false merges, missed links, coverage, period and label-validation method. Without calibration against known cases, a tool’s score cannot automatically be read as the probability of a correct identity. [Möser and Narayanan — Resurrecting Address Clustering in Bitcoin]

Fresh receiving addresses reduce direct reuse, but a later joint spend can create another link. Payjoin disrupts the common-input assumption; it erases neither the public graph nor information already held by a merchant. A personal node reduces the need to disclose queries to an external backend, not the visibility of confirmed transactions. A meaningful assessment specifies the observer and linkage being addressed instead of promising complete anonymity. [Bitcoin Developer Guide — Transactions] [BIP 78 — A Simple Payjoin Proposal] [Bitcoin — Protect your privacy]

For each claim, record the transaction or output, label source, heuristics, date and alternative explanations. Distinguish direct payment from multi-step graph connectivity, and key control from economic ownership. A risk score or graph distance is not independent proof of a person’s identity or actions. This is a derived quality-control procedure: new evidence must allow a conclusion to be revised without turning the original assumption into a supposedly independent fact. [Meiklejohn et al. — A Fistful of Bitcoins] [Möser and Narayanan — Resurrecting Address Clustering in Bitcoin]

For the clearest picture, read this entry together with Bitcoin Privacy, Common-Input Ownership Heuristic, Address Clustering, Transaction Labeling, CoinJoin, PayJoin. The reverse links also lead from Change output, Common-Input Ownership Heuristic, Address Clustering, Ross Ulbricht.

DOC · 001Bitcoin Developer Guide — TransactionsDocumentationDOC · 002Meiklejohn et al. — A Fistful of BitcoinsPrimaryDOC · 003Goldfeder et al. — When the cookie meets the blockchainPrimaryDOC · 004Möser and Narayanan — Resurrecting Address Clustering in BitcoinPrimaryDOC · 005BIP 78 — A Simple Payjoin ProposalSpecificationDOC · 006Bitcoin — Protect your privacyDocumentation
Source-first · No investment advice