From a zpub to your private key: the hidden risk most people miss

By mordom

Imagine a normal situation.

You have a hardware wallet. You want to monitor activity without plugging it in every time. Or you need to share addresses with your accountant. Or you’re using a watch-only app.
So you export a zpub (an extended public key) and share it.

The assumption is simple:

“I’m only sharing public addresses. There’s no risk.”

That’s where things get misleading.
Because what you’re sharing is not a list of addresses. It’s a key that can generate all of them, deterministically.
And under certain conditions, it can expose more than you expect.

This article explains exactly how.

Let’s get the terminology straight

We’ll keep this simple.

• Mnemonic (12/24 words) What you write down and store.
• Seed The binary data derived from the mnemonic. Not the same thing.
• Root key The first private key derived from the seed. Everything comes from here.
• zpub (extended public key) A public key that can derive other public keys (native SegWit in this case). We’ll use “zpub” for simplicity, but the concept applies to xpub, ypub, etc.
• Child keys
  • private
  • public

A wallet isn’t a single key.
It’s a tree of keys.

What a zpub actually does

A zpub does not contain private keys.
But it can:

• generate all child public keys
• generate all addresses
• reconstruct the entire observable side of your wallet

That’s exactly how watch-only wallets work.
So yes, it’s public.

But it’s also a generative key.

Quick reminder

If you want a full breakdown of hardened vs non-hardened, check our previous post on this topic here: 👉 https://blog.bitvault.sv/hardened-vs-non-hardened-addresses/

For this article, just remember:

there are two derivation modes

and they behave very differently

The two modes

➤ Hardened

• derivation requires the private key
• with a zpub you cannot derive child public keys
• you cannot expand the branch

👉 in practice:

with a zpub alone, you can’t generate anything

This is isolation.

➤ Non-hardened

• you have a zpub
• you can derive all child public keys
• indices match between public and private keys

👉 in practice:

zpub → all child public keys

This is what enables watch-only wallets.

But it comes with a trade-off.

The critical point

Consider this combination:

• a zpub
• a single child private key
• and the derivation index

👉 In this case:

you can recover the parent extended private key

In other words:

the key that was never supposed to leave the wallet

Intuition (no math)

Derivation isn’t magic. It’s a deterministic transformation.

You start from a parent key, apply a function, and get a child key.

In non-hardened derivation, that function also uses public data — data that is already contained in the zpub.

That’s the key detail.

If you have a child private key, and at the same time you have the zpub (which lets you compute that public “factor”) and you know the index, you have all parts of the equation.

At that point, you’re not just moving forward anymore. You can go in reverse.

You simply move that factor to the other side of the equation.

And you’re back at the parent key.

this isn’t magic: it’s a mathematical relationship between keys

(see technical note at the end)

The real implication

If you can recover the parent private key:

• you can derive all sibling private keys
• you can move further up the hierarchy
• you can compromise the entire branch

This isn’t automatic, but it is structurally possible.
At that point, you’re no longer talking about privacy.
You’re talking about control over funds.

No need for exotic attacks. This shows up in real scenarios:

• Poorly designed software (exposes the zpub, mishandles private keys, logs sensitive data)
• Server + client architectures (server uses the zpub for address generation, client signs transactions — if a child private key leaks, the server already has the other half)
• Operational mistakes (debug exports, partial backups, unsafe data sharing)

Different situations, same outcome: the wrong combination of data.

Why wallets use hardened derivation

This isn’t accidental.

Wallets use hardened derivation at critical levels to:

prevent upward recovery toward the root key

It creates a boundary.

And that boundary exists for exactly this reason.

What is NOT a risk

Let’s be clear:

👉 sharing a zpub alone does not compromise your wallet

You also need:

• a child private key
• and the right context

So:

• watch-only wallets → safe
• sharing with third parties → generally safe

The risk comes from combination, not from a single element.

Best practices

• never export child private keys
• avoid hybrid architectures unless you fully understand them
• use standard wallets
• treat your zpub as sensitive data

In short

When you share a zpub:

• you’re not sharing “just addresses”
• you’re sharing a generative structure

On its own, it’s safe.

But it’s not harmless.

not all information is harmless, even when it looks public

Technical note (with some formulas…)

Let’s formalize the key idea.

Ranges

• Non-hardened: 0 → 2³¹ - 1
• Hardened: 2³¹ → 2³² - 1

Non-hardened derivation

Child private key:

k_i = k_parent + H(K_parent, chaincode, i)

Where:

• k_parent → parent private key
• K_parent → parent public key (from zpub)
• i → index
• H(...) → deterministic function

The critical step

If you know:

• k_i (child private key)
• K_parent (from zpub)
• i

You can:

👉 move the H(…) term to the other side of the equation

k_parent = k_i - H(K_parent, chaincode, i)

And recover the parent private key.

Hardened derivation

k_i = k_parent + H(k_parent, chaincode, i)

👉 the hash function is based on the private key.

So:

• it cannot be computed from a zpub
• it cannot be reversed using public data

Final note

This is not a bug.

It’s a property of BIP32:

non-hardened derivation becomes reversible when public data is combined with a child private key

And that’s exactly why hardened derivation exists and is used in critical parts of wallet structures.

If you’re exploring more robust ways to structure your Bitcoin security, you can take a look at BitVault‘s security approach.