Common-Input Ownership Heuristic is the analytical assumption that one entity usually controls the inputs of a Bitcoin transaction. It exploits ordinary wallet behavior; it is neither a consensus rule nor proof of a person’s identity.
Each input references an earlier UTXO. An analyst retrieves its output script and uses joint spending to connect the corresponding addresses or scripts. A single-input transaction creates no new pair under this rule. The rule alone identifies neither change nor the owner of the recipient’s output. [Meiklejohn et al. — A Fistful of Bitcoins] [Bitcoin Developer Guide — Transactions]
A wallet may select several of its own UTXOs for one payment. Spending them together exposes a relationship that separate incoming payments did not reveal. This is an observation about coin selection, not a protocol requirement; input count alone does not give the probability of a correct attribution. [Meiklejohn et al. — A Fistful of Bitcoins]
Participants can sign their inputs separately and assemble one valid transaction. PSBT under BIP 174 supports exchanging transaction data and signatures; a coordinator need not hold every private key. Validity demonstrates satisfaction of spending conditions, not a single human signer. Multisig within one input is a different question from common control across inputs. [BIP 78 — A Simple Payjoin Proposal] [BIP 174 — Partially Signed Bitcoin Transaction Format]
CoinJoin can combine inputs from several participants. In Payjoin under BIP 78, the receiver adds inputs to the sender’s payment; blind application would merge both parties. Equal output amounts are not required for such collaboration. Excluding only conspicuous CoinJoin therefore does not establish that remaining transactions have one owner. [BIP 78 — A Simple Payjoin Proposal]
This example uses addresses A, B, C, not repeated spending of the same UTXO: one transaction connects A+B, another spends different outputs from B+C. Transitive merging produces A+B+C. If the second edge comes from a collaborative payment, the error affects the earlier cluster too; a low false-edge rate need not mean few misattributed addresses. [Meiklejohn et al. — A Fistful of Bitcoins] [Möser and Narayanan — Resurrecting Address Clustering in Bitcoin]
An exchange can jointly spend UTXOs managed for many customers. The heuristic may capture operational control without identifying the funds’ economic owners. A service label needs independent provenance and a valid time period; conversely, one person can use several wallets never joined together. Cluster count is not a count of people. [Meiklejohn et al. — A Fistful of Bitcoins]
Validating a merge only through later joint spending can reuse the very heuristic being tested. Möser and Narayanan demonstrate the use and limitations of such reference data. Evaluation must describe sample provenance, excluded transactions and period, separating false merges, missed links and coverage. An uncalibrated score is not an identity probability. [Möser and Narayanan — Resurrecting Address Clustering in Bitcoin]
Retain the transaction, rule version and acceptance or exclusion reason for every edge. New counterevidence must allow cluster recomputation, not merely a note on an unchanged conclusion. Coin Control can limit future joint spending of separated coins but cannot erase history; Payjoin challenges this heuristic, not every possible source of attribution. [BIP 78 — A Simple Payjoin Proposal] [Möser and Narayanan — Resurrecting Address Clustering in Bitcoin]
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, Chain Surveillance, Address Clustering.