Extended Public Key (xpub)

BIP32 represents an extended public key as a public point K paired with a 32-byte chain code c. Its serialization also carries version bytes, depth, parent fingerprint and child number. An xpub is therefore not one address or an ordinary public key: it identifies a hierarchy node and the data needed to continue its public branch.

CKDpub combines the parent public key, chain code and index through HMAC-SHA512. For indices from 0 to 2³¹−1 it produces a child public key and a new chain code, letting an online wallet generate receive and change addresses without a signing secret. It derives only descendants of the exported node, not siblings or ancestors.

Hardened indices begin at 2³¹ and are written with an apostrophe or h. Their derivation uses private data, so CKDpub from a parent xpub fails. Wallets commonly harden purpose, coin type and account, then export an account xpub; disclosure of that account's public branch alone does not open other hardened accounts.

A BIP32 serialization is 78 bytes: four version bytes, depth, parent fingerprint, child number, chain code and 33 bytes of key material. Base58Check renders it as 111 characters; the mainnet public version begins xpub and testnet begins tpub. The prefix is an effect of version bytes, not a separate cryptographic key species.

A BIP32 xpub does not state whether derived keys belong in P2PKH, wrapped SegWit, native SegWit, Taproot or multisig scripts, and without key-origin data its location may be ambiguous. SLIP-0132 introduced ypub, zpub and other versions as address-type hints, while descriptors state the script, fingerprint, path, xpub, wildcard and checksum explicitly.

Anyone holding an account xpub can calculate all non-hardened receive and change public keys in its branch and correlate their transactions and balances. Giving it to accounting software or pasting it into a public block explorer creates a durable view of the account and may connect network or identity data with on-chain history.

An xpub alone normally cannot sign. BIP32's critical exception is that a parent xpub plus one private key of its non-hardened descendant reveals the parent private key and therefore the rest of that branch. Extended public keys should be protected as sensitive data, and hardened account boundaries prevent this failure from climbing into other accounts.

A watch-only wallet can monitor an xpub, construct an unsigned transaction and pass it to a signing device. A shop can generate unique receive addresses on a server without storing an xprv. This limits direct theft after server compromise, not payment surveillance; a receive address should still be checked on a trusted signing-device display.

In multisig, possessing one's own seed is not the complete wallet configuration: exact recovery needs cosigner public keys, threshold, script type and derivation data. A descriptor records this policy more precisely than loose xpubs. An eight-hex-character master fingerprint helps match keys but is not proof of identity and can collide.

Before import, establish the network, account and derivation path, expected script type, receive/change branch and index range. Compare the xpub or descriptor on a trusted device, derive several addresses and match them in the source wallet; never submit an xpub to a third-party explorer without consciously accepting the privacy loss. 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)?.