Quantum and Bitcoin

Where you're going: Bitcoin's signatures rely on math a sufficiently large quantum computer could break. That computer does not exist yet. The math has been understood since 1994. This page walks through what is actually exposed, what is not, what Bitcoin can do about it, and why the answer is governance, not panic.

Quantum is the FUD claim that comes up most often after fiat-debasement and energy. Most of the noise is either doom ("quantum breaks Bitcoin tomorrow") or dismissal ("decades away, ignore it"). Both are wrong. The honest version is more interesting and more useful: the threat is real, the timeline is slow, the fix is governance, and Bitcoin has agency. That last word matters. The system was designed to evolve under exactly this kind of constraint.

The number that lands

About 35.6 percent of circulating supply sits at quantum-exposed addresses as of September 2026, more than one bitcoin in three. That figure moved twice between the Baseline 2026 Q2 measurement and methodology v1.2, and both moves were corrections to the measurement rather than changes on the chain. The original Baseline 2026 Q2 measurement counted 5,071,264 BTC, or 25.3 percent. A parser fix in June 2026 (methodology v1.1) folded in roughly 1.04 million BTC of nested-segwit reuse the first walk had skipped, taking the figure to about 30.5 percent. A second fix a week later (v1.2) found that about half of the old uncompressed-key P2PK coins had been silently dropped by a key-matching bug; repairing it moved P2PK from about 0.85 million to about 1.72 million BTC and the headline to 35.6 percent. ChainQuery caught the second bug by diffing its results against Wicked Smart Bitcoin's independently built count after he open-sourced his pipeline, and credits him for closing the gap.

The breakdown below is the live figure: 7,142,979 BTC across 13,961,993 addresses. Some of those coins are dormant; the reuse-exposed buckets, which make up most of the total, sit at addresses that have been spent from at least once. The largest single bucket is not Satoshi's coins but 2,045,013 BTC at modern segwit (P2WPKH) addresses that were reused at least once, which points to ordinary wallets in everyday use. The Satoshi-era P2PK coins are now the second bucket, about a quarter of the pile.

Snapshot: 2026-09-14, block 967,001, refreshed every Sunday. The full breakdown:

Source: ChainQuery quantum-exposure report, computed on a Bitcoin Core node, weekly Sunday snapshots.

This is not a crisis. It is a forcing function.

The honest version of the number

BIP-361 states that "over 34% of all bitcoin" had revealed a public key on chain as of March 1, 2026. ChainQuery's strict number is about 35.6 percent at block 967,001. Under the Baseline 2026 Q2 measurement the two were nine points apart, and an earlier version of this chapter attributed the gap to methodology.

The conservative rule, the one Wicked Smart Bitcoin's dashboard applies and ChainQuery describes as BIP-361-style parsing, counts every P2SH and P2WSH address whose redeem script was ever revealed on chain. ChainQuery only counts the ones where the revealed script actually contains a pubkey followed by a CHECKSIG-family opcode. Timelock-only scripts get excluded. Hash-preimage scripts get excluded. They do not leak pubkeys on spend.

That distinction is still correct, and it turned out to be worth only tens of BTC. The nine-point gap was two measurement bugs, described above, and once they were fixed the counts converged. The Wicked Smart Bitcoin quantum exposure dashboard applies the conservative BIP-361-style rule directly to chain data and publishes its history: its snapshots give about 34.4 percent at block 950,000 and 35.2 percent at block 961,000, and ChainQuery lands a little above the later one because it measures at a later block. The distance between the three counts is now block-height drift rather than parsing.

That convergence is the reason to trust the figure. An analytic count, a conservative on-chain count, and a strict on-chain count, built by people who disagreed about the rules, arrive at the same answer. We still use ChainQuery's number because it is reproducible from chain data, and we still cite BIP-361 because it is what a proposed soft fork is being written against.

Either way: more than a third of the supply, as of September 2026.

What "quantum-exposed" actually means

There are two classes of exposure. Order matters because the easier case explains the harder one.

Always-exposed. The pubkey is on chain from the moment the output is created. No spend required.

• P2PK (pay-to-public-key): the output script literally contains the pubkey. Satoshi-era coinbase rewards use this. 1,715,227 BTC across 39,465 addresses, almost all of it coinbase rewards that have never moved. The bulk of this slice maps to the Patoshi pattern - the ExtraNonce fingerprint of a single dominant early miner whose blocks account for roughly 22 percent of Bitcoin's first year.
• Bare multisig: the script contains every signer's pubkey. Rare in modern use, still on chain from older deployments, and effectively nothing in the current count.
• P2TR (Taproot, BIP-341): the bech32m address IS the tweaked pubkey. There is no hash layer in front. Every new taproot output is permanently exposed by design. 219,843 BTC across 5,052,695 addresses, and every new taproot output adds to it.

Reuse-exposed. The pubkey is hidden behind a hash on creation, but the spending witness contains the raw pubkey. After the first spend, every future deposit to that address is exposed.

• P2PKH: the legacy "1..." address. 1,190,389 BTC at reused legacy addresses.
• P2WPKH: native segwit "bc1q..." short form. 2,045,013 BTC, the largest single bucket. This is not Satoshi. This is people who upgraded their wallet and kept reusing addresses.
• P2WSH and P2SH: segwit and legacy script-hash forms. Counted as exposed only when the revealed redeem script contains a pubkey push followed by a CHECKSIG-family opcode, or contains OP_CHECKMULTISIG / OP_CHECKMULTISIGVERIFY. The multisig variants matter: most 2-of-3 cold-storage P2SH and P2WSH spends look like that on chain. 708,176 BTC at P2WSH and 1,264,332 BTC at P2SH, most of the P2SH figure being nested-segwit addresses (P2SH-wrapped P2WPKH, plus some P2SH-wrapped P2WSH) whose pubkey is revealed in the witness, the coins the v1.1 correction added.

The protocol does not protect you here. Best practices do.

Cite: BIP-143 (segwit witness structure - where the pubkey gets revealed), BIP-341 (taproot uses the raw tweaked pubkey, no hash layer), BIP-361 (the proposed migration framework).

Why we can't just fix this today

A natural question: if reuse is the biggest bucket, why does this number not just shrink as users migrate to fresh addresses? It does, at the margin. But there are three reasons the figure is sticky, and understanding them is the difference between sensible action and panic.

The reuse pool can drain. The always-exposed pool cannot. Individual action works on the reuse-exposed pool - 4.01 million BTC in the v1.0 baseline, larger once the nested-segwit reuse is folded in: move coins to a fresh address, never reuse it, and that BTC leaves the at-risk pool. Modern wallets default to this. The bleed today is from legacy custody (older exchanges, hardware wallets pre-2020, custom scripts) and from users who manually override the default to consolidate at a single public address.

The always-exposed pool (about 1.94 million BTC, almost all of it in the P2PK and P2TR buckets above) is a different problem. P2PK coinbase rewards from 2009-2010 require the original private keys to move, and a large fraction of those keys are presumed lost forever. Bare multisig has the same lost-key problem at smaller scale. And P2TR has no unreveal: the bech32m address IS the tweaked pubkey, so every new taproot output adds to always-exposed supply at creation time. You cannot migrate out of P2TR without a destination type that does not exist yet.

The act of migrating creates its own attack surface. Every spend from a hashed-address type reveals the pubkey for the few minutes between broadcast and confirmation. Today no CRQC (cryptographically-relevant quantum computer) exists, so this window is theoretical. But if a CRQC did exist and was watching the mempool, an attacker could derive the private key in real time, broadcast a competing transaction with a higher fee, and steal the funds before the original transaction confirmed. The spend itself becomes the vector. This is the "in-flight" attack that any post-quantum migration framework has to contend with.

Mass migration is the worst possible response. A panic in which every holder consolidates at once spikes fees, expands the in-flight attack surface across millions of UTXOs simultaneously, and gives an early CRQC the most target-rich environment it will ever see. The right response is the boring one: migrate deliberately, over a multi-year window, on a schedule that the protocol itself can defend.

The framing that makes the rest of this chapter make sense: individual action helps individuals. It does not solve the systemic problem. The reuse pool can shrink through user behavior. The always-exposed floor can only shrink through protocol change. Both pools can only fully resolve when a post-quantum signature scheme ships and people migrate to PQ-native addresses. That is why the answer is governance, not panic. The fix has to be governance.

The actual threat is Shor, not Grover

"Quantum breaks Bitcoin" is a sentence. The threat depends on which part of Bitcoin you mean.

Shor's algorithm breaks elliptic-curve cryptography. Given the public key on the secp256k1 curve, Shor's derives the private key in polynomial time on a sufficiently large quantum computer. This is what threatens Bitcoin's ECDSA and Schnorr signatures. It is the existential exposure. It is why the exposed-supply number - about 35 percent of all BTC - matters.

Grover's algorithm gives quadratic speedup on unstructured search. Applied to SHA-256, it halves effective security: 256-bit becomes 128-bit. Annoying. Not catastrophic. 128-bit symmetric security is still the standard floor for cryptography elsewhere. Bitcoin's proof-of-work survives Grover's. Bitcoin's hashed addresses (P2PKH, P2WPKH that have never been spent) survive Grover's. The 21 million supply cap survives Grover's.

The signature is the weak link, not the hash. That is the entire story of why "post-quantum Bitcoin" is about replacing signature schemes, not about replacing SHA-256.

The timeline, honest version

No cryptographically-relevant quantum computer (CRQC) exists. A CRQC capable of running Shor's against secp256k1 needs millions of stable physical qubits arranged into thousands of logical qubits via error correction, with sustained coherence across millions of gate operations and gate fidelity high enough that the error-correction overhead does not blow up.

State of the art in 2026: physical qubit counts in the hundreds to low thousands, and demonstrated logical (error-corrected or error-detected) qubits in the dozens at best, all on small codes. Multiple orders of magnitude separate today's systems from CRQC, on several axes (qubit count, error rates, coherence time).

The progress curve is steady but it is not Moore's Law. Doubling logical qubits is much harder than doubling transistors because error correction overhead scales with system size. Most expert estimates put a CRQC capable of breaking 256-bit ECDSA somewhere in a 10-to-30-year window. BIP-361's authors cite a 2027 to 2030 window, sourced to McKinsey's Quantum Technology Monitor 2025. Pessimistic accounts push to the 2040s or later.

The discipline is to plan for the optimistic case while the optimistic case is still future tense. The optimistic case has been "as early as 2027" since 2017, and the threshold keeps moving forward as quantum hardware progress meets the engineering reality of error correction. The trend line is toward eventual capability. The honest answer is "before we are ready, and possibly suddenly."

The right planning horizon is therefore "before that, with margin." Bitcoin's governance moves in years. That matches.

What Bitcoin can do, and is doing

Three categories of response, in order of how disruptive they are to existing users.

1. Encourage best practices today. Zero protocol change required.

• Use modern hashed scripts (P2WPKH, P2PKH) and never reuse the address.
• Avoid P2TR for cold storage that has to survive the migration window, because P2TR outputs are exposed at creation.
• Spend old P2PK coins into modern scripts when it is safe to do so.

This is free. It is also voluntary, which is the limit.

2. Soft-fork to deprecate vulnerable script types. Disable spends from P2PK and other always-exposed scripts after a specified block height. Force migration before the threat lands. The contentious part: coins whose keys are lost (or whose owner is silent) become permanently locked. Whether that is a feature or a bug is the most charged question in the whole debate.

3. Soft-fork to add post-quantum signature schemes. New output types that use post-quantum signatures. Users move coins to PQ addresses over years. This is the likely path. Two BIPs already in draft frame the work: BIP-360 proposes Pay-to-Merkle-Root (P2MR), a Taproot variant that removes the key path spend so the bech32m address no longer reveals a pubkey - fixing long-exposure quantum risk on tapscript outputs and providing the tapscript-capable platform a future PQ signature opcode would need. BIP-361 defines the migration framework that sunsets ECDSA and Schnorr over a multi-year window. P2MR is not the only output design under discussion: in 2026 Pieter Wuille opened a Delving Bitcoin thread weighing it against alternatives such as P2TRv2, a new Taproot version that would carry a post-quantum signature opcode, and P2TRH, a Taproot variant with a hashed output key. The signature scheme itself is still pre-consensus. In 2026 the SHRINCS working group posted a first draft BIP for SHRINCS, a hash-based scheme compatible with SLH-DSA.

All three categories run through the same governance process. There is no fast governance. There is no central upgrade authority. The slowness is the feature, and it is also the constraint. See Bitcoin governance for the five-veto model that decides which soft forks actually activate.

The candidate replacements

NIST finalized two post-quantum signature standards in August 2024. Both are on the table.

The two schemes side by side:

	ML-DSA (Dilithium)	SLH-DSA (SPHINCS+)
Math	Lattice-based (MLWE, MSIS)	Hash-based (Merkle trees of one-time signatures)
Security assumption	Lattice problems are hard for quantum and classical	SHA-256 family hash function security only
Maturity	Newer math, less collective cryptanalysis	Conservative, well-understood primitives
Signature size	~2.5 - 4.5 KB	~7 - 50 KB
Verification speed	Fast	Slower
Trade	Smaller and faster, less mature	Larger and slower, more conservative
Spec	FIPS 204	FIPS 205

Bitcoin's post-quantum work has mostly focused on the hash-based family in the SLH-DSA column. Its signatures are big, but its security rests only on the hash function holding, and it is simpler to implement. The SHRINCS draft BIP is an example: by keeping a little state in the wallet, it gets a hash-based signature down to 548 bytes, with a 5,777-byte fallback that needs no state. Lattice schemes such as ML-DSA and Falcon have smaller signatures than SLH-DSA and keep coming up in the discussion, but the math behind them is newer. A hybrid scheme that combines a classical signature with a PQ signature during the transition window is also being discussed - belt and suspenders against the possibility that the PQ scheme itself is broken before the classical scheme falls.

The final choice is downstream of consensus. There is no committee. There is the same governance process that produced Taproot and SegWit, running on its native timescale.

What you can do today

The actions that actually help.

• Audit your own UTXOs. Any P2PK outputs in your stash? Move them to modern addresses. Any addresses you reused? Move those balances to fresh ones.
• Use modern hashed scripts. P2WPKH and P2PKH are pubkey-hashed. The pubkey is not revealed until you spend. If you spend once and never reuse, your exposure window is the few minutes between broadcast and confirmation.
• Never reuse addresses. Modern wallets default to this. Do not override the default.
• Be deliberate about Taproot for long-term cold storage. P2TR is exposed at creation. The advantages of Taproot are real (privacy, efficiency for complex scripts) but for "park it for ten years and forget it" storage, hashed scripts have a smaller attack surface across the migration window.
• Do not panic-move coins. The threat is not imminent. A poorly-considered consolidation tx is a bigger risk to your stack today than a CRQC is.
• Follow the BIP discussions. The community needs informed nodes more than it needs anxious ones.

The honest uncertainty

Things we do not know.

• When a CRQC arrives. Estimates from 5 years to 50 years all exist. The honest answer is "before we are ready, and possibly suddenly."
• Whether the first CRQC will be public. A state actor or a private lab could build one before anyone announces it.
• Whether ML-DSA or SLH-DSA will hold up under future cryptanalysis. Lattice math is younger than RSA or ECDSA; the cryptographic community has less collective experience attacking it.
• Whether Bitcoin's governance can ship a soft fork on the timeline that is needed. It has before. There is no guarantee it will again.

These uncertainties do not change the answer. They sharpen it. Bitcoin's preparation has to start before the threat is concrete, because once the threat is concrete it is too late.

That preparation is happening, in public, slowly, contentiously, exactly as the protocol was designed to evolve.

Closing

Quantum is real. Bitcoin is preparing. The slow consensus that frustrates the urgent is the same slow consensus that protects against the panicked.

Trust the mechanism. Watch it work.

Move your coins to modern addresses.

---

Sources and further reading

• ChainQuery quantum-exposure report: https://chainquery.com/reports/quantum-exposure (live, weekly snapshots; figures above from 2026-09-14, block 967,001)
• BIP-361 - Post-Quantum Migration: https://github.com/bitcoin/bips/blob/master/bip-0361.mediawiki
• NIST FIPS 204 (ML-DSA): https://csrc.nist.gov/pubs/fips/204/final
• NIST FIPS 205 (SLH-DSA): https://csrc.nist.gov/pubs/fips/205/final
• NIST Post-Quantum Cryptography Project: https://csrc.nist.gov/projects/post-quantum-cryptography
• Shor 1994 - Algorithms for quantum computation

Glossary cluster on this site:

• Post-Quantum Bitcoin
• Shor's Algorithm
• Grover's Algorithm
• CRQC (cryptographically-relevant quantum computer)
• ML-DSA (Dilithium)
• SLH-DSA (SPHINCS+)
• Bitcoin Governance