Note

An xpub Is Not a Public Key: What Sharing an Extended Public Key Actually Exposes

An extended public key is a public key plus a chain code. Shared, it reveals every past and future address in its subtree, and with one leaked child private key it gives up the parent private key. BIP 32 says so directly.

2026-10-30 · self-custody, bip-32, bip-44, xpub, watch-only, hardened-derivation, privacy, silent-payments, civil-liberties

Listen · 9 min · AI voice

Dark CryptoDecentral hex mesh — a single bronze hexagon at the top branches downward into a widening tree of teal cells, every branch faintly lit as if seen through glass; no text.

Wallet software asks for an "xpub" in a lot of friendly places: a watch-only phone app, an accounting tool, a donation page, a point-of-sale plugin. The word "public" suggests the string is like an address, something you can hand out without thinking.

It isn't. Thesis, stated once: an extended public key is a public key plus a chain code, and that pairing gives away two things a plain public key never does: every past and future address in its subtree, and, combined with one leaked child private key, the parent private key itself. BIP 32, the standard that defines xpubs, says so directly. Share one when the trade is worth it, scoped as narrowly as the job allows.

What is actually inside an xpub

BIP 32 extends ordinary keys with "an extra 256 bits of entropy" called the chain code. An extended private key is (k, c); an extended public key is (K, c), where K is the public point for k and c is the same chain code. Serialisation adds depth, parent fingerprint and child index, and base58 turns it into the familiar xpub… string.

The chain code is what makes derivation work. To get a child, BIP 32 computes HMAC-SHA512(Key = c_par, Data = ...) and splits the 64-byte result into two halves: the left half (I_L) is added to the parent key, the right half becomes the child's chain code. There are two kinds of child:

Non-hardened (indices 0 to 2³¹−1). The HMAC input is the parent's public key and the index. Anyone holding (K, c) can run it, which is the whole point: a server can generate fresh receive addresses without ever touching a secret.
Hardened (indices 2³¹ and up, written 0h or 0'). The HMAC input is the parent's private key. BIP 32's public derivation function is "only defined for non-hardened child keys" and returns failure otherwise.

BIP 44 lays the tree out as m / purpose' / coin_type' / account' / change / address_index, with an apostrophe meaning hardened. So the first three levels are hardened and the last two, the receive/change split and the address index, are public. The xpub people usually export sits at the account node, m/84'/0'/0' for example, which is exactly the point where public derivation takes over.

Leak one: the whole subtree, past and future

BIP 32 states it plainly: "knowing an extended public key allows reconstruction of all descendant non-hardened public keys." From an account-level xpub, a holder can derive the receive chain (/0/*) and the change chain (/1/*), turn every key into an address, and look each one up.

That is a much bigger disclosure than one address:

The past. Every payment the account has ever received, and every change output it has ever created, which in turn reveals what it spent and when.
The future. The xpub doesn't expire. Every address the account hands out from now on is already computable. Rotating addresses, the usual privacy habit, does nothing against someone who holds the parent.
The scan is mechanical. BIP 44 sets a gap limit of 20: wallets keep deriving until they hit 20 unused addresses in a row. Anyone with the xpub can run the same loop.

The spec's own "Audits" use case describes this as a feature: sharing account xpubs "will allow the auditor to see all transactions from and to the wallet, in all accounts, but not a single secret key." Accurate and honest, and also a description of total financial visibility for as long as the account is used.

The person you give it to is not the only reader. A watch-only app has to learn which addresses have activity, and it usually asks a server. BIP 157 notes that the older Bloom-filter approach for light clients was shown to offer "zero privacy"; asking an address-index server directly tells that server the full address set. Client-side filters and your own node narrow that exposure. A tracker that simply uploads the xpub to its backend hands the whole subtree to the operator, its logs, and anyone who later breaches or subpoenas it.

Leak two: xpub plus one child key equals the parent key

The second leak is the one BIP 32 flags as "a weakness that may not be immediately obvious": "knowledge of a parent extended public key plus any non-hardened private key descending from it is equivalent to knowing the parent extended private key (and thus every private and public key descending from it)."

The mechanism is short. For a non-hardened child, the child private key is k_i = I_L + k_par (mod n), and I_L comes from an HMAC whose inputs are all public: the chain code, the parent public key, and the index. Someone with the xpub can compute I_L for any index. If they ever see one child private key k_i, they subtract: k_par = k_i − I_L. From there, every key in the account is theirs.

How does a single child private key leak in practice? Exporting one address's key to "sweep" it elsewhere. A debugging dump. A signing bug. On its own each exposes one output. Next to an xpub, each exposes the account.

BIP 32 lists this among properties that "do not exist," and gives the reason for hardening: "It is also the reason for the existence of hardened keys, and why they are used for the account level in the tree. This way, a leak of account-specific (or below) private keys never risks compromising the master or other accounts." Hardened derivation is a firewall. It doesn't stop the account from falling; it stops the fall from spreading upward.

Scoping the disclosure

The useful questions are about scope rather than trust.

Which node? BIP 32's "Unsecure money receiver" case shares only the external chain, N(m/iH/0). Someone who compromises that web server "can at most see all incoming payments but will not be able to steal the money, will not (trivially) be able to distinguish outgoing transactions." Change addresses on /1 stay underivable.
Which account? A dedicated account for one purpose (donations, one client, one shop) keeps the visible subtree separate from everything else, because the account level is hardened.
Does the job need an xpub at all? A batch of single addresses is enough for many recurring payments. BIP 352 silent payments were designed for this gap: the motivation names handing out "a method for the sender to generate addresses on-demand, such as an xpub" as the interactive status quo, and the goals include static addresses where transactions "can't be linked to a silent payment address by an outside observer" and "Separates scanning and spending responsibilities." The cost the spec admits is that receivers must scan the chain, which is still hard for light clients.
Does the descriptor say the rest? A bare xpub doesn't state script type or path; BIP 380 descriptors do, and our descriptors note covers why watch-only exports should carry that context.

Who this matters for

Anyone, but some cases sharpen it. A campaign, newsroom or mutual-aid group that posts an xpub-backed donation page lets anyone enumerate every donation the account receives; BIP 44 itself describes donation accounts as ones "where all addresses are considered public." A freelancer who gives a client an account xpub has shown them every other payment into that account. Where financial surveillance is used against dissent, that difference between "one address" and "the whole account" is the difference that matters.

What this is not

This is not an argument against watch-only wallets, PSBT workflows or audits, which rely on xpubs for good reasons and are covered in our PSBT note. It does not claim an xpub alone lets anyone spend; it doesn't, and BIP 32 is explicit about that. It is not a ranking of wallets, trackers or servers, and it makes no claim about how any named product stores what you give it. It is not legal or tax advice about disclosing records to an auditor or authority. It is not a statement about Monero, whose view keys are a different design with their own scope. And it has nothing to do with prices or trading. Spec quotes are from the bitcoin/bips master branch as of 30 October 2026.

The one-line takeaway: an xpub is a read key for an entire subtree, and half of a spend key; share the narrowest node that does the job, and never let it sit next to a child private key.