Empreinte de clé

Une empreinte est une étiquette de largeur fixe pour une clé, et sa largeur fait partie du format plutôt que d'un choix d'affichage. Le BIP-380 exige exactement 8 caractères hexadécimaux entre les crochets d'un descripteur, et ses propres vecteurs de test rejettent une empreinte de sept caractères, une de neuf caractères et une comportant une lettre hors de l'hexadécimal. Quand un portefeuille refuse d'importer votre descripteur, comptez d'abord ce champ.

Comment cela fonctionne

Le BIP-32 donne à une clé étendue deux identités de longueurs différentes, et l'empreinte est la plus courte. L'identifiant est le Hash160 de la clé publique sérialisée, RIPEMD-160 sur SHA-256, le code de chaîne étant ignoré, et seuls les 32 premiers bits de cet identifiant sont appelés empreinte. Les 128 autres bits ne sont pas jetés : le BIP-32 indique que l'identifiant complet de 160 bits pourrait servir en interne, tandis que la forme courte ne sert qu'à détecter rapidement les nœuds parents et enfants, si bien qu'un logiciel doit être prêt à gérer les collisions.

La cohérence entre un champ d'empreinte et la clé qui l'entoure est une règle de validité, pas une convention. Une clé maîtresse n'a pas de parent et inscrit 0x00000000 dans son champ d'empreinte parent, et le cinquième vecteur de test du BIP-32, celui qui couvre les clés devant être reconnues comme invalides, liste à la fois un xprv et un xpub portant une profondeur nulle avec une empreinte parent non nulle. Un logiciel qui importe l'une ou l'autre de ces chaînes sans broncher ne suit pas la spécification, ce qu'il vaut la peine de savoir avant de lui confier une restauration.

Où cela se voit

Les empreintes de clé figurent avant tout dans deux formats lisibles par machine, les descripteurs de script de sortie et les transactions bitcoin partiellement signées, et dans les deux elles se placent juste devant un chemin de dérivation.

Le BIP-380 place les informations d'origine de clé entre crochets avant la clé et se montre strict sur la largeur : exactement 8 caractères hexadécimaux, puis les étapes durcies et non durcies. Sa liste d'expressions invalides nomme trois échecs de ce seul champ : deadbef à sept caractères, deadbeeef à neuf, et gaaaaaaa commençant par une lettre qui n'est pas un chiffre hexadécimal. Les trois sont rejetés d'emblée, si bien qu'une empreinte mal saisie vous coûte une erreur d'import plutôt qu'un portefeuille surveillant discrètement la mauvaise branche.

Le BIP-174 associe une empreinte de 4 octets à un chemin écrit sous forme d'entiers little endian de 32 bits, et pour l'entrée de clé publique étendue globale, le nombre de ces entiers doit correspondre à la profondeur que le xpub déclare lui-même. C'est ce nombre qui permet à un signataire de confronter un chemin cité à la clé qui lui a été remise, au lieu de faire confiance à l'étiquette.

Sur l'écran d'un appareil, ces mêmes huit caractères répondent à une question : de quelle phrase de récupération s'agit-il. Ils ne livrent rien de dépensable, car un hachage tronqué ne peut pas être retransformé en clé ni en adresse. Ils restent un identifiant, donc deux descripteurs portant les mêmes huit caractères constituent un lien visible entre ces deux branches.

Empreinte de clé vs adresse bitcoin

Une empreinte de clé et une adresse bitcoin partent du même hachage et cessent d'être comparables immédiatement après. Le BIP-32 note que l'identifiant d'une clé étendue correspond exactement aux données utilisées dans les adresses bitcoin traditionnelles, puis déconseille d'écrire cet identifiant en base58, car il serait lu comme une adresse et un logiciel de portefeuille n'est pas tenu d'accepter un paiement vers la clé de chaîne elle-même. Une empreinte conserve 4 des 20 octets de l'identifiant et s'écrit en hexadécimal simple, si bien qu'elle est trop courte pour être prise pour une destination de paiement, même par accident. Huit caractères hexadécimaux dans un descripteur indiquent de quelle clé un chemin est parti ; une adresse indique où les bitcoins peuvent aller.