Address Clustering

Anna utilise de nouvelles adresses pour différentes rentrées d’argent, puis paie un magasin avec son portefeuille. Un portefeuille est une application ou un appareil permettant de recevoir et d’envoyer des bitcoins. L’analyste voit circuler des fonds, mais doit distinguer deux questions : lesquels ont été dépensés, et quelles adresses pourraient relever du même contrôle ? Le paiement au magasin répond à la première. Il ne suffit pas à réunir Anna et le magasin dans un groupe. Address Clustering cherche d’autres indices, comme la dépense commune de plusieurs sommes reçues. Le diagramme des paiements montre des liens réels entre transactions ; les groupes colorés y ajoutent une interprétation. Cette distinction est essentielle pour lire ces cartes. [1] [5]

Les sommes reçues auparavant existent comme UTXO, des sorties de transaction non dépensées. Chaque sortie indique un montant et les conditions à remplir pour le dépenser. Une nouvelle entrée désigne une sortie antérieure précise, pas une case universelle « adresse de l’expéditeur ». L’outil retrouve son scriptPubKey d’origine, qui énonce les conditions de dépense. Pour les types pris en charge, une adresse représente commodément ces conditions ; tous les scripts n’ont pas d’adresse habituelle. Une explication rigoureuse distingue donc adresses et scripts, et précise le réseau ainsi que les blocs étudiés. Un bloc regroupe des transactions en un lot ajouté à l’historique commun. Un identifiant technique ne devient pas pour autant l’identité d’une personne. [4] [6]

La Common-Input Ownership Heuristic suppose un contrôle commun de plusieurs entrées d’une transaction. Repérer le change est une autre étape : on cherche la sortie qui rend au payeur le reste après paiement et frais. Une bonne estimation relie la nouvelle adresse de monnaie rendue d’Anna à ses anciennes rentrées. Confondre le paiement au magasin avec le change revient au contraire à attribuer à Anna des fonds qui appartiennent au magasin. Deux sorties ne révèlent pas à elles seules leurs rôles : il peut s’agir de deux destinataires ou de transferts entre portefeuilles personnels. Une adresse jamais vue ne prouve pas non plus qu’elle appartient au payeur. [1] [3]

Un montant arrondi, un type de script ou une adresse réutilisée constituent des indices, pas des lois immuables. Une mise à jour de portefeuille peut construire les transactions autrement et tromper un ancien modèle. CoinJoin permet à plusieurs participants de partager une transaction ; dans Payjoin selon BIP 78, le destinataire peut ajouter ses propres entrées. Cette coopération n’impose pas des sorties de montants égaux. Sans nouvelle évaluation, une précision historique ne peut donc être promise pour les transactions actuelles. Il faut aussi savoir dans quels cas la méthode ne fait aucune prédiction. [2] [3]

Imaginons deux groupes d’adresses séparés. Un lien erroné peut les fusionner et étendre l’erreur à tous leurs membres. Pour réaliser ces fusions rapidement, les programmes utilisent souvent union-find, une structure de données qui suit les groupes connectés. Sa forme courante ne permet pas de supprimer un ancien lien et de séparer automatiquement le résultat correctement. Pour une analyse vérifiable, il faut donc conserver les transactions, les liens et les versions des règles, pas seulement la liste finale. C’est une conséquence pratique de la propagation des erreurs décrite dans la recherche : corriger peut demander un nouveau calcul, pas un simple changement de nom. [2]

Malte Möser et Arvind Narayanan étudient le cluster collapse, la fusion erronée de nombreux groupes en un ensemble immense. Leur constrained union-find refuse de fusionner des groupes reliés par une sortie prédite comme paiement. Dans l’exemple d’Anna, l’hypothèse « elle paie le magasin » peut empêcher de réunir ensuite les deux parties. Cette protection ne connaît pourtant pas la vérité indépendamment : elle dépend de la prédiction et peut refuser des liens corrects. Moins de fusions ne donnent donc pas automatiquement une image complète ou sans erreur des propriétaires. [2]

Nommer une adresse d’après une plateforme d’échange et étendre ce nom à un cluster entier sont deux opérations distinctes. Une étiquette nécessite une source, une période de validité et un chemin de propagation vérifiable. Un groupe contrôlé par une plateforme peut servir de nombreux clients. La validation ne devrait pas non plus reposer seulement sur des données produites par la même hypothèse. Fusions erronées, liens manqués et couverture de l’échantillon doivent être évalués séparément. Beaucoup d’adresses étiquetées ne garantissent pas une attribution correcte. [1] [2]

Anna peut déplacer des fonds entre deux de ses portefeuilles. Si le modèle ne les relie pas, il peut compter ce mouvement comme un paiement entre entités distinctes. Un regroupement amélioré peut le reconnaître comme transfert interne, ou self-churn, et réduire le volume estimé sans modifier l’histoire de la blockchain. De même, le solde d’un cluster correspond à ses UTXO encore non dépensés à un bloc donné ; additionner toutes ses anciennes rentrées inclurait de l’argent déjà dépensé. Pour comparer des graphiques, vérifiez donc la date, mais aussi la version du modèle, les étiquettes et le périmètre des données utilisées. [1] [2]