Un xpub n’est ni une adresse Bitcoin ni une clé de signature. Il exporte un nœud BIP32 pour qu’un wallet watch-only ou un serveur de réception génère les clés et adresses situées dessous. Il ne permet normalement pas de dépenser, mais révèle la branche; le sens des adresses dépend aussi du derivation path et de la script policy.
BIP32 représente une clé publique étendue par le point public K et un chain code c de 32 octets. La sérialisation porte aussi version bytes, depth, parent fingerprint et child number. Un xpub n’est donc pas une adresse isolée: il identifie un nœud hiérarchique et les données permettant de poursuivre sa branche publique.
CKDpub combine parent public key, chain code et index avec HMAC-SHA512. Pour les index de 0 à 2³¹−1, il produit une child public key et un nouveau chain code; un wallet en ligne génère ainsi adresses receive et change sans secret de signature. Seuls les descendants du nœud exporté sont accessibles.
Les index hardened commencent à 2³¹ et s’écrivent avec une apostrophe ou h. Leur dérivation emploie des données privées, donc CKDpub échoue depuis un parent xpub. Les wallets durcissent généralement purpose, coin type et account avant d’exporter l’account xpub, séparant les autres comptes hardened.
La sérialisation BIP32 fait 78 octets: version, depth, parent fingerprint, child number, chain code et 33 octets de key material. Base58Check produit 111 caractères; la version publique mainnet commence par xpub et testnet par tpub. Le préfixe résulte des version bytes.
Un xpub n’indique pas si les clés servent à P2PKH, wrapped SegWit, native SegWit, Taproot ou multisig, et son emplacement peut rester ambigu. SLIP-0132 introduit ypub, zpub et d’autres versions comme indices; un descriptor déclare explicitement script, fingerprint, path, xpub, wildcard et checksum.
Le détenteur d’un account xpub calcule toutes les public keys receive et change non hardened et peut corréler transactions et soldes. Le transmettre à un logiciel fiscal ou à un block explorer public crée une vue durable du compte et peut relier données réseau ou identité à l’historique on-chain.
Un xpub seul ne signe normalement pas. Exception critique de BIP32: parent xpub plus private key d’un descendant non hardened permet de retrouver la parent private key et toute la branche. Il faut donc protéger l’extended public key comme donnée sensible et placer des limites account hardened.
Un wallet watch-only suit le xpub, construit une transaction non signée et la remet au dispositif de signature. Un commerce génère des adresses uniques sans conserver de xprv. Cela limite le vol direct après intrusion, pas la surveillance; l’adresse de réception reste à contrôler sur l’écran fiable du signataire.
En multisig, son propre seed ne suffit pas à décrire le wallet: la restauration exacte exige public keys des cosigners, threshold, script type et données de dérivation. Un descriptor conserve mieux cette policy que des xpubs isolés. Le master fingerprint sert au rapprochement, pas à prouver une identité, et peut entrer en collision.
Avant import, déterminer network, account, derivation path, script type, branches receive/change et plage d’index. Comparer xpub ou descriptor sur un appareil fiable, dériver plusieurs adresses et les confronter au wallet source; ne jamais utiliser un explorer tiers sans accepter consciemment la perte de confidentialité. Sources: BIP 32 — Hierarchical Deterministic Wallets; BIP 380 — Output Script Descriptors General Operation; SLIP-0132 — Registered HD Version Bytes; Bitcoin Core — Output Descriptors; Trezor — What Is a Public Key (XPUB)?.
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.