# 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).