Glossary / Addresses & keys
Extended key
Also known as xpub, xprv, Public extended key, Private extended key.
- Definition
- An extended key pairs an ordinary bitcoin key with a 32-byte chain code, and that pair is what lets software derive an entire branch of keys below it.
Specified in BIP-32.
An xpub is not a public key. It is 78 bytes of structure: version, depth, parent fingerprint, child index, the 32-byte chain code, and the key itself, wrapped in Base58Check to produce a string of 111 characters. Give one to an accountant and they can read every address on that branch and every satoshi it has ever received, without being able to spend anything.
How it works
An extended key exists because a bare key cannot produce children. Derivation in BIP-32 hashes the parent's chain code together with its key material and an index, and the chain code supplies the extra entropy that keeps sibling keys unrelated to one another. Remove it and there is nothing left to derive from.
Serialization is fixed at 78 bytes in a strict order: 4 version bytes, 1 depth byte, 4 bytes of parent fingerprint, 4 bytes of child index, 32 bytes of chain code, and 33 bytes of key data. A private extended key pads its 32-byte secret with a leading zero so both forms occupy the same width. The version bytes create the readable prefix: 0x0488B21E writes xpub, 0x0488ADE4 writes xprv, and the testnet equivalents write tpub and tprv.
Two derivation functions operate on these. The public one computes non-hardened children from an xpub alone, which is how a payment processor generates thousands of invoice addresses on a web server that holds nothing spendable. The private one computes anything, hardened indices included, and needs the xprv.
You will also meet ypub, zpub and vpub. Those come from SLIP-0132, a convention that reuses the same 78-byte layout with different version bytes to signal a script type. Bitcoin Core never adopted it, and output script descriptors under BIP-380 replaced the idea properly by naming the script type in full, as in wpkh([1a2b3c4d/84h/0h/0h]xpub.../0/*).
Why this matters when you buy bitcoin
An extended public key is the most sensitive thing you will ever be asked to share that is not technically a secret, and the request usually looks routine.
Three legitimate reasons to export one exist. Setting up a watch-only wallet so a phone can display a hardware wallet's balance. Handing a self-hosted payment processor the branch it should draw invoice addresses from. Assembling a multisig, where each cosigner contributes one xpub and every one of them is needed to rebuild the wallet later, even if all the seed phrases survive.
Everything else deserves suspicion. No exchange reviewed on this site needs an extended key to send you a withdrawal; it needs one address. A support agent asking for an xpub to verify your wallet is running a profiling exercise at best. Anyone asking for an xprv is asking for the coins, and the correct response is to stop the conversation.
The disclosure is also permanent in a way people underestimate. An xpub reveals not only today's balance but every payment on that branch, past and future, because the holder can keep deriving new addresses long after you stop talking to them. There is no revocation. Undoing it means generating a fresh seed and moving every coin, paying a fee on every input you own.
One trap belongs here specifically. If somebody holds your extended public key and also obtains a single non-hardened child private key, they can reconstruct the parent extended private key and spend the whole branch. BIP-32 states this in its own security notes. It is why account levels are hardened, and why exporting an individual key out of a modern wallet, which a few tools still offer, is a dangerous convenience rather than a handy one.
What an accountant can and cannot do with your xpub
Hand over an extended public key and the boundary is sharp. Suppose you export the account extended public key for m/84'/0'/0' from a hardware wallet and email it to whoever prepares your taxes.
They can derive every receiving address and every change address under that account, look each one up on any explorer, and reconstruct a complete dated history of amounts in and out. They can total your current balance to the satoshi and keep watching it change. They can derive addresses you have not used yet and see the moment you do.
They cannot sign anything. Hardened children are unreachable from the public side, so a sibling account such as m/84'/0'/1' stays invisible to them, and so does the master key. They cannot recover a private key from any of it, unless you separately hand over one of the individual keys underneath, which is the failure case described above.
Extended key vs public key
A public key is a point on the secp256k1 curve, 33 bytes when compressed, and it verifies signatures. An extended public key is that same point plus a 32-byte chain code and four fields describing its position, and it can produce billions of further public keys. Publishing a public key discloses one output's worth of information. Publishing an extended public key discloses a wallet.
Extended key vs Wallet Import Format
An xprv and a Wallet Import Format string both encode key material in Base58, and the resemblance ends there. A WIF string holds one private key with a network byte and a checksum, useful for moving a single legacy key, and importing it recovers exactly the coins locked to that key. An xprv holds a key plus the chain code and position that let it regenerate an unlimited branch. The asymmetry is what catches people out: sweeping a WIF into a modern wallet is routine housekeeping, while pasting an xprv into unfamiliar software hands over everything beneath it at once.