Types de scripts et formats d’adresse

Une adresse est un encodage lisible par un humain d’un script de verrouillage. Son format indique à l’analyste quel type de script est utilisé, ce qui permet de cerner le logiciel de portefeuille et l’époque dont il provient, et détermine quelles informations seront rendues publiques lorsque les coins seront dépensés. Savoir lire les formats couramment et connaître ce que multisig et Taproot dissimulent ou révèlent fait partie des compétences de base de toute personne travaillant avec des données UTXO.

Du script à l’adresse

Les adresses n’apparaissent pas sur la chaîne. La chaîne stocke le scriptPubKey ; les explorateurs et les décodeurs le convertissent en adresse à des fins d’affichage. Chaque type de script standard correspond à un encodage et à un préfixe reconnaissable (les scripts eux-mêmes sont analysés dans la leçon Transactions Bitcoin brutes) :

Les réseaux de test utilisent différents préfixes (m ou n pour P2PKH, 2 pour P2SH, tb1 pour SegWit), ce qui permet de repérer facilement une adresse de réseau de test qui se serait glissée dans un jeu de données. Certains scripts plus anciens, comme les sorties pay-to-public-key de l’époque des débuts du minage et le multisig nu, n’ont aucune adresse standard ; les explorateurs affichent la clé publique ou une étiquette synthétique, et les entrepôts de données peuvent laisser la colonne d’adresse vide. Une requête qui filtre sur address IS NOT NULL les élimine silencieusement.

Base58Check

Les adresses héritées utilisent Base58Check. L’encodeur prend un octet de version, lui ajoute la charge utile de 20 octets (un HASH160 d’une clé publique ou d’un script), calcule une somme de contrôle et écrit le résultat dans un alphabet de 58 caractères qui exclut les caractères faciles à confondre 0, O, I et l.

octet de version   00                -> P2PKH du réseau principal, la chaîne commence donc par "1"
charge utile       HASH160 de 20 octets d’une clé publique
somme de contrôle  4 premiers octets de SHA-256(SHA-256(version || payload))
encodé             Base58 des 25 octets -> 1Fx3…9qLm

Chaque octet nul initial devient un 1 initial, ce qui explique pourquoi toutes les adresses P2PKH commencent par ce caractère. Base58Check distingue les majuscules des minuscules, et la somme de contrôle de 4 octets fait qu’une adresse mal saisie est presque toujours rejetée. Pour les analystes, l’octet de version est la clé de classification : 0x00 signifie P2PKH, 0x05 signifie P2SH, et toute autre valeur correspond à un autre réseau ou à une autre cryptomonnaie.

Bech32 et bech32m

Les adresses SegWit natives utilisent bech32, défini dans le BIP-173. Une chaîne bech32 comporte trois parties : une partie lisible par l’humain (bc pour le réseau principal, tb pour le réseau de test), le séparateur 1 et une partie de données écrite dans un alphabet de 32 caractères qui exclut 1, b, i et o. Le premier caractère de données est la version witness (q correspond à la version 0, p à la version 1), suivi du programme witness et d’une somme de contrôle de 6 caractères.

bc1q…7k3f            42 caractères
hrp        bc        -> réseau principal Bitcoin
séparateur 1
version    q = 0     -> SegWit v0, la somme de contrôle doit donc être bech32
programme  20 octets -> P2WPKH (un programme de 32 octets serait P2WSH)
somme de contrôle    6 derniers caractères

Bech32 s’écrit entièrement en minuscules (les majuscules sont autorisées pour les codes QR, mais les décodeurs doivent rejeter les chaînes qui mélangent les casses), sa longueur maximale est de 90 caractères et sa somme de contrôle garantit la détection de toute erreur touchant jusqu’à quatre caractères. Il présente un défaut : lorsqu’une chaîne se termine par p, insérer ou supprimer des caractères q juste avant ce p peut laisser la somme de contrôle valide. Pour la version 0, les longueurs strictes du programme (20 ou 32 octets) rendent ce problème largement inoffensif. Les versions ultérieures autorisent d’autres longueurs ; BIP-350 a donc introduit bech32m, identique, à l’exception de la constante utilisée dans la somme de contrôle (0x2bc830a3 au lieu de 1). Les adresses de version 0 conservent bech32 ; les versions 1 à 16, y compris Taproot, utilisent bech32m. Un décodeur doit rejeter une adresse de version 1 munie d’une somme de contrôle bech32 et une adresse de version 0 munie d’une somme de contrôle bech32m.

Conseils pratiques pour les pipelines : ne vous contentez pas de classifier les adresses selon qu’elles « commencent par bc1 » ; lisez le quatrième caractère (q ou p) et la longueur. Les analyseurs écrits avant 2021 peuvent rejeter des adresses bc1p valides ou les traiter comme des erreurs, et un pipeline qui élimine les lignes impossibles à analyser sous-estimera l’activité Taproot sans aucun avertissement.

Ce que le format révèle sur les portefeuilles

Les formats d’adresse suivent l’historique des portefeuilles et fournissent donc des informations sur le logiciel qui les utilise :

• 1… (P2PKH) : anciens portefeuilles, services limités aux adresses héritées et certains portefeuilles de plateformes d’échange établies de longue date. Une activité P2PKH récente indique souvent un logiciel ancien ou personnalisé.
• 3… (P2SH) : ambigu jusqu’à la dépense. Il peut s’agir d’un portefeuille multisig ou d’un portefeuille à clé unique utilisant SegWit imbriqué (P2WPKH encapsulé dans P2SH), une configuration par défaut courante autour de 2017–2019.
• bc1q… (SegWit v0) : type d’adresse de réception par défaut de la plupart des portefeuilles grand public ces dernières années. P2WSH (62 caractères) indique généralement un multisig ou un autre script personnalisé.
• bc1p… (Taproot) : portefeuilles ayant adopté Taproot après son activation au bloc 709 632, en novembre 2021, ainsi que les outils d’inscription et de jetons qui en dépendent.

Lorsqu’une sortie 3… est dépensée, le script de remboursement apparaît dans l’entrée et permet de lever l’ambiguïté : un script de remboursement composé de 0014 suivi de 20 octets correspond à P2WPKH imbriqué, 0020 suivi de 32 octets correspond à P2WSH imbriqué, et un script se terminant par ae (OP_CHECKMULTISIG) correspond à un multisig classique.

Les types de scripts peuvent aussi être mélangés dans les transactions. Si toutes les entrées sont en P2WPKH et que les deux sorties sont l’une en P2WPKH et l’autre en P2SH, la sortie qui correspond au type des entrées est plus susceptible d’être de la monnaie rendue. Le type d’adresse est l’une des nombreuses empreintes de portefeuille, au même titre que la version de la transaction, le verrouillage temporel et les valeurs de séquence, ainsi que l’encodage de signature ; la leçon Heuristiques de détection de la monnaie rendue explique comment les combiner et quel niveau de confiance leur accorder.

Multisig et son empreinte

Le multisig classique utilise OP_CHECKMULTISIG dans un script de remboursement P2SH ou un script witness P2WSH. La politique reste cachée tant que les fonds ne sont pas dépensés (seul un hachage se trouve sur la chaîne), mais elle est entièrement rendue publique lors de la première dépense. Une entrée P2WSH 2-sur-3 décodée se présente ainsi :

witness[0]  (vide)             -- élément factice exigé par OP_CHECKMULTISIG
witness[1]  3044…01            -- première signature (DER, octet sighash 01)
witness[2]  3045…01            -- deuxième signature
witness[3]  5221…21…21…53ae    -- OP_2 <key1> <key2> <key3> OP_3 OP_CHECKMULTISIG

Dans le script witness, 52 est OP_2 (deux signatures requises), chaque 21 pousse une clé publique compressée de 33 octets, 53 est OP_3 (trois clés) et ae est OP_CHECKMULTISIG. Une seule dépense révèle le seuil, les trois clés publiques et les deux clés qui ont signé.

Cette empreinte constitue une preuve riche en informations. Les dépositaires mettent souvent en œuvre des politiques distinctives (2-sur-3, 3-sur-5) pour le stockage à froid, et la même clé publique présente dans de nombreux scripts multisig relie ces adresses à un même détenteur de clé avec bien plus de fiabilité que les heuristiques comportementales. De nombreux portefeuilles trient les clés dans l’ordre lexicographique (BIP-67), ce qui constitue en soi une petite empreinte.

Taproot et confidentialité

Taproot combine trois éléments. BIP-340 définit les signatures Schnorr sur la même courbe secp256k1 : des signatures de 64 octets fixes et des clés publiques « x-only » de 32 octets. BIP-341 définit la sortie : OP_1 suivi d’une clé Q de 32 octets, où Q = P + t·G, P est une clé interne et le tweak t engage P ainsi que la racine de Merkle d’un arbre facultatif de scripts alternatifs. BIP-342 définit les règles de script dans cet arbre et remplace OP_CHECKMULTISIG par OP_CHECKSIGADD.

Une sortie Taproot peut être dépensée de deux façons, qui révèlent des quantités d’information très différentes :

Sur le chemin par clé, un portefeuille à clé unique, un groupe n-sur-n utilisant l’agrégation de clés (MuSig2) et un schéma de signature à seuil produisent tous le même résultat : une signature pour une clé. Le chemin par script ne révèle que la feuille effectivement utilisée ; les branches inutilisées restent cachées, même si la longueur du chemin de Merkle révèle certaines informations sur la taille de l’arbre, comme le souligne le BIP-341 lui-même, et peut aider au regroupement.

Pour les analystes, Taproot élimine l’empreinte multisig décrite ci-dessus chaque fois que le chemin par clé est utilisé, rendant ainsi invisibles les politiques de conservation. Il ne masque ni les montants, ni le graphe des transactions, ni leur chronologie et, bien que l’adoption reste modeste, le format bc1p lui-même est distinctif. Les dépenses par chemin de script contiennent aussi des inscriptions : depuis 2023, de grands witness comprenant une « enveloppe » OP_FALSE OP_IF … OP_ENDIF servent à intégrer des images et des données de jetons ; il vaut la peine de filtrer ce type de dépense dans l’analyse des paiements.

Points clés pour l’examen : faire correspondre préfixes et longueurs aux types de scripts (1, 3, bc1q de 42 et 62 caractères, bc1p de 62 caractères) ; structure de Base58Check (octet de version, somme de contrôle de 4 octets calculée avec un double SHA-256, version 0x00 contre 0x05) ; structure de bech32 (hrp, séparateur 1, caractère de version witness, somme de contrôle de 6 caractères) et passage à bech32m dans le BIP-350 pour la version witness 1 et les versions supérieures ; pourquoi « commence par bc1 » ne suffit pas à classifier une adresse ; comment la dépense d’une sortie P2SH permet de déterminer s’il s’agit de SegWit imbriqué ou de multisig ; ce que révèle une dépense multisig classique ; dépenses Taproot par chemin par clé et par chemin par script, Q = P + t·G et bloc de contrôle de 33 + 32m octets ; ce que Taproot dissimule et ce qu’il ne dissimule pas.