The Common-Input Ownership Heuristic assumes that multiple inputs in a Bitcoin transaction — references to earlier amounts being spent — are usually controlled by the same entity. It uses wallet behavior to identify related addresses. It is an analytical clue, not a Bitcoin rule or proof of who owns the money.
Peter receives two payments at different addresses. Later, when paying for a bicycle repair, his wallet spends both receipts together. A wallet is an application or device for receiving and sending bitcoin. An outside observer now sees a connection that was not visible in the separate receipts: someone managed to spend these funds in one transaction. For an ordinary personal wallet, it makes sense to suspect common control. This behavior underlies the heuristic, a practical rule for making an estimate. Bitcoin does not require all inputs to have one owner, however. Nor does a larger number of inputs by itself tell us the probability that the estimate is correct. [1] [6]
Received funds exist as UTXOs, unspent outputs of earlier transactions. Each output records an amount and the conditions for spending it. An input in the new transaction points to one specific earlier output. The analyst retrieves its spending conditions, expressed as a script, a short program setting the spending rules, and links the corresponding address or script with those of other inputs. That is the method’s precise scope. A single-input transaction supplies no new pair to connect. The rule also does not identify which new output is a payment and which is change, the remainder returning to the payer. That needs another clue. The repair shop’s output therefore cannot automatically be assigned to Peter merely because it appears in his payment. [1] [4]
Peter and another person can prepare a joint transaction, each signing their own inputs. Their private keys, the secret numbers used to create signatures authorizing bitcoin spending, remain separate. PSBT is a format for passing an unfinished transaction and supporting information between programs or devices, described in BIP 174. A coordinator assembling those details need not hold all the keys. The network checks whether spending conditions have been met, not whether one person produced every signature. Multisig addresses a different question: it may require several signatures for one input, whereas this heuristic estimates the relationship between multiple inputs. [2] [5] [6]
CoinJoin lets several participants contribute their own funds to a joint transaction. Payjoin demonstrates the problem within a payment: under BIP 78, the recipient can add their own inputs too. If the repair shop accepted such a payment, blindly applying the heuristic could merge its funds with Peter’s. Collaboration does not require every output to have the same amount. Excluding transactions that look like obvious CoinJoin is therefore not enough to declare all remaining transactions single-owner payments. This does not mean every transaction is collaborative; it means appearance alone does not always rule that possibility out. [2]
Imagine addresses A, B and C. One transaction spends outputs from A+B together. Another combines different outputs from B+C. This does not spend the same UTXO twice. Through the shared B, a tool may merge them into A+B+C, one group or cluster. But if the second transaction involved different people collaborating, the mistake also affects the previously assigned address A. Errors can spread between entire groups this way. A small number of incorrect links therefore does not guarantee a small number of incorrectly attributed addresses. [1] [3]
An exchange can spend funds it manages for many customers in one transaction. The heuristic may correctly identify common operational control by the service. It does not establish which customers have the economic interest in the funds. Even the service’s name cannot be read from the inputs alone: a label needs additional evidence and must apply to the period concerned. Conversely, Peter may have several wallets whose funds he never combines. Counting the discovered groups therefore does not simply count people. Control, ownership and identity are related but distinct questions. [1]
An analyst wants to know whether an address link was correct. If the only confirmation is another joint spend, the same assumption may simply be repeated. That does not automatically supply independent evidence. Malte Möser and Arvind Narayanan describe using this kind of reference data and its limitations. An evaluation should therefore state where its sample comes from, which transactions it excludes and what period it covers. Incorrect merges, missed connections and coverage should be assessed separately. Without calibration against known cases, a score cannot be interpreted as the probability of correctly identifying a person. [3]
Peter can use Coin Control, manually choosing which UTXOs to spend, to limit future linking of previously separate receipts. This does not erase earlier transactions and requires understanding the funds being selected. Payjoin does not eliminate all other ways of making an attribution either. For analysis, each link should be traceable to a transaction, rule version and reason for inclusion or exclusion. These review questions follow from the limitations in the sources. When an error is found, it must be possible to determine again which addresses belong in the group; merely adding a note to an unchanged conclusion does not repair incorrect assignments. [2] [3]
For the clearest picture, read this entry together with Address Clustering, CoinJoin, Payjoin, Chain Surveillance, PSBT, Coin Control. The reverse links also lead from Payjoin, Coin Selection, Chain Surveillance, Address Clustering.