Adresses et encodages : Base58Check, Bech32, Bech32m

Curiosité

1. Pourquoi la modification d’un seul caractère dans une adresse la rend-elle presque toujours invalide, alors que certaines fautes de frappe passent quand même ?
2. Comment une suite de lettres et de chiffres peut-elle servir de carte vers un script de verrouillage précis sans que ce script soit stocké sur la chaîne ?
3. Que peut garantir Bech32 concernant les fautes de frappe que Base58Check ne peut que rendre peu probables ?

Explorer

1. Une adresse n’est pas un objet stocké dans l’ensemble des UTXO ; c’est un encodage lisible par les humains d’un script de sortie. La chaîne ne stocke que des octets, mais les logiciels les convertissent en chaînes de caractères que les humains peuvent lire et saisir. Cette couche de traduction doit empêcher les erreurs de transcription, car une adresse mal saisie qui semble toujours valide peut envoyer des fonds au mauvais endroit. La conception d’origine de Satoshi, Base58Check, y répondait en utilisant un alphabet de 58 caractères qui exclut les caractères visuellement ambigus ‘0’, ‘O’, ‘I’ et ‘l’.
2. Base58Check encode un octet de version, la charge utile (comme un hash de 20 octets) et une somme de contrôle de quatre octets. La somme de contrôle est dérivée des quatre premiers octets du double hash SHA-256 des données précédentes. Les adresses Pay-to-Public-Key-Hash (P2PKH) traditionnelles utilisent l’octet de version 0x00, ce qui donne des chaînes commençant par ‘1’. Pay-to-Script-Hash (P2SH) utilise l’octet de version 0x05, ce qui produit des chaînes commençant par ‘3’. Cette structure permet aux portefeuilles de vérifier l’intégrité avant d’accepter une adresse.
3. Segregated Witness (SegWit), activé en août 2017 au bloc 481 824, a introduit des sorties witness natives qui nécessitaient un nouvel encodage. Base58Check était mal adapté aux structures de données plus longues et aux schémas d’erreurs propres à SegWit. Pieter Wuille et Greg Maxwell ont proposé Bech32 dans le BIP-173 (2017). Il utilise un jeu restreint de 32 caractères — chiffres et lettres minuscules, à l’exception de ‘1’, ‘b’, ‘i’ et ‘o’, le ‘1’ étant réservé comme séparateur. L’usage d’une seule casse évite les ambiguïtés et convient aux codes QR.
4. Les adresses Bech32 commencent par la partie lisible par l’humain « bc » et le séparateur « 1 », suivis des données et d’une somme de contrôle de six caractères. Cette somme de contrôle repose sur les codes de Bose-Chaudhuri-Hocquenghem (BCH), nettement plus robustes que la somme de contrôle dérivée de SHA-256 de Base58Check. Le code BCH garantit la détection de toute erreur affectant jusqu’à quatre caractères et permet souvent de localiser la position des fautes de frappe. Les adresses SegWit v0 natives (P2WPKH et P2WSH) utilisent ce format et commencent par « bc1q ».
5. Les développeurs ont ensuite identifié une faiblesse dans le polynôme d’origine de Bech32 : l’insertion ou la suppression de certaines séquences de caractères pouvait produire une adresse valide mais différente. Pour corriger ce problème sans casser les adresses v0 existantes, le BIP-350 (2020) a introduit Bech32m. Celui-ci modifie une constante dans le calcul du checksum afin que ce type d’insertion ou de suppression soit détecté. Les adresses Taproot (SegWit version 1), activées en novembre 2021, utilisent Bech32m et commencent par « bc1p ».
6. Les adresses testnet utilisent le préfixe « tb1 » au lieu de « bc1 ». La partie données encode le programme witness : un hash d’une clé publique ou d’un script pour SegWit version 0, ou une clé publique ajustée (tweaked) de 32 octets pour Taproot. Lorsqu’un logiciel scanne un code QR ou accepte une saisie manuelle, il exécute la fonction polymod de BCH pour vérifier l’intégrité. Ouvrez un explorateur de blocs et trouvez une adresse de chaque type : une P2PKH legacy commençant par « 1 », une SegWit v0 commençant par « bc1q » et une adresse Taproot commençant par « bc1p ». Notez leurs longueurs et leurs préfixes.

Faits clés

Exercice neuf, six, trois, un

Vérification des faits

Les dates, les chiffres et les affirmations ont été vérifiés à l’aide des sources publiées listées ci-dessous.

• P. Wuille, G. Maxwell, 'SegWit address format' (BIP-173, 2017)
• P. Wuille, 'Bech32m format for v1+ witness addresses' (BIP-350, 2020)
• A. M. Antonopoulos & D. A. Harding, Mastering Bitcoin, 3rd ed. (2023), ch. 4
• Bitcoin Wiki, 'Technical background of version 1 Bitcoin addresses'