L’heuristique de propriété par entrée commune

L’heuristique de propriété par entrée commune est la règle de regroupement la plus ancienne et la plus utilisée dans les chaînes UTXO. Elle produit la plupart des liens dans tout regroupement Bitcoin, elle est généralement juste et, lorsqu’elle se trompe, elle le fait d’une manière qui fusionne des portefeuilles entiers. Un analyste doit comprendre à la fois pourquoi elle fonctionne et précisément quelles transactions la mettent en défaut.

La logique

Pour dépenser un UTXO, une transaction doit fournir un script de déverrouillage ou un témoin valide pour cette sortie, ce qui signifie en pratique une signature de la clé qui la contrôle. Une transaction comportant trois entrées nécessite donc des signatures pour trois pièces. Dans un usage ordinaire, un portefeuille construit un paiement en sélectionnant des pièces de son propre solde et en les signant toutes. Ainsi, si plusieurs adresses apparaissent comme entrées dans une même transaction, l’explication la plus probable est qu’un seul portefeuille, et donc un seul contrôleur, détient les clés de toutes ces adresses.

Cette idée est aussi ancienne que Bitcoin. La section sur la confidentialité du livre blanc de 2008 avertit déjà que les transactions à entrées multiples « révèlent nécessairement que leurs entrées appartenaient au même propriétaire ». Reid et Harrigan (2011, « Une analyse de l’anonymat dans le système Bitcoin ») l’ont utilisée pour construire un réseau d’utilisateurs, et Meiklejohn et al. (2013, « Une poignée de bitcoins ») l’ont formulée comme leur heuristique 1 : si deux adresses ou plus sont des entrées d’une même transaction, elles sont contrôlées par le même utilisateur. Cette règle est également appelée heuristique de propriété par entrée commune (CIOH) ou heuristique des entrées multiples.

Exemple détaillé

Voici une transaction décodée, simplifiée pour ne conserver que les champs utiles au regroupement (identifiants tronqués) :

{
  "txid": "7c1e…40ab",
  "vin": [
    {"prevout": "a91f…03:1", "address": "bc1q…k3f7", "value_btc": 0.0400},
    {"prevout": "e2c8…7d:0", "address": "bc1q…m9a2", "value_btc": 0.0250},
    {"prevout": "51b0…e9:4", "address": "bc1q…x0d1", "value_btc": 0.0180}
  ],
  "vout": [
    {"n": 0, "address": "bc1q…p2w8", "value_btc": 0.0700},
    {"n": 1, "address": "bc1q…r4t6", "value_btc": 0.0128}
  ]
}

Les trois entrées totalisent 0,0830 BTC ; les sorties totalisent 0,0828 BTC, la commission est donc de 0,0002 BTC (20 000 satoshis). La règle de l’entrée commune crée des liens entre bc1q…k3f7, bc1q…m9a2 et bc1q…x0d1. Elle ne dit rien sur les sorties : déterminer si bc1q…r4t6 correspond à de la monnaie rendue appartenant au même portefeuille est une inférence distincte et bien moins solide, abordée dans la leçon Heuristiques de détection de la monnaie rendue.

Si bc1q…m9a2 faisait déjà partie d’un regroupement de 2 000 adresses et bc1q…x0d1 d’un regroupement de 300, cette transaction fusionnerait ces regroupements en un regroupement de 2 301 adresses. Voilà la portée de cette règle, mais aussi le danger qu’elle présente.

La règle est particulièrement efficace pour les services. Les plateformes d’échange dépositaires et les prestataires de paiement consolident périodiquement de nombreux petits dépôts en une seule sortie, dans une transaction de concentration qui peut dépenser des centaines d’adresses de dépôt à la fois. Chaque opération de balayage lie toutes ces adresses au portefeuille du service, ce qui explique pourquoi les regroupements de services atteignent des millions d’adresses et pourquoi un seul dépôt vérifié suffit souvent à les étiqueter (voir la leçon Attribution et étiquetage). Les consolidations effectuées par des utilisateurs ordinaires fonctionnent de la même manière, à plus petite échelle : un portefeuille qui fusionne une douzaine d’anciennes pièces pour économiser sur les frais futurs révèle qu’il les détenait toutes. Dans les deux cas, la même hypothèse s’applique : une seule partie a signé. Elle est juste tant que personne d’autre n’a contribué d’entrée.

Dans quelle mesure fonctionne-t-elle ?

Les données sur la précision sont limitées, mais cohérentes. Meiklejohn et al. ont appliqué cette règle à l’ensemble de la chaîne en 2013 et ont ramené 12 056 684 clés publiques à environ 5,58 millions de regroupements. Nick (2015, mémoire de maîtrise sur la désanonymisation de Bitcoin fondée sur les données) a obtenu de rares données de référence grâce à une fuite de confidentialité dans les filtres de Bloom utilisés par les portefeuilles légers, qui a révélé les ensembles d’adresses de portefeuilles réels ; la règle de l’entrée commune a permis d’identifier plus de 69 % des adresses de ces portefeuilles. Notez ce que mesure ce chiffre : le rappel (la part de chaque portefeuille qui a été retrouvée), et non la précision (la proportion de liens qui étaient corrects). La règle est généralement considérée comme très précise pour les transactions ordinaires, mais cela repose sur une hypothèse concernant le comportement des portefeuilles, et les transactions décrites ci-dessous la mettent en défaut.

Quand l’hypothèse ne tient pas

CoinJoin. Plusieurs utilisateurs se mettent d’accord pour effectuer une transaction unique ; chacun apporte des entrées et ne signe que les siennes, et les sorties comprennent généralement plusieurs montants identiques, de sorte que personne ne peut savoir quelle sortie appartient à qui. L’application de la règle de l’entrée commune fusionne les portefeuilles de tous les participants, créant précisément le faux lien que CoinJoin cherche à induire. Consultez la leçon Mélangeurs, CoinJoin et obfuscation dans les graphes pour voir à quoi ressemblent ces transactions dans un graphe.

PayJoin. Dans un PayJoin (BIP 78), le destinataire d’un paiement ajoute l’une de ses propres entrées à la transaction de l’expéditeur. Le résultat ressemble à un paiement ordinaire à deux entrées ; la règle lie donc les pièces de l’expéditeur à celles du destinataire, et le montant apparent du paiement est également faussé. Un PayJoin bien conçu ne peut pas être distingué de manière fiable d’une transaction normale ; son existence plafonne donc le niveau de confiance associé à tout lien pris isolément. Son adoption est faible, ce qui limite les dommages globaux, sans toutefois exclure cette possibilité dans un cas particulier.

Autres transactions multipartites. Tout protocole dans lequel deux parties ou plus apportent des entrées met la règle en défaut : ouvertures de canaux Lightning financées par les deux parties, certains protocoles d’échange et de traitement par lots, ainsi que les transactions signées avec SIGHASH_ANYONECANPAY, qui permet à d’autres personnes d’ajouter des entrées après la première signature (utilisé, par exemple, dans les contrats de financement participatif).

Contrôle partagé. Une adresse multisig détenue conjointement par plusieurs personnes constitue un seul « propriétaire » au sens du script, mais représente plusieurs personnes dans la réalité. L’entité correcte est l’arrangement conjoint, et non un signataire en particulier.

Garde et importation de clés. Un service de garde dépense ensemble les dépôts de ses clients ; le regroupement est donc correct pour le service, mais ne permet pas de tirer de conclusions sur ses clients. Les portefeuilles qui permettent aux utilisateurs d’importer ou de balayer des clés privées reçues d’autres personnes (portefeuilles papier, cartes-cadeaux) peuvent lier des pièces qui avaient des propriétaires différents ; le regroupement de Mt. Gox, mentionné dans la leçon Qu’est-ce que le regroupement et pourquoi est-ce important ?, en est le cas le plus connu.

Mesures de protection

Cinq pratiques permettent de conserver l’utilité de cette règle.

1. Écarter les transactions probablement CoinJoin avant d’établir des liens. Le test le plus simple consiste à rechercher plusieurs sorties ayant exactement la même valeur.

-- Signaler les CoinJoin possibles afin de ne pas lier leurs entrées
WITH same_value AS (
  SELECT tx_id, value_sat, COUNT(*) AS n_equal
  FROM outputs
  GROUP BY tx_id, value_sat
),
shape AS (
  SELECT t.tx_id, t.input_count, MAX(s.n_equal) AS max_equal_outputs
  FROM transactions t
  JOIN same_value s ON s.tx_id = t.tx_id
  GROUP BY t.tx_id, t.input_count
)
SELECT tx_id
FROM shape
WHERE input_count >= 2
  AND max_equal_outputs >= 3;  -- ajuster ce seuil et le documenter

La requête compte, pour chaque transaction, le nombre de sorties ayant la même valeur, conserve le groupe le plus important et signale les transactions à entrées multiples dont au moins trois sorties sont identiques. Le choix du seuil relève du jugement. Cette méthode détectera aussi certains paiements par lots de plateformes d’échange qui, par hasard, versent des montants égaux ; les exclure ne coûtera que quelques liens (un faux négatif), ce qui constitue l’erreur la plus prudente. Elle ne détectera pas les conceptions de CoinJoin qui évitent les sorties de valeur égale : il s’agit donc d’un filtre, et non d’un détecteur. Les outils de recherche utilisent des règles plus élaborées ; Goldfeder et al. (2018, « Quand le cookie rencontre la blockchain ») ont ajouté une exclusion des CoinJoin à leur regroupement pour cette raison.

1. Signaler les mélanges d’entrées inhabituels. Les entrées de types de script différents (par exemple, une entrée P2PKH classique à côté d’une entrée P2TR) sont rares dans les logiciels de portefeuille à utilisateur unique et méritent un examen plus attentif.

1. Surveiller les fusions. Examinez tout lien qui fusionnerait deux grands regroupements, ou deux regroupements portant des étiquettes différentes. Harrigan et Fretter (2016, « L’efficacité déraisonnable du regroupement d’adresses ») ont observé qu’il est rare que deux grands regroupements fusionnent naturellement ; une telle fusion constitue donc un signal d’alerte.

1. Conserver la transaction justificative pour chaque lien. Si une transaction se révèle par la suite être un CoinJoin ou un PayJoin, ses liens peuvent être supprimés et les regroupements reconstruits.

1. Indiquer la règle, pas seulement le résultat. Précisez qu’un regroupement a été établi au moyen de la règle de l’entrée commune, les exclusions appliquées et la hauteur de bloc utilisée.

Niveaux de confiance

La génération, en SQL, des paires d’adresses à partir des tables d’entrées et leur utilisation pour amorcer des regroupements sont abordées dans la leçon Interroger les données UTXO.

Points clés pour l’examen : pourquoi des entrées dépensées ensemble impliquent un contrôleur commun (chaque entrée nécessite sa propre signature valide et les portefeuilles sélectionnent des pièces dans leur propre solde) ; la règle en tant qu’heuristique 1 de Meiklejohn et al. et ses origines dans le livre blanc ; la différence entre rappel et précision dans les données issues de la fuite des filtres de Bloom (plus de 69 % des adresses des portefeuilles retrouvées) ; les principales exceptions (CoinJoin, PayJoin selon BIP 78, canaux financés par les deux parties, SIGHASH_ANYONECANPAY, multisig, garde et importation de clés) ; pourquoi un seul lien peut fusionner deux regroupements entiers ; le filtrage des sorties de valeur égale avant l’établissement des liens et la documentation du seuil ; l’examen des fusions importantes ou de celles qui réunissent des étiquettes contradictoires.