TL;DR
Bitcoin is not quantum-safe on any address type today. Legacy (P2PKH) and native SegWit (P2WPKH) hide the public key behind a hash until you spend — giving never-spent UTXOs a narrow protection window. Taproot (P2TR) outputs publish the raw public key immediately, eliminating that window. None of these schemes survive a large quantum computer running Shor's algorithm; genuine quantum safety requires a new output type carrying ML-DSA (FIPS 204) or SLH-DSA (FIPS 205) signatures, activated by a Bitcoin soft-fork.
The quantum threat model for Bitcoin
Bitcoin signs with ECDSA on the secp256k1 curve (and Schnorr, same curve, for Taproot). Shor's algorithm on a fault-tolerant quantum computer breaks discrete-log on that curve in polynomial time. Two things follow:
- Any public key on-chain is harvestable. Not just from now on — an attacker can record public keys today and derive the private key once hardware arrives ("harvest now, decrypt later").
- Hashing the public key delays exposure, it doesn't eliminate it.SHA-256 and RIPEMD-160 are not broken by Shor; Grover only gives a square-root speed-up, which halves the effective bit-strength — still comfortable at 256 bits. The window closes the moment you spend, because the spend transaction reveals the pk.
Address-type comparison
Every Bitcoin output type differs in when — and whether — it exposes the raw public key on-chain. That timing is what determines quantum exposure.
| Address type | Prefix | What's on-chain | Quantum protection window | Address reuse risk | Path to post-quantum |
|---|---|---|---|---|---|
| Legacy (P2PKH) | 1… | Hash of public key (RIPEMD160(SHA256(pk))) | Public key revealed only when spent — never-spent UTXOs stay hashed | Reuse fully exposes pk; every subsequent output is directly harvestable | Requires new output type (BIP) with ML-DSA or SLH-DSA verification |
| Nested SegWit (P2SH-P2WPKH) | 3… | Hash of a script that hashes the public key | Same as P2PKH — hashed until spend | Same reuse penalty as P2PKH | Same BIP path as native SegWit |
| Native SegWit v0 (P2WPKH) | bc1q… | Hash of public key (HASH160) | Hashed until spend; cheapest hashed address today | Reuse exposes pk permanently | SegWit versioning allows a v2/v3 opcode set for ML-DSA outputs |
| Taproot (P2TR, SegWit v1) | bc1p… | Raw 32-byte x-only public key (no hash) | None — pk is on-chain from the moment the UTXO is created | Reuse doesn't matter; the pk is already public on first funding | SegWit version increment (v2+) for post-quantum tapscript alternatives |
| Hypothetical P2QRH (proposed) | bc1r… (illustrative) | Commitment to ML-DSA or SLH-DSA public key | Full — signatures verified against a post-quantum scheme | Reuse safe; scheme is quantum-secure | Requires a BIP + soft-fork activation; larger witness size |
Why Taproot outputs are the most exposed
Taproot (BIP-341) commits directly to a 32-byte x-only Schnorr public key in the output script. Unlike P2PKH or P2WPKH, there is no hash step — the key is the scriptPubKey (modulo the SegWit version byte). Consequences:
- Every funded Taproot UTXO exposes its pk from block one.
- Address reuse is irrelevant to quantum risk here — reuse is already the default state.
- Privacy and script flexibility gains from Taproot are real; the trade-off is that hashed-key protection disappears entirely.
This is why some proposals for post-quantum Bitcoin (e.g. draft P2QRH ideas) suggest a new SegWit version that commits to a hash of a post-quantum public key, restoring the hashed-until-spend property under a quantum-secure scheme.
What post-quantum Bitcoin actually needs
Three protocol-level pieces:
- A new signature scheme. ML-DSA (FIPS 204, lattice) is the fastest candidate — signatures ~2.4 KB. SLH-DSA (FIPS 205, hash-based) is more conservative but produces ~8-30 KB signatures, expensive on-chain.
- A new output type. Almost certainly a SegWit version increment (v2 or higher) so the witness carries the post-quantum signature and old nodes continue to accept the transaction as anyone-can-spend under a soft-fork.
- A migration path. Users must be able to sweep classical UTXOs into post-quantum outputs before a quantum adversary appears. That's a coordination problem larger than the cryptographic one.
ML-KEM (FIPS 203) is not part of on-chain Bitcoin — it's the tool wallets use to protect the channel between hardware device and host, and to encrypt cloud backups. See our wallet comparison for where each vendor sits on ML-KEM adoption.
What to do today
- Prefer P2WPKH (bc1q…) for cold storage over P2TR (bc1p…). The hashed public key gives you a genuine — if narrow — protection window.
- Never reuse addresses. Every spend reveals your public key permanently. A hashed address you've spent from is equivalent to a Taproot address for quantum purposes.
- Sweep old, reused UTXOs into fresh addresses. Especially any addresses whose pk is already on-chain from prior spends.
- Follow BIP activity on post-quantum output types. Activation is what will actually move Bitcoin's quantum posture, not vendor firmware.
- Scan specific addresses. Run any Bitcoin address through the Wallet Scanner for a rules-based exposure score.
Nothing on this page is financial, investment, or security advice. See methodology and editorial policy.
Frequently asked questions
What is a quantum-safe Bitcoin wallet?
A quantum-safe Bitcoin wallet would sign transactions with a NIST post-quantum signature scheme — ML-DSA (FIPS 204) or SLH-DSA (FIPS 205) — instead of ECDSA or Schnorr. No such wallet exists on Bitcoin mainnet today because the protocol itself does not yet accept post-quantum signatures. What you can do today is minimise exposure by using address types that keep the public key hashed until spend, and avoiding address reuse.
Are Taproot (P2TR) addresses quantum-safe?
No. Taproot outputs expose the raw 32-byte x-only public key on-chain from the moment they are funded, so a large quantum computer running Shor's algorithm could derive the private key without waiting for a spend. Legacy P2PKH and SegWit v0 P2WPKH addresses hash the public key until spend, which gives a narrow additional protection window — but only for never-spent coins.
Is my Bitcoin already at risk today?
No cryptographically relevant quantum computer exists in 2026. Current NIST estimates and public roadmaps from IBM, Google, and Quantinuum put a Shor-capable machine years out at minimum. The realistic risk today is 'harvest now, decrypt later' — an attacker recording exposed public keys now to break them in the future. Coins on address types whose public key is already on-chain (any spent address, all Taproot outputs) are the harvest-now surface.
What's ML-KEM's role for Bitcoin?
ML-KEM (FIPS 203) is a post-quantum key-encapsulation mechanism — it protects confidentiality of key material in transit, not on-chain signatures. Wallets can adopt ML-KEM unilaterally for host↔device channels and cloud backup; Bitcoin itself does not use KEMs. On-chain quantum safety requires ML-DSA or SLH-DSA activation via a BIP.
What can I do right now to protect Bitcoin from quantum risk?
Use fresh, never-spent P2WPKH or P2PKH addresses for cold storage, avoid address reuse, sweep old UTXOs to new hashed addresses, and follow BIP activity around post-quantum signatures. Run a specific address through /wallet-scanner to see rules-based exposure.