Common-Input Ownership Heuristic suppose qu’une même entité contrôle généralement les entrées d’une transaction Bitcoin. Elle exploite le comportement des portefeuilles ordinaires ; ce n’est ni une règle de consensus ni une preuve d’identité personnelle.
Chaque entrée référence un UTXO antérieur. L’analyste retrouve son script de sortie et utilise la dépense commune pour relier les adresses ou scripts correspondants. Une transaction à entrée unique ne crée aucune nouvelle paire selon cette règle. Celle-ci seule ne détermine ni le change ni le propriétaire de la sortie du destinataire. [Meiklejohn et al. — A Fistful of Bitcoins] [Bitcoin Developer Guide — Transactions]
Un portefeuille peut sélectionner plusieurs de ses UTXO pour un paiement. Leur dépense commune révèle un lien absent des paiements entrants séparés. C’est une observation sur la sélection des pièces, non une obligation du protocole ; le nombre d’entrées ne donne pas à lui seul une probabilité d’attribution correcte. [Meiklejohn et al. — A Fistful of Bitcoins]
Les participants peuvent signer leurs entrées séparément et assembler une transaction valide. PSBT selon BIP 174 permet d’échanger données et signatures ; le coordinateur n’a pas besoin de toutes les clés privées. La validité atteste le respect des conditions de dépense, pas un signataire humain unique. Multisig dans une entrée est distinct du contrôle commun de plusieurs entrées. [BIP 78 — A Simple Payjoin Proposal] [BIP 174 — Partially Signed Bitcoin Transaction Format]
CoinJoin peut réunir les entrées de plusieurs participants. Dans Payjoin selon BIP 78, le destinataire ajoute ses entrées au paiement de l’émetteur ; une application aveugle fusionnerait les deux parties. Cette coopération n’exige pas des sorties de même montant. Écarter uniquement les CoinJoin visibles ne prouve donc pas un propriétaire unique pour les transactions restantes. [BIP 78 — A Simple Payjoin Proposal]
Cet exemple utilise les adresses A, B, C, pas une seconde dépense du même UTXO : une transaction relie A+B, une autre dépense des sorties différentes issues de B+C. La fusion transitive produit A+B+C. Si le second lien vient d’un paiement collaboratif, l’erreur touche aussi le cluster antérieur ; peu de fausses arêtes ne signifie pas forcément peu d’adresses mal attribuées. [Meiklejohn et al. — A Fistful of Bitcoins] [Möser and Narayanan — Resurrecting Address Clustering in Bitcoin]
Une plateforme d’échange peut dépenser ensemble des UTXO gérés pour de nombreux clients. L’heuristique peut saisir le contrôle opérationnel sans identifier les propriétaires économiques. Une étiquette de service exige une provenance indépendante et une validité temporelle ; une personne peut aussi utiliser plusieurs portefeuilles jamais reliés. Compter les clusters ne revient pas à compter les personnes. [Meiklejohn et al. — A Fistful of Bitcoins]
Valider une fusion uniquement par une dépense commune ultérieure peut réutiliser l’heuristique évaluée. Möser et Narayanan montrent les usages et limites de telles références. L’évaluation doit documenter provenance de l’échantillon, exclusions et période, en séparant fausses fusions, liens manqués et couverture. Un score non calibré n’est pas une probabilité d’identité. [Möser and Narayanan — Resurrecting Address Clustering in Bitcoin]
Conservez pour chaque arête la transaction, la version de règle et le motif d’acceptation ou d’exclusion. De nouvelles preuves contraires doivent permettre de recalculer le cluster, pas simplement annoter une conclusion inchangée. Coin Control peut limiter les dépenses communes futures de pièces séparées, sans effacer l’historique ; Payjoin conteste cette heuristique, pas toutes les sources d’attribution. [BIP 78 — A Simple Payjoin Proposal] [Möser and Narayanan — Resurrecting Address Clustering in Bitcoin]
Pour une vision complète, lisez aussi Address Clustering, CoinJoin, PayJoin, Chain Surveillance, PSBT, Coin Control. Cette entrée est également citée par PayJoin, Chain Surveillance, Address Clustering.