Trust isn't abolished — it's relocated onto one math problem
The parent page has two through-lines. One is the power law. The other is older and quieter: "don't trust, verify." That slogan is usually read as a triumph over trust — you no longer have to believe a bank or a custodian. But that is not what it does. It does not abolish trust; it relocates it. You stop trusting an institution and start trusting a math problem: that one particular calculation is easy to run forwards and effectively impossible to run backwards.
That calculation is the elliptic-curve discrete logarithm problem, or ECDLP, and everything in this article hangs off it.
The one-way street. Your wallet takes a secret number — your private key — and multiplies it by a fixed, publicly known point on a curve to produce your public key. Going forward is cheap: any phone can do it. Going backward — recovering the secret from the public result — is, on a classical computer, hopeless. That asymmetry is the whole trick. It is why you can shout your public key from the rooftops, etch it onto the blockchain forever, and lose nothing: nobody can divide their way back to your private key.
Nobody has proven ECDLP is hard — it is an unproven hardness conjecture, exactly the kind of foundational assumption this page interrogates rather than swallows. It is the binding security assumption of Bitcoin ownership, and the one quantum computing actually threatens.
A second cryptographic layer plays a different role, and conflating the two is the source of most confusion here. SHA-256 and RIPEMD-160 — the hash functions — wrap your public key inside an address. Think of this layer not as a second co-equal lock but as a curtain: it keeps your public key out of sight until the moment you spend, so an attacker has nothing to point an algorithm at. The address is a fingerprint of the key, not the key itself; an unspent, never-reused coin is safe because its public key simply hasn't been published yet — not because the hash is eternally un-reversible. So: the deepest threatened layer is ECDLP (binding, and it breaks); the hash layer is a temporary curtain (hiding, and it merely softens). That distinction is the spine of the whole piece, and it produces the one sentence that makes both "Bitcoin is doomed" and "Bitcoin is quantum-proof" wrong:
We earn that in §3. But first, the genuinely reassuring part, which deserves to come before the heavy math: which coins are actually exposed. The answer is not "Bitcoin." It is a specific, countable subset.
A countable subset — not "Bitcoin"
Settle the single most common misconception first, because nearly everyone arrives carrying it. There are two completely different things people mean by "quantum breaks Bitcoin," and only one is real.
Box A — Key recovery real
A quantum computer running Shor's algorithm could take a visible public key and recover the matching private key, then forge a signature and spend coins that aren't its own. This is theft of specific, identifiable coins. It does not rewrite history, reverse confirmed transactions, or break consensus rules. The forged signature is, mathematically, a valid signature.
Box B — Consensus attack non-event
Rewriting the blockchain or double-spending confirmed transactions requires raw mining power, governed by hashing — and hashing is only mildly softened by quantum attack and is re-absorbed by Bitcoin's difficulty adjustment. Quantum does not meaningfully enable this.
The punchline most coverage misses: quantum threatens the ownership of exposed coins, not the integrity of the ledger. Box A is the story; Box B is largely a non-event. Shor needs a public key to act on. Where the chain shows only the curtain — a hash — Shor has no target. That single fact partitions every coin into exposed and safe.
| Output type | What the public key is doing | Quantum status |
|---|---|---|
| P2PK (earliest coinbase coins) | Public key sits in the open, by the format's design | Exposed — key visible at rest |
| Reused address (any type, spent from at least once) | Public key was revealed the first time you spent | Exposed — key visible at rest |
| Taproot key-path (P2TR) | Tweaked public key sits directly in the output | Exposed — key visible at rest |
| Unspent, never-reused (P2PKH / P2WPKH) | Only a 160-bit fingerprint of the key is shown | Hidden — safe until spent |
The safe case is structural, not luck: a well-kept coin's public key first appears at the instant of spending, and not before. This is why the oldest piece of wallet hygiene — one address, one use — is also the best free quantum defense available today.
The exposed coins split by time pressure. The long-range attack targets coins whose public key is already permanently public (P2PK, reused addresses, Taproot key-path): the key sits on-chain forever, so a future machine takes all the time it needs — the larger standing risk, and why the governance dilemma later exists. The live-race attack targets an otherwise-safe hashed coin only at the instant of spending, when the curtain briefly lifts — a sprint against the next block that, crucially, the attacker is unlikely to win.
▸ For the curious: how each output type exposes its key, the live-race mechanics, and why "harvest now, decrypt later" doesn't apply
The output types. P2PK coins — the oldest on the chain, much of what Satoshi mined — put the public key in the open; the curtain was never drawn. A reused address drew it back the first time it was spent. Taproot key-path outputs place the key directly in the output with no hash wrapper — a partial regression to the P2PK era, precisely why the hardening proposals target it. A never-reused P2PKH/P2WPKH output shows only a 160-bit fingerprint (HASH160 = RIPEMD160(SHA256(pubkey))): you can check that a key matches it, but you cannot rebuild the key from it. (One caveat, since this page disowns bad arguments even when they point the right way: you'll read that "Taproot usage is declining because of quantum fears." Treat that as unproven — fee optimization, batching, and exchange behavior explain the fall at least as well, with no direct evidence of a quantum cause.)
The live race. When you spend a hashed coin, your transaction lands in the mempool — the public waiting room every node can see — and the curtain lifts. The attacker must now (1) feed your public key to Shor and recover your private key, then (2) broadcast a competing transaction paying the same coins to themselves with a higher fee — a replace-by-fee race — and (3) get it confirmed before the next block buries your legitimate spend. That window averages ~ten minutes, but blocks arrive on a Poisson schedule, so sometimes two, sometimes thirty. And ten minutes is the attacker's best case: your legitimate spend is already in the mempool, possibly already paying a competitive fee, so the attacker is overtaking a transaction with a head start. Miners pick the winner — they can prefer the first-seen spend from a key, or refuse a replacement that spends the same input under a different signature. So any single headline number for live-race success is an attacker-favorable upper bound, not an expected outcome.
Why HNDL doesn't apply. The standard quantum worry for the rest of the internet — harvest now, decrypt later (HNDL) — is serious for ordinary traffic: an adversary records your encrypted data today and stores it for a future machine to decrypt, presupposing a hidden secret inside. Bitcoin is different: its signatures authorize transactions; they do not hide a payload. A signature proves I am allowed to move these coins — no encrypted message waits to be cracked. As a16z's analysis puts it (correcting a Federal Reserve note that, in their reading, "exaggerates the urgency" by mis-applying HNDL), there is no confidentiality to retroactively attack. What does carry over is a cousin: for exposed coins, the target is already public and already permanent — you don't "harvest" a P2PK key, it has sat in the open since 2009. So the defense isn't curative; it's preventive: migrate vulnerable coins before a capable machine exists. Real and pressing — just not HNDL, and calling it HNDL borrows an urgency that doesn't belong to it.
Structure-finding versus haystack-searching
We've claimed an asymmetry — Shor breaks the keys, Grover only bends the hashes — and asserted it sinks both the doom and the complacency narratives. Here's why, intuition first.
Structure-finding vs. haystack-searching. An elliptic-curve key has a hidden mathematical regularity — a periodic structure baked into how the curve works. Shor's algorithm is a structure-finding machine: hand it something with a hidden period and it locates that period with brutal efficiency. Because ECDLP has that structure, Shor cuts straight through it — a true break, where security doesn't degrade, it collapses. A cryptographic hash is the opposite — engineered to be structureless, with no period to find. The best a quantum computer can do against it is Grover's algorithm, a cleverer haystack search that finds the needle in roughly the square root of the tries a classical search would need. A real speedup, but searching an astronomically large haystack twice as efficiently. A soften, not a break.
That contrast — surgical structure-finding versus merely-faster searching — is the entire asymmetry.
But — the strongest anti-alarmist point in the article — having the algorithm is not the same as being able to run it. Shor against secp256k1 is a single, unbroken chain of tens of millions of Toffoli gates (the for-the-curious estimate is ~70–90 million; §4's subject), and that chain has to execute coherently, start to finish, faster than the machine falls apart.
The orchestra that can't drop a note. A qubit is like a soap bubble holding a number: every operation risks popping it. So the challenge isn't owning a large quantum computer, any more than a symphony's challenge is owning enough musicians. It's getting every musician to play a seventy-million-note piece flawlessly, end to end — because a single decoherence event anywhere ruins the result. No machine ever built has sustained anything close to this.
The binding constraint isn't how many qubits you have; it's whether you can hold a multi-million-gate computation together long enough to finish. That gap — the subject of §4 — is enormous.
▸ For the curious: the receipts on Shor (exponential; breaks outright) and Grover (quadratic; only softens)
Shor. Bitcoin signatures (ECDSA, and Schnorr since Taproot) rest on recovering a private key $d$ from the public key $Q = dG$ on the secp256k1 group, whose order is $N \approx 2^{256}$. The best classical attack is Pollard's rho, costing about $\sqrt{N} \approx 2^{128}$ group operations — comfortably infeasible forever on classical hardware. Shor's algorithm solves the same problem in polynomial time — on the order of $(\log N)^3$ work — by translating discrete-log into quantum period-finding. (Two different exponents on the same group order: $\sqrt{N} = 2^{128}$ is the classical cost; $(\log N)^3$ is Shor's. Not to be conflated.) That gap is effectively exponential. Once a public key is visible and a cryptographically-relevant quantum computer exists, the matching private key is derivable and the signature scheme is broken outright (Proos & Zalka 2003, arXiv:quant-ph/0301141; Roetteler, Naehrig, Svore & Lauter, ASIACRYPT 2017, arXiv:1706.06752).
Grover. Against SHA-256, Grover cuts brute-force cost from $2^{256}$ to about $2^{128}$ operations. That sounds alarming — until you count:
Cracking a single SHA-256 hash with Grover would take ~10²² years — roughly 800 billion times the age of the universe. SHA-256 is softened, nowhere near broken. (In the page's self-correcting habit: an earlier draft put this at ~10¹⁹ seconds, wrong by ten orders of magnitude; the correct figure is ~10²⁹ s ≈ 10²² years — and the error happened to understate Bitcoin's margin.)
Three facts make the hash layer even safer:
- Grover barely parallelizes. Splitting the search across $k$ machines buys only $\sqrt{k}$ (Zalka 1997), forcing one long serial run. NIST encodes this ceiling as
MAXDEPTH; realistic fault-tolerant Grover attacks need depth ~$2^{144}$, making SHA-256 effectively harder than the $2^{128}$ headline. - Difficulty adjustment absorbs the speedup. A Grover miner's edge is a square-root gain, and Bitcoin's roughly-two-week retargeting competes it back toward parity. Honest hedge: retargeting restores difficulty, not necessarily relative hashrate share — a quantum miner with both a genuine √-speedup and ASIC-competitive per-operation throughput could grab disproportionate share before the retarget catches up. But today's quantum hardware is nowhere near ASIC per-hash speed, which is what makes mining safe in practice now.
- RIPEMD-160's outer layer sits at ~$2^{80}$ under Grover — small by cryptographic standards but still infeasible, and irrelevant unless SHA-256 falls first.
So mining survives, structurally: proof-of-work rests on hashing, hashing only bends, and difficulty re-absorbs the bend. The thing quantum genuinely threatens is the ownership of coins whose public key is already showing.
Physical qubits, logical qubits, and the factory tax
First, a vocabulary problem that almost every scary qubit headline trades on. When a company announces "1,000 qubits," it counts physical qubits — real, noisy hardware that holds a quantum bit for a fraction of a second before errors creep in. The number that matters for breaking Bitcoin is logical qubits — the perfect, error-free qubits the algorithm assumes, each one built by ganging hundreds to thousands of physical qubits together to check each other's work and vote out errors. A machine with "a thousand qubits today" is closer to having the raw material for one or two reliable ones. And the operations Shor leans on most heavily are the expensive ones to manufacture inside the error-correcting scaffold — so the real cost is a "factory tax" that balloons a design needing ~1,200 logical qubits into hundreds of thousands of physical ones, which is why progress on the number that matters has been slower than the press releases suggest.
With that, the resource estimates stop being a single scary number and become a story about how the target has moved. Every figure that follows is a projection about hardware that does not yet exist. Treat each one the way this page treats the power-law exponent: an estimate with a band, not a fact.
▸ For the curious: how the resource estimates have moved (Roetteler · Proos–Zalka · Gidney · Google)
The error-correcting scaffold has a name worth knowing: the surface code. The operations Shor leans on most heavily (Toffoli and T-gates) cannot be done cheaply inside it; to manufacture them, a real machine runs magic-state factories — large, slow subsystems that produce these expensive gates one batch at a time. That factory tax, not the raw qubit headline, is the binding cost.
The canonical academic baseline is Roetteler, Naehrig, Svore and Lauter (ASIACRYPT 2017, arXiv:1706.06752): breaking secp256k1's 256-bit curve takes roughly 2,330 logical qubits and ~1.26 × 10¹¹ Toffoli gates. The deeper anchor is Proos and Zalka (2003, arXiv:quant-ph/0301141), who first established the scaling — qubits growing linearly with key bit-length, gate count with its cube — and pegged a concrete low end of ~1,000 logical qubits for a smaller 160-bit curve. One reassuring fact falls out: elliptic-curve crypto is cheaper to break than RSA, so Bitcoin's curve is a softer quantum target than the RSA securing most of the web — a warning about everything else, not a comfort about Bitcoin.
"The estimates are huge, so we have decades" is fragile because the estimates keep shrinking — from math, not hardware. In May 2025, Gidney (arXiv:2505.15917) cut the headline cost of breaking RSA-2048 from a 2019 figure of ~20 million noisy qubits to under 1 million — a ~20× reduction — purely from algorithmic cleverness, hardware assumptions untouched. Any "we are safe because the numbers are astronomical" position is one good paper away from revision.
That brings us to the most consequential and most recent estimate. In March 2026, Google Quantum AI with collaborators at Stanford and the Ethereum Foundation (Babbush, Gidney, Boneh, Drake and others) posted "Securing Elliptic Curve Cryptocurrencies against Quantum Vulnerabilities" (arXiv:2603.28846; v2, 15 Apr 2026). It is the lowest published estimate to date: fewer than 1,200 logical qubits and ~90 million Toffoli gates (or, in an alternate trade-off, fewer than 1,450 logical qubits and ~70 million Toffoli gates), fewer than half a million physical qubits, executable "in minutes" at a 0.1% error rate. The three sourcing hedges travel with it: preprint, peer review pending; any attacker-favorable figure is the paper's own idealized upper bound; and Google sells quantum computers. None of this makes the paper wrong — it makes it a projection from an interested party.
Notice what the two big reductions are and are not. There are two ~20× drops on record, but on different problems — Gidney's is RSA (20M → under 1M qubits); the Google result is the separate ECC estimate. They are not one continuous halving line, and drawing them as a single trajectory would manufacture false inevitability. What they jointly show is narrower but real: resource estimates can fall sharply on theory alone.
The shrinking-estimates story matters because it makes "decades away" a bet, not a fact — two separate ~20× reductions have come from theory alone, without anyone building a new qubit.
Against all of these projections sits built hardware. The frontier is around 1,000–1,200 physical qubits (IBM's Condor at 1,121; Atom Computing's neutral-atom array near 1,180), and none does the fault-tolerant computation an attack requires. Google's Willow result (Nature, Dec 2024) was a genuine milestone — error correction working below threshold, so adding physical qubits made the logical qubit better — but Willow held a single logical qubit as memory, not a computer running tens of millions of gates in sequence. As §3 laid out with the orchestra that can't drop a note, Shor against secp256k1 demands an unbroken coherent computation of tens of millions of Toffoli gates (the 70–90M figure), end to end, and no device has come within many orders of magnitude. This sustained-coherence requirement, not the qubit count, is the strongest reason the calibrated read is not alarmist.
A caveat about the word "qubit." As a16z has noted, "logical qubit" has been "stretched beyond recognition" in marketing — sometimes applied to error-detecting codes that can't fix anything. When you read a qubit number, ask: physical or logical, built or projected? Most headlines blur all four.
The tension peak: Mosca's inequality
Here the question stops being about physics and becomes a decision under uncertainty — the article's climax. The rule, named for cryptographer Michele Mosca, is common sense about deadlines: X is how long your secret must stay secret, Y is how long migration to quantum-proof cryptography takes, and if X + Y > Z — the time until the attacker's machine arrives — you are already too late. You act when X + Y threatens to exceed Z, not when Z is proven.
Feed Bitcoin in, and one term behaves unlike anything in normal cryptography. X is effectively infinite and solid: a store of value must stay secure forever, and for coins whose public key is already exposed, X is maxed out and irreversible — no future moment un-publishes a published key. Z is genuinely uncertain, a wide band (below). And Y is the load-bearing uncertain term: soft-forking post-quantum cryptography into Bitcoin and persuading users to move millions of coins plausibly takes 5 to 10 or more years given Bitcoin's ossification — a projection, not a measurement, and the soft point the whole conclusion leans on.
So if you accept a long Y, then because X is already infinite for exposed coins, X + Y exceeds even a generous Z today, and the rational move is to begin migration work before a code-breaking machine is demonstrated — not because Q-Day is imminent, but because Bitcoin's Y is unusually long. Not a prophecy that the machine is near; an argument that, for this system, you cannot afford to find out the hard way.
▸ For the curious: how long are Y and Z, really? (migration precedents · expert bands · the standards clock)
How long is Y? The only evidence is the historical record of retiring a broken primitive, and it is not encouraging. MD5 was shown weak from 2004, with practical collisions by 2008 — and took well over a decade to purge, with stragglers for years after. SHA-1: theoretical death announced 2011, browsers hard-failing its certificates by 2017 — yet Git still uses SHA-1 at its core in 2026, fifteen years on, mid-migration. DNSSEC has been rolling out partially for roughly twenty years and is still incomplete.
The alarming part: every one of those migrations had a central forcing authority — a standards body, a browser cartel, a vendor — that could set a deadline and make it stick. Bitcoin has none; its changes happen by rough consensus among developers, miners, and users who routinely decline to upgrade. If a primitive with a CA/Browser Forum behind it takes a decade-plus, Bitcoin's Y is plausibly longer. The disanalogy sharpens the Mosca conclusion, it doesn't soften it.
How long is Z? The most credible signal is structured expert elicitation. The Global Risk Institute / Mosca Quantum Threat Timeline reports a band, not a point. The 2025 edition (Mosca and Piani, evolutionQ; 26 experts) puts the chance of a cryptographically-relevant machine — one breaking RSA-2048 within a day — at 28%–49% within ten years, the highest ten-year reading in the survey's seven-year history, up sharply from the 2024 band (which was 19%–34%; the optimistic end jumped to 49%, the pessimistic floor from 14% to 28%). Further out, ~69% of experts put it above even odds within fifteen years, 92% within twenty. A commonly-cited 5-year band of ~5–14% comes from the 2024 edition, not 2025 — treat it as a year-stamped artifact.
The other clock is a deadline, valuable precisely because it comes from a party with no stake in Bitcoin. The NSA's CNSA 2.0 suite and supporting NIST guidance direct federal systems to deprecate the classical public-key crypto Bitcoin relies on (ECC P-256, RSA-2048): software- and firmware-signing quantum-safe by 2030, broad removal targeted for 2035. The standards are finished — FIPS 203, 204 and 205 (ML-KEM, ML-DSA, SLH-DSA) were finalized in August 2024. A fourth, FIPS 206 (the Falcon-based FN-DSA), is forthcoming, not published — submitted for approval in August 2025, but the public draft had still not appeared by mid-2026, with a final standard expected late 2026 or early 2027. These bind federal systems, not Bitcoin — but they set an external, incentive-neutral pace for the whole cryptographic-library ecosystem Bitcoin floats in.
The cryptography is the easy part
The good news is real: the cryptography is the easy part. Quantum-proof signature schemes already exist, standardized and ready; the migration paths are drafted. What makes Bitcoin's problem hard is three things no algorithm can fix: a bloat tax on every transaction, the coordination to deploy anything, and one dilemma about other people's coins that cryptography cannot resolve.
The bloat tax, and where quantum-safe coins would live
The post-quantum schemes are on the shelf: ML-DSA (Dilithium) and the lattice-based FN-DSA (Falcon), compact but resting on newer, less battle-tested assumptions; and SLH-DSA (SPHINCS+), hash-based and therefore the conservative choice — its security leans only on the SHA-256-class assumptions Bitcoin already trusts. The catch is size. A Bitcoin signature-plus-public-key today is ~64–96 bytes; post-quantum signatures are kilobytes (SPHINCS+ into the tens). On a chain whose scarcest resource is block space, that is a direct hit to throughput and permanent upward pressure on fees, and the trade-off runs one way: the most conservative assumptions cost the most bytes, and the smallest signatures rest on the least-tested math.
Two drafted proposals stage the response, and both are Draft status, pre-activation. BIP-360 defines where quantum-safe coins would live: a new output type now called P2MR (Pay-to-Merkle-Root) — essentially Taproot with the quantum-vulnerable key-spend path removed, script-spend-only, so no bare public key sits exposed. BIP-361 (Jameson Lopp and six co-authors, April 2026) stages the contested step the press calls a "freeze": not a flat lockout but a phased sunset of the legacy signatures, with two formal phases and an experimental recovery mechanism. The honest read is that a non-controversial new address type "achieves nothing" for the standing long-range threat by itself — offering a safer mailbox doesn't protect the mail already lying in the open. That protection requires the freeze BIP-361 stages and the values choice below.
▸ For the curious: the PQC signature sizes, and the exact status of BIP-360 and BIP-361
The signature-size trade-off.
| Scheme | Basis | Relative size | Security posture |
|---|---|---|---|
| Current (ECDSA/Schnorr) | Elliptic curve | ~64–96 B (sig + pubkey) | Quantum-vulnerable |
| FN-DSA / Falcon | Lattice | ~1–2 KB | Compact; newer assumptions |
| ML-DSA / Dilithium | Lattice | ~2–4 KB | Standardized (FIPS 204); newer assumptions |
| SLH-DSA / SPHINCS+ | Hash-based | tens of KB | Most conservative (FIPS 205); SHA-256-class only |
The most conservative assumptions cost the most bytes; the smallest signatures rest on the least-tested math. No free lunch — only a choice about which price to pay.
BIP-360 (championed by the developer known as Hunter Beast). The name has churned: first Pay-to-Quantum-Resistant-Hash, briefly P2TSH, now P2MR (Pay-to-Merkle-Root) as of v0.11.0, February 2026. It was merged into the bitcoin/bips repository on 11 February 2026 — but "merged into the repo" is not "activated on the network." Its status field still reads Draft; merging is bookkeeping, not a soft fork. The proposal also deliberately narrowed: the specific post-quantum signature algorithm was moved out into a separate future BIP, so the output type can be debated on its own merits.
BIP-361's phases. Phase A (~3 years): the network stops accepting new sends to quantum-vulnerable address types, so the exposed pile stops growing. Phase B (~5 years, after A): the network stops honoring spends signed with legacy ECDSA/Schnorr — sunsetting the vulnerable signatures. Plus a recovery path: a sketched quantum-safe rescue mechanism using zero-knowledge proofs to let holders who still possess their original wallet seed reclaim funds after the sunset — but the canonical BIP text describes this as experimental and under development, not a formalized, numbered phase. Secondary press frames the whole thing as a tidy "three-phase plan with a Phase C rescue"; the spec does not number it.
One sourcing distinction. The dramatic figures attached to this debate — "170,000 vulnerable P2PK outputs," "1.1 million Satoshi-era coins" — come from media coverage, not the BIP (tier (c)). The spec's own load-bearing claim is more measured: more than 34% of all bitcoin sat at addresses with a revealed public key as of 1 March 2026. Cite the scary round numbers as reporting; cite the structural fact as spec.
The forced choice: a quadrilemma, not a trilemma
Here cryptography runs out of room. Some exposed coins cannot be migrated by anyone, because no one holds the keys: Satoshi's own stash — Chaincode Labs puts the directly-exposed P2PK portion at 600,000 to 1.1 million BTC — plus an unknown mass of coins whose owners died or vanished. There is no cryptographic answer to what the network does about coins it knows a future machine can steal but their owners can no longer rescue. Only a values choice, with four options, not the tidy three usually framed:
1 · STEAL — do nothing
Leave the coins exposed and let a future machine drain them — in practice, wealth redistribution to whoever wins the hardware race (a nation-state, a large company), then a fire-sale that shatters confidence.
Breaks "your keys, your coins" — an attacker walks off with the coins while the protocol's letter survives.
2 · FREEZE — sunset the vulnerable spends
Soft-fork a deadline after which legacy ECDSA spends are invalid, locking unmigrated coins in place. Prevents theft by having the protocol confiscate the coins instead of an attacker.
Breaks "your keys, your coins" the other way — it trades a thief for a committee.
3 · BURN — provably destroy them
Render unmigrated vulnerable coins permanently unspendable. Lopp's stated preference, on the logic that quantum-recovered coins "only make everyone else's coins worth less… a theft from everyone." Even Lopp says he does not like it — only that inaction is worse.
Breaks "your keys, your coins" — the protocol destroys property to protect the whole.
4 · TIME-LOCKED RECLAIM — a long migration window
Rather than a hard cutoff, give original owners an extended, protocol-enforced window to prove ownership and move funds to a quantum-safe output before any freeze or burn. Rescues owners who are merely slow or asleep.
Reduces but does not eliminate the problem — a key that's truly gone still can't be reclaimed by a holder who no longer exists.
- STEAL — do nothing. Leave the coins exposed and let a future machine drain them. In practice this is wealth redistribution to whoever wins the hardware race — a nation-state, a large company — followed by a fire-sale that shatters confidence. "Your keys, your coins" survives the letter of the protocol while an attacker walks off with the coins.
- FREEZE — sunset the vulnerable spends. Soft-fork a deadline after which legacy ECDSA spends are invalid, locking unmigrated coins in place. This prevents theft by having the protocol confiscate the coins instead of an attacker. It trades a thief for a committee.
- BURN — provably destroy them. Render unmigrated vulnerable coins permanently unspendable. This is Jameson Lopp's stated preference, on the logic that quantum-recovered coins "only make everyone else's coins worth less… a theft from everyone." Even Lopp says he does not like it — only that inaction is worse.
- TIME-LOCKED RECLAIM — a long migration window. Rather than a hard cutoff, give original owners an extended, protocol-enforced window to prove ownership and move funds to a quantum-safe output before any freeze or burn takes effect. It reduces the confiscation problem — rescuing owners who are merely slow or asleep — but does not eliminate it, because genuinely lost keys and Satoshi-era coins still cannot be reclaimed by a holder who no longer exists.
▸ For the curious: how other chains are answering the same question
Bitcoin is not facing this alone, and the comparison sharpens the diagnosis. QRL (the Quantum Resistant Ledger) was built from genesis on hash-based XMSS signatures — quantum-safe by design, at the cost of building a whole new chain. Ethereum has a structural advantage: account abstraction lets accounts change their own signature logic, and Vitalik Buterin has publicly sketched a recovery-fork approach leaning on that flexibility. Algorand already uses Falcon-based state proofs in parts of its design.
The pattern is consistent and unflattering to Bitcoin in exactly one respect: chains with upgrade-friendly account models can swap signature schemes far more easily. Bitcoin's signature ossification — the very rigidity that makes it credibly neutral — is what makes its migration slower and its Y term longer. That is not a knock on the thesis; it is the thesis. Bitcoin's quantum problem was never that the cryptography is unsolvable. It is that Bitcoin, more than almost any other system, is built to be hard to change — and the one time that property becomes a liability is precisely when it is asked to change to save itself.
The immutability trolley problem
Everything so far has been physics and engineering. This is where cryptography runs out and the question becomes one no amount of qubits can answer.
A quantum thief who derives your private key and spends your coins breaks no rule of the Bitcoin protocol. Their signature is valid; the math checks out; every node accepts it because, by the only definition the network has ever enforced, it is a legitimate spend. "Code is law" says the coins are theirs now. And yet every instinct says a theft just happened.
To stop it, the network would have to do the one thing it has spent fifteen years promising never to do: reach into the ledger and invalidate an otherwise-valid signature — freeze, burn, or sunset the old scheme. That protects the victim. It also breaks Bitcoin's deepest invariant: that no one, not even the developers, not even a supermajority, can reach in and alter who controls a coin.
So the choice is a trolley problem. On one track, "code is law" stands and a quantum attacker drains millions through valid signatures. On the other, you pull the lever — you confiscate, by protocol, to honor a shared human sense of ownership the code does not encode. Bitcoin cannot keep both "code is law" and "theft is illegitimate" at the same time. A sufficiently powerful machine forces the network to confess which of its two foundational promises was the real one. (The four governance responses are §5's subject; this is about why the choice is forced at all.)
▸ For the curious: the calibrated middle — two spectra, stated fairly
This is a polarized topic, with vendor incentives pulling one way and ideological commitments the other. The honest move is to lay out both spectra, then stand in the calibrated middle.
The Bitcoiner spectrum runs from "do nothing" to "freeze now," each position with a real steelman:
- Complacency / ossification (segments of maximalists; the implicit position of slow BIP review): SHA-256 isn't broken, Grover is only quadratic, mining is safe, a code-breaking machine is decades off — and a soft fork is itself an attack surface. Right that mining and hashing are safe and Z is uncertain, and that contentious forks are genuinely dangerous. But it conflates the durable hashing layer with the vulnerable signature layer, waves away the already-exposed millions, and treats slowness as a feature precisely where slowness is the binding risk.
- Property-rights absolutism (Charles Hoskinson, many vocal holders): freezing or burning anyone's coins — even lost ones, even Satoshi's — violates "your keys, your coins." Coherent on principle (the DAO/Ethereum-Classic split is the cautionary precedent), but it collides with the fact that doing nothing is not neutral — inaction is a decision to let an attacker seize those exact coins.
- Activist migration (Hunter Beast / BIP-360; Lopp et al. / BIP-361; Casa): commit now to a phased soft fork. Rational, arguably the safest path — but politically explosive and assumes coordination Bitcoin has historically struggled to muster (the reaction on X to BIP-361 was reportedly overwhelmingly negative).
- Conservative soft-fork skeptics (Adam Back; some Core developers): wary of fast-tracked, contentious activation, preferring minimal, opt-in, non-confiscatory mechanisms. A reasonable procedural brake — though every month of caution lengthens Y.
The quantum spectrum runs from "tomorrow" to "never":
- Vendor / supremacy hype (some IBM / Google / IonQ / PsiQuantum marketing, amplified by media FUD): quantum breaks Bitcoin imminently. Misrepresents resource estimates as capabilities, ignores sustained fault-tolerance entirely, and conflates random-circuit-sampling "advantage" and raw physical-qubit counts with an actual break.
- The calibrated middle (Mosca / GRI; a16z's Justin Thaler; the standards bodies behind CNSA 2.0 and NIST IR 8547): the probability within ten years is real and rising — but not near-certain. Act on Mosca's inequality. Separate facts from projections from debunked claims. This is the position this piece centers; the 2030/2035 deadlines supply an external, incentive-neutral clock.
- The principled hard skeptic (Gil Kalai, with Alicki, Dyakonov, Levin): scalable fault-tolerant quantum computing may be physically impossible. A serious minority view that bounds the doom narrative — but its strong form is in real tension with Willow's below-threshold error suppression, and is rejected by the Preskill / Harrow / Aaronson mainstream. Kalai himself floats ~2030 as a fair checkpoint. Present it honestly — and never as a license for inaction, because Mosca binds under uncertainty, not certainty.
▸ For the curious: the false-alarm ledger — why "quantum broke crypto" headlines never survive review
Before panicking at the next "quantum just broke encryption" headline, install the right prior: that headline recurs every couple of years, and none of the instances has survived review.
| Year | The claim | What actually happened |
|---|---|---|
| 2019 | Google's Sycamore achieves "quantum supremacy." | Real and important — but random-circuit sampling, a benchmark with no cryptographic content. It could not factor a number or break a key. Not cryptanalysis. |
| recurring | "Shor's algorithm factored 15 (and 21, and 35)." | True and a milestone each time — but these do not scale. They rely on hand-tuned circuits and prior knowledge of the answer; resource cost explodes long before practical numbers. A breakable 15 says nothing about a 256-bit key. |
| 2022–23 | A Chinese group claims a lattice / "RSA broken" method on near-term hardware. | The paper grafted a quantum optimizer onto Schnorr's (unvalidated) classical factoring claim; Bruce Schneier and Scott Aaronson noted the classical step doesn't work at scale. Debunked. |
| 2024–25 | D-Wave "breaks RSA." | Factored trivially small or specially structured numbers using a quantum annealer — not a gate-model machine running Shor. One factorization was reproduced on a Commodore VIC-20, a 1981 home computer. |
The pattern is the point: every time, the fine print reveals a benchmark with no cryptographic stakes, a toy-sized demonstration that doesn't scale, or an outright error. The genuinely credible primary source pointing the other way is not any of these — it is the Google Quantum AI ECC preprint (arXiv:2603.28846), and that paper does not claim a break has happened. It is a careful resource estimate of what a future, un-built machine would require. That is the difference between hype and the calibrated middle.
Resilient in math, gated by coordination
Bitcoin is not the fragile one
One fact this debate routinely omits inverts the whole framing. A quantum computer powerful enough to run Shor against secp256k1 would, by the same capability, break essentially all classical public-key cryptography in production at once — the RSA and ECC securing TLS and the web's padlock, code-signing, online banking, government systems, secure messaging. So "quantum breaks Bitcoin," said in isolation, badly overstates anything Bitcoin-specific: the same machine breaks the global financial and PKI systems Bitcoin lives inside, and that world has far larger problems than some exposed Bitcoin UTXOs.
And here's what should lower the temperature: Bitcoin is arguably more migratable than the global PKI, not less. It has a known, enumerable set of vulnerable outputs — you can literally count the exposed public keys on-chain — active soft-fork proposals already drafted, standardized replacements ready to drop in, and a community visibly fighting about migration today. The world's TLS and PKI are a vastly larger, more fragmented surface with no single forcing authority and no clean inventory of what is exposed.
(The honest counter to the counter: relative fragility is not relative attractiveness. Bitcoin is permissionless to attack, irreversible once a theft settles, and instantly liquid to monetize — properties the rest of the PKI mostly lacks. So Bitcoin may be more defensible and yet more tempting at once. Same fact, flipped.)
The threat is real but neither imminent nor uniform
Bitcoin's quantum resilience is not gated by a missing algorithm — the algorithm exists. Post-quantum signatures are standardized; a soft-fork path is drafted; the cryptography is genuinely the easy part. What gates Bitcoin is social and governance latency — its long, uncertain migration time — and the irreducible exposed-coin dilemma, the freeze/steal/burn/reclaim values choice over Satoshi-era and permanently lost coins that no cryptography can resolve.
✓ Survives quantum
- Mining & proof-of-work. Hashing only bends (Grover, quadratic) and difficulty adjustment re-absorbs the bend.
- Never-reused, properly-hashed coins (P2PKH / P2WPKH) — the public key is hidden until spend.
- The ledger's integrity. No rewrite, no double-spend of confirmed history (Box B is a non-event).
- The cryptographic fix itself — FIPS 203/204/205 are standardized; replacements are ready to drop in.
- The live-spend race, marginally — even granting a working machine, the primed attacker's upper bound is under 41%, and that is the paper's own idealized worst case.
✗ Does not survive
- The standing, already-exposed surface — 4–10M BTC (~20–50% of supply) whose public key sits on-chain forever, facing no clock.
- P2PK, reused addresses, Taproot key-path outputs — the key is visible at rest.
- The truly unrecoverable coins — Satoshi-era P2PK at 600K–1.1M BTC, plus an unknown mass of lost keys, which no migration can rescue.
- "Code is law" and "theft is illegitimate" together — a powerful machine forces the network to give up one.
- Any comfort from a precise timeline. "Decades," "this decade," "never" are all projections with wide bands.
The threat is real but neither imminent nor uniform. Mining and never-reused, properly-hashed coins are safe. The live-spend race is marginal even granting a working machine — the Google Quantum AI preprint puts a primed attacker's chance of stealing a coin inside Bitcoin's ~ten-minute confirmation window at slightly under 41% (arXiv:2603.28846, Fig. 6). But that is the paper's own idealized, attacker-favorable, Bitcoin-specific upper bound: it assumes instant public-key syndication, a winning fee-replacement, and zero mempool congestion, and ignores miner-mediated defensive policy. A worst-case snapshot, not an expected outcome, and a projection about hardware no one has built (the three standing hedges apply: peer-review-pending preprint; the authors' deliberate idealization; Google's vendor interest). Faster-block chains fare far worse on the same analysis — Litecoin under 3%, Zcash under 0.08% — which underscores that Bitcoin's slower cadence is here protective.
What genuinely does not survive is the large, standing surface of already-exposed public keys — somewhere in the range of 4–10 million BTC, roughly 20–50% of supply (Deloitte estimates more than 4M, ~25%; River about 6.8M; Chaincode Labs 4–10M with a working midpoint near 6.26M). That surface faces no clock: an exposed key sits on-chain forever. Within it sit the truly unrecoverable coins — the Satoshi-era P2PK holdings Chaincode puts at 600,000 to 1.1 million BTC, plus an unknown mass of lost keys — which no migration can rescue, because no one holds the keys to move them.
What a holder can do today
None of this requires waiting for a soft fork, taking a side in the freeze debate, or trusting any timeline. There are concrete, free, uncontroversial steps available now:
- Never reuse an address. The first time you spend from an address, you publish its public key forever. One address, one use — modern wallets do this by default; let them.
- Keep funds in unspent, never-reused hashed outputs (P2WPKH / P2PKH), not in P2PK, reused addresses, or Taproot key-path outputs — those expose the public key directly.
- Treat spending as the moment of exposure. Plan large spends with that in mind, and guard any extended public key (xpub), since leaking one exposes an entire branch of derived keys at once.
- Ignore "Q-Day is here" headlines. No code-breaking quantum computer exists. When one is genuinely near, the signal will be unambiguous and the standardized fixes are already on the shelf.
These cost nothing, change no protocol, and are correct regardless of which timeline turns out right.