Extended Public Key (xpub)

Anna keeps her Bitcoin wallet on a hardware device and wants to check on her phone whether a customer has paid. She transfers the public configuration of the selected account, including its xpub, to the phone, but no private keys. The phone then acts as a Watch-only Wallet: it can monitor the relevant addresses, prepare a new one and construct an unsigned transaction. Spending still requires a signature from the device holding the secret keys. Similarly, a shop can generate different receiving addresses for orders without storing spending keys on its server. This separation limits the consequences of a server compromise, but does not solve everything: an attacker could show customers the attacker’s own address for a new payment. [1] [5]

You give an ordinary Bitcoin address to someone who needs to pay you. An xpub offers a much broader view. Anyone with an account xpub and its address construction rules can derive receiving addresses and addresses for returning change, then link their histories and balances. This covers the derivable branch, not automatically every account in the wallet. If you give the xpub to an accounting service or a third-party block explorer, it can keep a copy and monitor later payments too. Disconnecting the app cannot revoke a copy already shared. For a single payment, one address is usually enough; give broader access only where it serves a real purpose. [1] [5]

A BIP32 wallet creates a tree of keys from one starting point. Here, a branch means a group of derived keys, not part of the network or blockchain. An xpub can continue downward only through steps called non-hardened. The other kind, Hardened Derivation, requires private data and creates a boundary the xpub alone cannot cross. A common BIP44 layout places such a boundary before each account. Exporting one account’s xpub therefore does not by itself expose other accounts. Export depth matters too: an xpub for just the receiving branch grants a narrower view than an account xpub, which commonly covers change as well. [1] [6]

Different rules can turn the same public keys into different Bitcoin addresses. A transaction output records an amount and the conditions for spending it later. The application needs to know the wallet’s output type, such as Native SegWit or Taproot, and which branch and sequence numbers to derive. SLIP-0132 prefixes such as ypub and zpub can hint at an address type, but do not fully describe a wallet. An Output Descriptor is more precise: it records keys and the rules that produce addresses and spending conditions. It can include key-origin information, a derivation path and a checksum to detect typing errors. That checksum checks the text, not the trustworthiness of whoever sent it. Not every descriptor is public-only: some contain private keys, so distinguish them before sharing. [2] [3] [4]

First check the network, selected account, address type and derivation path—the instructions that locate a key in the tree. Compare several receiving addresses with the original wallet and, with a hardware wallet, use its trusted display following the manufacturer’s procedure. A matching account name alone is not enough. A zero balance after import does not necessarily mean lost funds: you may be looking at another account, another address type or too narrow a range of address indices. Do not respond by entering recovery words into a random website. If you only need a view, look for a public-configuration export, not a Seed Phrase or xprv, an extended private key. [4] [5]

An xpub alone is not a signing key. However, BIP32 has an important connection: a parent xpub together with a non-hardened descendant’s private key allows recovery of the parent private key. For a more distant descendant, every intervening step must be non-hardened, and the corresponding path must be known for the calculation. This is not theft from knowing an address alone. The dangerous combination is a leaked public view and a leaked secret key from the same branch. It can give an attacker the other keys below that parent too. Hardened boundaries separate accounts, but cannot protect a private key that has already been exposed. [1]

A Multisig wallet might require two signatures from three keys. Knowing which two keys you can recover is not enough, however. Reconstructing the right spending conditions also needs the public data of the other participating keys, their arrangement, the required signature count and derivation rules. Alongside secret backups, keep the wallet configuration—for example a public descriptor containing all the required xpubs. It does not authorize spending, but may be essential to recovery. The master fingerprint, eight hexadecimal characters identifying the starting key, helps match the configuration. It is not a unique identity certificate: two different keys can have the same fingerprint. [4] [5]

A public key is used to verify signatures made with the corresponding private key. BIP32 adds a chain code, a 32-byte value used to derive further keys. Together they form an extended public key. Its portable representation also carries version and tree-position data: depth, the immediate parent’s fingerprint and the child number. That is not the same as a complete path from the wallet’s first key. An xpub is therefore neither a single receiving address nor an account password, and does not contain a list of transactions. The watching wallet looks those up on the blockchain for the relevant addresses. [1]

BIP32’s CKDpub function takes a parent public key, its chain code and a child index. Using HMAC-SHA512, a cryptographic calculation over those inputs, it prepares a further public key and a new chain code. Publicly derivable indices run from 0 to 2³¹−1. Hardened indices start at 2³¹ and are usually marked with an apostrophe or h in paths; CKDpub from an xpub cannot derive them. Repeating permitted steps produces descendants, not siblings or ancestors of the exported key. If a rare invalid result described in BIP32 occurs, the implementation moves to the next index. Ordinary users do not need to perform these calculations; transferring the correct configuration is what matters. [1]

Before text encoding, the standard BIP32 record occupies 78 bytes: version 4, depth 1, parent fingerprint 4, child number 4, chain code 32 and key data 33. Base58Check adds a checksum and turns the record into 111 characters. The public version for Bitcoin’s main network starts with xpub, the test version with tpub; the private equivalents start with xprv and tprv. Tpub does not mean Taproot. A prefix follows from version bytes and does not describe all address rules. Importing software must also validate the public key, not merely check its first letters or length. [1] [3]