Une Extended Public Key (xpub) suit BIP32, un ensemble de règles qui organisent les clés d’un portefeuille. Elle permet de calculer d’autres clés publiques dans une partie précise du portefeuille et, avec les bonnes règles d’adresses, de préparer la réception et de suivre les paiements. Dépenser exige toutefois une signature numérique : une autorisation cryptographique de la transaction. Cette signature est créée avec une clé privée, que le xpub ne contient pas. Le xpub ne remplace donc ni les clés privées ni la Seed Phrase, la sauvegarde du portefeuille notée sous forme d’une suite de mots.
Anna utilise un portefeuille matériel et veut vérifier sur son téléphone si un client l’a payée. Elle y transfère la configuration publique du compte choisi, comprenant son xpub, mais aucune clé privée. Le téléphone devient une Watch-only Wallet : il peut surveiller les adresses concernées, en préparer de nouvelles et construire une transaction non signée. Dépenser exige toujours la signature de l’appareil qui conserve les clés secrètes. De même, une boutique peut générer des adresses différentes pour ses commandes sans stocker de clés de dépense sur son serveur. Cela limite les conséquences d’un piratage, sans tout résoudre : l’attaquant pourrait afficher sa propre adresse aux clients pour un nouveau paiement. [1] [5]
Tu donnes une adresse Bitcoin ordinaire à quelqu’un qui doit te payer. Un xpub offre une vue bien plus large. Avec le xpub d’un compte et ses règles d’adresses, on peut calculer les adresses de réception et de retour de monnaie, puis relier leurs historiques et leurs soldes. Cela concerne la branche dérivable, pas automatiquement tous les comptes du portefeuille. Un service comptable ou un explorateur tiers auquel tu fournis le xpub peut le conserver et suivre aussi les paiements futurs. Déconnecter l’application ne révoque pas une copie déjà transmise. Pour un paiement, une adresse suffit généralement ; n’accorde un accès plus large que s’il répond à un véritable besoin. [1] [5]
Un portefeuille BIP32 crée un arbre de clés à partir d’un point de départ unique. Une branche désigne ici un ensemble de clés dérivées, pas une partie du réseau ou de la chaîne de blocs. Un xpub ne peut descendre que par des étapes dites non-hardened. L’autre type, Hardened Derivation, exige des données privées et forme une frontière que le xpub seul ne franchit pas. Une organisation courante selon BIP44 place cette frontière avant chaque compte. Exporter le xpub d’un compte ne révèle donc pas à lui seul les autres. La profondeur d’export compte aussi : le xpub de la seule branche de réception donne une vue plus restreinte que celui du compte, qui couvre généralement aussi le retour de monnaie. [1] [6]
Les mêmes clés publiques peuvent produire différentes adresses Bitcoin selon les règles appliquées. Une sortie de transaction indique un montant et les conditions permettant de le dépenser ensuite. L’application doit connaître le type de sortie du portefeuille, par exemple Native SegWit ou Taproot, ainsi que la branche et les indices à dériver. Les préfixes ypub et zpub de SLIP-0132 peuvent indiquer un type d’adresse, mais ne décrivent pas tout le portefeuille. Output Descriptor est plus précis : ce texte consigne les clés et les règles qui produisent les adresses et les conditions de dépense. Il peut inclure l’origine des clés, le chemin de dérivation et une somme de contrôle contre les erreurs de saisie. Celle-ci vérifie le texte, pas la fiabilité de son expéditeur. Tous les descripteurs ne sont pas uniquement publics : certains contiennent des clés privées. Fais la distinction avant de partager. [2] [3] [4]
Vérifie d’abord le réseau, le compte choisi, le type d’adresse et le chemin de dérivation, c’est-à-dire les instructions qui situent la clé dans l’arbre. Compare plusieurs adresses de réception avec le portefeuille d’origine et, pour un portefeuille matériel, utilise son écran de confiance selon la procédure du fabricant. Un nom de compte identique ne suffit pas. Un solde nul après import ne prouve pas une perte : tu observes peut-être un autre compte, un autre type d’adresse ou une plage d’indices trop courte. Ne saisis pas tes mots de récupération sur un site au hasard pour y remédier. Pour consulter seulement, cherche un export de configuration publique, pas la Seed Phrase ni un xprv, la clé privée étendue. [4] [5]
Un xpub seul n’est pas une clé de signature. BIP32 comporte toutefois une relation importante : le xpub parent, appelé parent xpub dans la documentation, associé à la clé privée d’un descendant non-hardened permet de retrouver la clé privée du parent. Pour un descendant plus éloigné, toutes les étapes intermédiaires doivent être non-hardened, et le calcul nécessite de connaître le chemin correspondant. Il ne s’agit pas de voler à partir d’une simple adresse. La combinaison dangereuse est une vue publique divulguée avec une clé secrète divulguée de la même branche. L’attaquant peut alors obtenir les autres clés sous ce parent. Les frontières hardened séparent les comptes, mais ne protègent pas une clé privée déjà révélée. [1]
Un portefeuille Multisig peut exiger deux signatures parmi trois clés. Savoir quelles sont les deux clés que tu peux restaurer ne suffit pourtant pas. Reconstituer les bonnes conditions de dépense exige aussi les données publiques des autres clés participantes, leur organisation, le nombre de signatures requis et les règles de dérivation. Conserve donc la configuration en plus des sauvegardes secrètes, par exemple un descripteur public avec tous les xpub nécessaires. Il n’autorise pas à dépenser, mais peut être indispensable à la restauration. Le master fingerprint, huit caractères hexadécimaux identifiant la clé de départ, facilite la correspondance. Ce n’est pas une pièce d’identité unique : deux clés différentes peuvent avoir le même fingerprint. [4] [5]
Une clé publique vérifie les signatures produites par la clé privée correspondante. BIP32 lui ajoute un chain code, une valeur de 32 octets servant à dériver d’autres clés. Ensemble, ils forment une clé publique étendue. Sa représentation transférable comporte aussi la version et la position dans l’arbre : profondeur, fingerprint du parent immédiat et numéro de l’enfant. Cela n’équivaut pas au chemin complet depuis la première clé du portefeuille. Un xpub n’est donc ni une adresse de réception individuelle ni un mot de passe, et il ne contient pas de liste de transactions. Le portefeuille d’observation les recherche sur la chaîne pour les adresses concernées. [1]
La fonction CKDpub de BIP32 prend la clé publique du parent, son chain code et l’indice de l’enfant. Avec HMAC-SHA512, un calcul cryptographique sur ces entrées, elle prépare une autre clé publique et un nouveau chain code. Les indices dérivables publiquement vont de 0 à 2³¹−1. Les indices hardened commencent à 2³¹ et sont généralement notés avec une apostrophe ou h dans les chemins ; CKDpub à partir d’un xpub ne peut pas les dériver. Répéter les étapes autorisées produit des descendants, pas des frères ni des ancêtres de la clé exportée. Si un rare résultat invalide décrit dans BIP32 survient, l’implémentation passe à l’indice suivant. L’utilisateur n’a pas à effectuer ces calculs : l’essentiel est de transférer la bonne configuration. [1]
Avant encodage en texte, l’enregistrement BIP32 standard occupe 78 octets : version 4, profondeur 1, fingerprint parent 4, numéro de l’enfant 4, chain code 32 et données de clé 33. Base58Check ajoute une somme de contrôle et transforme le tout en 111 caractères. La version publique du réseau principal commence par xpub, celle de test par tpub ; leurs équivalents privés commencent par xprv et tprv. Tpub ne signifie pas Taproot. Le préfixe provient des octets de version et ne décrit pas toutes les règles d’adresses. À l’import, le logiciel doit aussi valider la clé publique, pas seulement ses premières lettres ou sa longueur. [1] [3]
Pour une vision complète, lisez aussi HD Wallet, Watch-only Wallet, Confidentialité de Bitcoin, Derivation Path, Bitcoin, Output Descriptor. Cette entrée est également citée par HD Wallet, Cold Storage, Watch-only Wallet, Output Descriptor.