156 / 691CHAINAL

Chain Surveillance

Surveillance de la blockchain et inférences sur les acteurs réels

Chain Surveillance associe transactions publiques, estimations de contrôle commun et données externes ; la conclusion dépend de l’étape d’attribution étayée la moins fiable.

Chain Surveillance observe systématiquement le graphe de transactions Bitcoin pour déduire des flux, groupes d’adresses et liens avec des acteurs. Elle combine données vérifiables, heuristiques et étiquettes externes. Transaction enregistrée, contrôle commun des clés et identité personnelle sont trois niveaux d’affirmation distincts.

Une transaction indique les anciennes sorties dépensées et les nouvelles sorties, montants et conditions créés. Le graphe UTXO établit les relations entre sorties, pas le nom ou l’adresse IP du payeur. Le protocole ne marque normalement pas une sortie comme paiement ou change et n’affecte pas chaque satoshi entrant à une sortie précise. Un tracé coloré peut intégrer une règle supplémentaire d’allocation de valeur qui doit être explicitée. [Bitcoin Developer Guide — Transactions]

La common-input ownership heuristic relie les entrées parce qu’un portefeuille ordinaire utilise ses propres fonds. Un change présumé peut rattacher une sortie. Ce ne sont pas des règles de consensus : CoinJoin et Payjoin autorisent des entrées de participants différents sans partage de clés privées. BIP 78 est un contre-exemple concret où le destinataire ajoute ses entrées. Une transaction commune ne prouve donc pas un propriétaire unique sans hypothèses supplémentaires. [Meiklejohn et al. — A Fistful of Bitcoins] [BIP 78 — A Simple Payjoin Proposal]

L’attribution d’un service peut venir d’un contact documenté, d’une adresse publiée ou d’un registre de contrepartie. Chaque étiquette doit avoir un auteur, une justification et une période d’application. Une plateforme peut gérer les fonds de nombreux clients et un acteur utiliser plusieurs clusters. Un cluster ne compte donc pas les personnes ; une adresse de service ne désigne pas automatiquement un client ou l’objet de chaque paiement. [Meiklejohn et al. — A Fistful of Bitcoins]

L’étude de Goldfeder et al. de 2017 examine les liens entre achats, blockchain et identifiants web. Un modèle pratique associe montant, fenêtre temporelle ou adresse de paiement à un cookie ou compte. C’est une autre source, pas une identité inscrite dans la transaction. Un échantillon historique ne donne pas un taux universel de réussite actuel. Des métadonnées déjà conservées peuvent néanmoins permettre un rapprochement rétrospectif. [Goldfeder et al. — When the cookie meets the blockchain]

Une adresse IP peut être enregistrée lors des connexions ou relais, mais n’est pas un champ d’une sortie Bitcoin. Un nœud relaie aussi les transactions d’autrui : le premier peer observé n’est pas nécessairement l’émetteur initial. Tor peut limiter le lien entre trafic et IP ; il ne modifie ni les montants publiés ni les relations UTXO. Il faut séparer ce qui a été observé sur le réseau de ce qui a été déduit de la blockchain. [Bitcoin — Protect your privacy]

Une fusion transitive peut, par une fausse arête, réunir deux grands groupes en un supercluster erroné. Möser et Narayanan étudient les limites au cluster collapse et reconnaissent les hypothèses et biais des données de référence dérivées. Pour votre évaluation, indiquez faux regroupements, liens manqués, couverture, période et validation des étiquettes. Sans calibration sur des cas connus, un score n’est pas automatiquement la probabilité d’une identité correcte. [Möser and Narayanan — Resurrecting Address Clustering in Bitcoin]

De nouvelles adresses réduisent la réutilisation directe, mais une dépense commune ultérieure peut créer un autre lien. Payjoin perturbe l’hypothèse des entrées communes sans effacer le graphe public ni les données du marchand. Un nœud personnel réduit les requêtes révélées à un backend tiers, pas la visibilité des transactions confirmées. Une évaluation utile précise observateur et lien visé plutôt que de promettre l’anonymat total. [Bitcoin Developer Guide — Transactions] [BIP 78 — A Simple Payjoin Proposal] [Bitcoin — Protect your privacy]

Pour chaque affirmation, notez transaction ou sortie, origine de l’étiquette, heuristiques, date et explications alternatives. Distinguez paiement direct et connexion à plusieurs étapes, contrôle des clés et propriété économique. Score de risque ou distance dans le graphe ne prouvent pas seuls une identité ou une conduite. Ce contrôle de qualité déduit exige de pouvoir réviser la conclusion avec de nouvelles preuves sans transformer l’hypothèse initiale en fait prétendument confirmé de façon indépendante. [Meiklejohn et al. — A Fistful of Bitcoins] [Möser and Narayanan — Resurrecting Address Clustering in Bitcoin]

Pour une vision complète, lisez aussi Confidentialité de Bitcoin, Common-Input Ownership Heuristic, Address Clustering, Transaction Labeling, CoinJoin, PayJoin. Cette entrée est également citée par Sortie de monnaie, Common-Input Ownership Heuristic, Address Clustering, Czech Ministry Bitcoin donation scandal.

DOC · 001Bitcoin Developer Guide — TransactionsDocumentation ↗DOC · 002Meiklejohn et al. — A Fistful of BitcoinsSource primaire ↗DOC · 003Goldfeder et al. — When the cookie meets the blockchainSource primaire ↗DOC · 004Möser and Narayanan — Resurrecting Address Clustering in BitcoinSource primaire ↗DOC · 005BIP 78 — A Simple Payjoin ProposalSpécification ↗DOC · 006Bitcoin — Protect your privacyDocumentation ↗
Sources d’abord · Pas un conseil financier