Bitcoin and Quantum Computing

Neha Narula (former MIT Digital Currency Initiative director) lays out the case that Bitcoin needs to start migrating to post-quantum cryptography now, even though the timeline is uncertain. Her contribution isn't the threat analysis itself — that's covered in crqc-timeline — but the application to Bitcoin specifically, where decentralized governance makes migration uniquely difficult.

The probability framework

Narula breaks the risk into two independent factors:

• P(CRQC exists by date X) — Google's own researchers estimate 10% by 2030
• P(Bitcoin fails to upgrade by date X) — given that Taproot activation took nearly 4 years, she estimates ~50% chance of successful PQ soft fork + wallet migration by 2029

Multiplied: roughly 5% probability that Bitcoin breaks due to quantum threats by 2030. That's not high in absolute terms, but for a system holding hundreds of billions in value, 5% existential risk in 4 years is not something you ignore.

And the inputs are arguably conservative. crqc-timeline documents how two April 2026 papers collapsed timelines, with Google's Adkins and Schmieg setting 2029 as the migration deadline. The 10% figure may already be outdated.

Why Bitcoin is uniquely hard to migrate

Most systems that depend on classical cryptography — TLS, banking, government infrastructure — will migrate via centralized decisions. A standards body publishes new requirements, vendors update, done. Bitcoin doesn't have this luxury.

Consensus changes are slow. Taproot, a relatively uncontroversial upgrade, took nearly 4 years from proposal to activation. A post-quantum signature scheme changes fundamental transaction structure — this is harder and more contentious.

Signature size trade-offs. ml-dsa signatures are a few KB vs ECDSA's 64 bytes. Larger signatures mean fewer transactions per block, higher node storage costs, and potentially higher fees. The Bitcoin community will debate this extensively. ml-kem key exchange isn't directly relevant since Bitcoin uses signatures, not key exchange, but the ecosystem-wide PQ migration creates pressure.

Non-upgraded UTXOs. What happens to coins sitting in classical (secp256k1) addresses that never move to PQ addresses? If a CRQC arrives, those coins become stealable. Do you freeze them? That's confiscation. Do you ignore the problem? That's theft. There's no good answer, and the philosophical debate will be bitter.

Wallet ecosystem migration. Even after consensus activates PQ signatures, every exchange, custodian, hardware wallet, and individual user needs to generate new PQ keys and move their coins. This is a separate, slower process that depends on software updates across hundreds of independent implementations.

The counterarguments

Narula systematically addresses common pushback:

"It's FUD" — There's real misinformation about quantum threats, but the underlying cryptographic vulnerability is technically sound. ECDSA on secp256k1 falls to Shor's algorithm.

"CRQCs may never exist" — Possible, but historically, betting against researchers solving hard problems doesn't end well. The crqc-timeline 1939–1940 analogy applies.

"Other systems are vulnerable too" — True, but other systems have centralized upgrade paths. Bitcoin's decentralization is usually a feature; here it's a vulnerability.

"Google is trying to sabotage Bitcoin" — Two things can be true simultaneously: a company may have competitive motivations AND the technical threat can be real.

The absence of a plan

The most concrete point: as of April 2026, there is no finalized Bitcoin PQ specification, no reference implementation, no ecosystem coordination plan. The work hasn't started in earnest. Given that Taproot took 4 years and PQ migration is harder, starting now may already be late.

Where this fits

This is the most concrete application of post-quantum-cryptography in the wiki. The crqc-timeline covers the threat timeline and migration advice for general systems. This post shows what happens when you apply that advice to a system that can't be upgraded by fiat — you get a coordination problem layered on top of a cryptographic one, with store-now-decrypt-later making the clock tick even before CRQCs arrive (captured Bitcoin transactions with exposed public keys can be retroactively broken).