Le fingerprint BIP32 est constitué des premiers 4 octets du HASH160 d’une clé publique compressée. HASH160 applique SHA-256 puis RIPEMD-160, deux fonctions qui calculent des empreintes numériques des données. Les 32 bits obtenus s’affichent généralement sous forme de 8 caractères hexadécimaux, chiffres et lettres. Le chain code, donnée supplémentaire servant à dériver d’autres clés, n’entre pas dans cette courte empreinte.
Imaginez des documents concernant plusieurs portefeuilles que vous devez distinguer. Le fingerprint sert d’étiquette calculée à partir de la clé publique dans son encodage précisément défini. Ce n’est pas un hash direct des mots de sauvegarde ou de la clé privée. Cette étiquette seule n’est pas une adresse de réception, ne peut pas signer de paiement et ne permet pas de restaurer les clés. La noter ne remplace donc pas une sauvegarde capable de restaurer réellement le portefeuille. [1]
BIP32 construit un arbre de clés : d’autres clés dérivent d’une clé maîtresse, comme des branches d’un tronc commun. L’enregistrement d’une clé publique étendue, xpub, ou privée, xprv, contient le fingerprint de sa clé parente, située un niveau au-dessus. La clé maîtresse n’a pas de parent, donc ce champ contient 00000000. Ce n’est pourtant pas son propre fingerprint. Une application peut afficher l’empreinte propre de la clé maîtresse ; avant de comparer, identifiez le champ que vous lisez. [1]
La clé maîtresse du vecteur de test public BIP32 numéro 1 a pour fingerprint propre 3442193e. Pourtant, le champ parent de son xpub maître contient 00000000. Aucune contradiction : une valeur décrit la clé elle-même, l’autre son parent inexistant. Un vecteur de test est un ensemble publié d’entrées et de résultats attendus permettant de vérifier un programme. N’utilisez jamais ces données publiques pour créer un portefeuille destiné à votre argent. [1]
PSBT est un ensemble de données de transaction que l’on peut transmettre à un dispositif de signature. Selon BIP174, il associe le fingerprint maître à un chemin de dérivation : les étapes menant à une clé publique précise. Un Output Descriptor, description textuelle des clés et des conditions de dépense, peut aussi indiquer l’origine d’une clé. Pour vérifier la monnaie rendue lors d’un paiement, le dispositif ne peut pas se contenter d’une empreinte identique. Il doit dériver et comparer la véritable clé et les conditions correspondantes, afin de ne pas prendre une sortie étrangère pour l’une des siennes. [2] [3]
Une courte empreinte économise de la place, mais son domaine est limité : 32 bits ne permettent que 4294967296 valeurs. Des clés différentes peuvent donc avoir le même fingerprint. C’est une collision, et BIP32 exige explicitement que les logiciels sachent la gérer. Une correspondance ne vérifie pas tous les comptes, chemins de dérivation ou types de scripts, c’est-à-dire les règles de dépense. Elle ne prouve pas non plus que vous possédez les clés privées nécessaires. [1] [3]
Vérifiez d’abord que vous comparez le même type d’empreinte au même niveau de l’arbre. Une différence peut signaler un autre seed, la base secrète des clés, ou une autre passphrase, un mot de passe supplémentaire. Avant de conclure, écartez une confusion entre les champs maître et parent. Complétez la comparaison par la vérification d’adresses connues, des chemins de dérivation et des règles de dépense. Le fingerprint est un contrôle partiel utile, mais ne remplace pas une sauvegarde bien conservée et une procédure de restauration vérifiée. [1] [3]
Pour une vision complète, lisez aussi HD Wallet, PSBT, BIP39 passphrase, Output Descriptor. Cette entrée est également citée par SeedQR.