Base58Check

L'alphabet écarte les quatre caractères que l'on confond lorsqu'on recopie à la main : le zéro, le O majuscule, le I majuscule et le l minuscule. Une somme de contrôle de quatre octets, tirée d'un double SHA-256 de la charge utile, fait qu'une adresse mal saisie est rejetée par le portefeuille plutôt qu'envoyée dans le vide, avec environ une chance sur 4,29 milliards qu'elle passe.

Toute adresse commençant par 1 ou 3 est en Base58Check.

Comment cela fonctionne

Trois éléments entrent dans chaque chaîne Base58Check. Un octet de version placé au début indique de quel type de données il s'agit, la charge utile au milieu porte les octets proprement dits, et quatre octets de somme de contrôle à la fin sont les quatre premiers octets de SHA-256 appliqué deux fois à la version et à la charge utile réunies. Le résultat est ensuite écrit en base 58 plutôt qu'en base 16, ce qui le raccourcit nettement et supprime les glyphes ambigus.

C'est l'octet de version qui produit les caractères de tête familiers. La version 0x00 marque une adresse pay-to-public-key-hash et donne un 1 initial ; la version 0x05 marque une adresse pay-to-script-hash et donne un 3 initial ; la version 0x80 marque une clé privée au format Wallet Import Format, donnant 5, K ou L. Les clés étendues utilisent plutôt une version de quatre octets, 0x0488B21E, ce qui explique pourquoi toute xpub commence par ces quatre lettres.

Les octets nuls initiaux reçoivent un traitement particulier, car la conversion de base les écarterait sinon. Chaque octet 0x00 au début de la charge utile est écrit sous la forme d'un caractère « 1 » supplémentaire, ce qui explique pourquoi certaines adresses historiques sont plus courtes ou plus longues que leurs voisines alors qu'elles portent la même quantité de données.

Où le rencontre-t-on

Base58Check est partout dans la première décennie du bitcoin et nulle part dans ses formats les plus récents. Les adresses historiques, les adresses pay-to-script-hash, les clés privées WIF et les clés étendues xprv et xpub que vous exportez d'un portefeuille l'utilisent toutes. Rien de ce qui commence par bc1 ne l'utilise.

Deux propriétés expliquent à la fois cette popularité et cet abandon. La sécurité de transcription était le but : l'alphabet a été conçu pour qu'une adresse lue à voix haute, recopiée depuis un écran ou gravée sur une plaque métallique survive à une manipulation humaine, et la somme de contrôle transforme les erreurs restantes en refus plutôt qu'en pertes. Mais le codage est sensible à la casse, ce qui force un code QR en mode octet au lieu du mode alphanumérique plus compact, et il peut seulement vous dire que quelque chose ne va pas, jamais quoi ni où.

Base58Check vs Bech32

Base58Check détecte les erreurs et bech32 les corrige. Bech32, spécifié dans le BIP-173 et adopté pour les adresses SegWit natives en 2017, utilise un alphabet de 32 caractères sans aucune majuscule, de sorte que la chaîne entière tient dans le mode alphanumérique d'un code QR et se scanne depuis une image plus petite. Sa somme de contrôle BCH garantit la détection de jusqu'à quatre caractères erronés et peut indiquer quelles positions sont suspectes, plutôt que de simplement échouer.

Le successeur a eu besoin d'un correctif pour lui-même. Une faiblesse d'extension de longueur dans la somme de contrôle bech32 d'origine faisait que certaines adresses pouvaient gagner ou perdre un dernier caractère sans détection, aussi le BIP-350 a défini bech32m, qui change une constante et est ce qu'utilisent les adresses Taproot commençant par bc1p. Base58Check reste valide et continuera de fonctionner indéfiniment, mais de nouveaux types d'adresses ne sont pas définis dans ce codage.