Address Clustering regroupe des adresses Bitcoin ou scripts de sortie auxquels un modèle attribue un contrôle commun. La blockchain ne stocke pas ces groupes. Nommer un service ou une personne constitue une étape supplémentaire exigeant ses propres preuves.
Le graphe transactionnel relie les sorties réellement dépensées aux transactions qui les consomment. Un cluster regroupe en plus les nœuds selon un contrôle inféré. Un paiement entre deux adresses ne suffit pas à leur attribuer un propriétaire commun ; arêtes transactionnelles et liens de contrôle doivent rester distincts. [Meiklejohn et al. — A Fistful of Bitcoins]
Une entrée référence un UTXO antérieur, pas un champ universel d’adresse de l’émetteur. Il faut retrouver le scriptPubKey initial et préciser réseau et plage de blocs. Certains scripts n’ont pas de représentation d’adresse habituelle ; les transformer en personne supposée confondrait objet technique et identité. [Bitcoin Developer Guide — Transactions]
Common-Input Ownership Heuristic relie les entrées. Détecter le change peut ajouter une sortie ; choisir par erreur le destinataire fusionne les deux parties. Deux sorties ne signifient pas automatiquement paiement et change : elles peuvent viser deux destinataires ou des portefeuilles personnels. La nouveauté d’une adresse ne décide pas seule. [Meiklejohn et al. — A Fistful of Bitcoins] [BIP 78 — A Simple Payjoin Proposal]
Type de script, montants ronds et utilisation passée peuvent être des caractéristiques du modèle, pas des preuves. CoinJoin et Payjoin contredisent certaines hypothèses ; les exceptions n’exigent pas des montants manifestement égaux. Les changements logiciels ou comportementaux modifient les erreurs : les performances historiques nécessitent une nouvelle mesure pour les données actuelles. [Möser and Narayanan — Resurrecting Address Clustering in Bitcoin] [BIP 78 — A Simple Payjoin Proposal]
Union-find forme efficacement des groupes transitifs. Une implémentation ordinaire ne peut simplement supprimer une ancienne fusion et répartir correctement le cluster. Conservez arêtes, transactions et versions des règles ; corriger peut nécessiter un recalcul. La liste des membres seule ne préserve pas le chemin de preuves ayant produit la fusion. [Möser and Narayanan — Resurrecting Address Clustering in Bitcoin]
Möser et Narayanan contraignent union-find pour empêcher de fusionner des groupes séparés par une sortie de paiement prédite. Cela peut limiter cluster collapse, mais dépend aussi de l’inférence du paiement. Une règle prudente peut rejeter des liens valides ; moins de fusions ne décrit pas automatiquement mieux tous les propriétaires. [Möser and Narayanan — Resurrecting Address Clustering in Bitcoin]
Étiqueter une adresse au nom d’un service et propager ce nom au cluster sont deux affirmations. Consignez provenance, période et trajet de propagation ; un groupe de plateforme d’échange n’est pas un client. Des références issues de la même heuristique ne sont pas pleinement indépendantes. Séparez fausses fusions, fausses séparations et couverture. [Meiklejohn et al. — A Fistful of Bitcoins] [Möser and Narayanan — Resurrecting Address Clustering in Bitcoin]
Reconnaître un transfert interne peut retirer self-churn des paiements entrants estimés. Une nouvelle version des clusters peut donc réviser une métrique historique sans changer la blockchain. Calculez les soldes avec les UTXO encore non dépensés au bloc choisi, pas toutes les sorties reçues dans le passé. Précisez versions du modèle, des étiquettes et date de coupure. [Meiklejohn et al. — A Fistful of Bitcoins] [Möser and Narayanan — Resurrecting Address Clustering in Bitcoin]
Pour une vision complète, lisez aussi Common-Input Ownership Heuristic, Chain Surveillance, Sortie de monnaie, CoinJoin, PayJoin, UTXO. Cette entrée est également citée par Pseudonymat, Chain Surveillance, Common-Input Ownership Heuristic, Transaction Labeling.