HD Wallets & Quantum Risk: Does reusing one address endanger the rest?

We recently released version 2 of our Bitcoin Risq List tracking quantum vulnerable Bitcoin, and one question came up straight away: in a HD wallet, if all keys come from the same seed, why isn’t every address vulnerable once one address is vulnerable?

The short answer is that reusing one address does not automatically put your other HD addresses at risk. In a BIP‑32 HD wallet (such as Ledger Live, Trezor Suite, Electrum, etc.), each address has its own private key. They all come from the same seed, but they do not “share the same private key”.

When you spend from an address, that address’s public key becomes visible on-chain. When a cryptographically relevant quantum computer arrives, Shor’s algorithm could recover the private key from any exposed public key. Reusing an address keeps that same public key out in the open, making it a long‑lived target. Using a fresh address limits what’s exposed.

For more on this, check out our post on the quantum vulnerabilities of various Bitcoin address types here.

The Bitcoin Risq List flags addresses, not wallets. For example, if you used 10 addresses and only the 10th was reused/spent‑from, the tracker will mark the 10th as at risk and the other 9 as safe (no public key exposure). That’s the right mental model: risk follows public key exposure, not the seed.

We have written about this extensively on our blog, but in order to make this post complete it’s worth reiterating here.

Both ECDSA (secp256k1) and EdDSA (e.g., Ed25519) are elliptic‑curve signatures. A sufficiently powerful quantum computer running Shor’s algorithm could derive a private key from a known public key. That’s the whole threat model here.

• A single master seed deterministically creates a tree of keys.
• Each address sits at a path like m / purpose' / coin' / account' / change / index.
• Keys at the same level with different indexes are siblings (e.g., …/0/3, …/0/10).
• Parent = chop off the last step (…/0 is parent of …/0/10).
• Child = add a step (…/0/10/5 would be a child of …/0/10).

Default case (what people actually use):

If the 10th address (…/0/10) is reused and somehow cracked in a future quantum world, only that key is compromised. Its siblings (…/0/3, …/0/4, …/0/11, …) remain safe. You cannot “climb up” to the parent or “hop sideways” to siblings just from that one cracked key.

Children of the cracked key:

Cryptographically, if a wallet ever used …/0/10 as a parent (e.g., creating …/0/10/5), those descendants would also be compromised. But mainstream wallets don’t do this. They don’t create grandchildren under an address; they keep addresses as leaves. In practice, this “downward” risk doesn’t happen.

More explicitly, mainstream wallets (Ledger Live, Trezor Suite, Electrum, etc.) do not derive “children of children” for addresses. Addresses are treated as leaves at /change/index. New addresses are made by incrementing the index (creating siblings), not by adding deeper levels (creating grandchildren).

Which address is exposed (3rd vs 10th) doesn’t change the logic:

If …/0/3 is cracked, …/0/3 is compromised (and any hypothetical children under it, which wallets don’t create). Siblings like…/0/1, …/0/2, …/0/10 remain safe.

The xpub caveat (important edge case)

Bitcoin‑style paths typically use non‑hardened derivation at the last two levels (change and index). That allows public‑side derivation of child public keys from an xpub (extended public key = parent pubkey + chain code).

In a classical attack, if an attacker has both the parent xpub for a branch (e.g., m/…/0) and any one child private key under that branch (e.g., m/…/0), then BIP-32 math lets them recover the parent private key for that branch and sweep all siblings (m/…/0/*).

In a quantum attack setting, simply leaking your xpub is enough for an attack to derive your master private key (xpriv) using Shor’s algorithm.

However, on‑chain activity alone does not reveal your xpub. This is mainly a risk if you share xpubs with third parties (watch‑only services, analytics, plugins). Treat xpubs as sensitive.

EdDSA nuance: Many Ed25519 HD schemes use hardened‑only derivation, which avoids that xpub escalation path entirely. But EdDSA keys still aren’t quantum‑safe; once a public key is exposed, that specific key is a quantum target, same as ECDSA.

Your seed phrase (12/24 words → master seed) is protected by strong hashing in BIP‑32. Even with quantum speedups, brute‑forcing a 512‑bit preimage is still astronomically hard. The weak point in a quantum world is any address whose public key is on‑chain. That’s what attackers would target.

For much more on this, have a read of our two-part series on why seeds are quantum secure and the impact that has on EdDSA and ECDSA, here and here.

• Don’t reuse addresses. After you spend, that public key is exposed forever; don’t keep using it.
• Assume address‑level risk. One exposed address ≠ whole wallet.
• Treat xpubs as sensitive. Avoid sharing account xpubs widely.
• Stay standard. Use mainstream and up-to-date wallets. These keep addresses as leaves and avoid odd derivation depths.
• Watch for PQ upgrades. Over time the ecosystem will add post‑quantum options. When they arrive, move long‑term funds to PQ‑safe addresses.

Bottom line: HD wallets do not “share a single private key”. In the BIP‑32 model most people use, addresses are independent siblings at the leaves. Reusing one address can endanger that key in a quantum future, but it doesn’t automatically pull the rest down with it.