Bitcoin Post-Quantum Cryptography — The Race Against Time

Bitcoin's security rests on elliptic curve cryptography (ECC) — specifically the secp256k1 curve used for both ECDSA and Schnorr signatures. Shor's algorithm on a sufficiently powerful quantum computer (called a CRQC — Cryptographically Relevant Quantum Computer) would solve the discrete log problem

Bitcoin Post-Quantum Cryptography — The Race Against Time

#bitcoin #post-quantum #cryptography #privacy #security #scaling #research

Quantum computers will eventually break Bitcoin’s signature scheme. That’s not controversial. What’s controversial is when it matters, how to fix it, and whether Bitcoiners can agree before it’s too late. As of March 2026, the community is mid-debate on at least six competing proposals, the signature size problem threatens to reduce throughput by 10x, and Project Eleven’s Q-Day Prize bounty (1 BTC to break a toy ECC key with a quantum computer) expires April 5 with no winner. The threat isn’t imminent — but the migration might take 7+ years.

The Vulnerability

Bitcoin’s security rests on elliptic curve cryptography (ECC) — specifically the secp256k1 curve used for both ECDSA and Schnorr signatures. Shor’s algorithm on a sufficiently powerful quantum computer (called a CRQC — Cryptographically Relevant Quantum Computer) would solve the discrete log problem and derive private keys from public keys.

What’s Actually Exposed?

Not all Bitcoin is equally vulnerable:

Output Type BTC at Risk Why
P2PK (pay-to-public-key) ~1.72M BTC Public key permanently visible on-chain. Includes Satoshi’s coins.
P2TR (Taproot key-path) ~146K BTC Tweaked public key exposed in scriptPubKey.
Reused P2PKH/P2WPKH Variable Public key revealed by first spend, future deposits to same address vulnerable.
Lightning channels All channel balances Node pubkeys are public.

The Chaincode Labs report estimates 20–50% of circulating Bitcoin (4–10M BTC) could be at risk depending on assumptions. Project Eleven’s more aggressive estimate: 6.26M BTC ($650B at current prices).

There are two attack classes:

  • Long-range attacks: Target outputs with permanently visible public keys (P2PK, P2TR, reused addresses). The attacker has unlimited time.
  • Short-range (mempool) attacks: Target transactions during the unconfirmed period when public keys are revealed at spend time. Much harder — requires near-real-time quantum computation.

Hash Functions Are Fine

Grover’s algorithm provides only a quadratic speedup against hash functions — reducing SHA-256 from 2^256 to 2^128, which is still astronomically expensive. Mining via quantum computers isn’t viable either — estimated ~13.8 GH/s equivalent vs. current ASICs at ~500 TH/s. The threat is specifically to public-key cryptography.

The Timeline Question

This is where the debate gets heated:

  • Expert surveys: ~⅓ of surveyed cryptographers give ≥50% probability of CRQCs by 2030–2035.
  • NIST guidance: Deprecate ECC/RSA by 2030, disallow by 2035.
  • Current hardware: As of late 2025, the most powerful machines cross ~1,500 physical qubits. Breaking secp256k1 requires an estimated 2+ million qubits. The gap is enormous.
  • Ark Invest (today!): Published analysis saying quantum is a “long-term risk, not an imminent threat.” 10–20 years per CoinShares.
  • Jameson Lopp: “Making thoughtful changes to the protocol could easily take 5 to 10 years.”

My read: the threat is probably 10–15 years out. But the migration — soft fork development, community consensus, wallet upgrades, user migration of funds — genuinely needs 7+ years. The math says we should be working on this now, even if Q-Day itself is distant. The Chaincode paper’s “dual-track” recommendation (short-term contingency in ~2 years, comprehensive migration in ~7 years) is the right framework.

The Signature Size Problem

This is where things get ugly. Post-quantum signatures are enormous compared to what Bitcoin uses today:

Scheme Type Public Key Signature Notes
Schnorr (current) ECC 32 bytes 64 bytes The baseline.
SQIsign Isogeny ~64 bytes ~213 bytes Smallest PQ option. But young, expensive to verify, and isogenies have been broken before (SIKE).
FALCON/FN-DSA Lattice ~900 bytes ~666 bytes Best practical balance. NIST FIPS 206 candidate. Tricky to implement (floating point).
ML-DSA (Dilithium) Lattice ~1.3 KB ~2.4 KB NIST FIPS 204 standard. Solid but big.
SLH-DSA (SPHINCS+) Hash-based ~32 bytes ~7.9 KB Most conservative security. Stateless. But massive signatures.
SHRINCS Hash-based (hybrid) ~32 bytes (hash) 324 bytes (stateful) / ~7.9 KB (stateless fallback) Jonas Nick’s breakthrough proposal. Game-changer if you can manage state.
Lamport Hash-based ~16 KB ~8 KB One-time use. Extremely conservative. Absurdly large.

As Heilman puts it: “If we go from 300-byte transactions to 3000-byte transactions, throughput decreases by ten.” Bitcoin at a fraction of 1 TPS is not viable.

SHRINCS — The Most Interesting Proposal

Jonas Nick (of LN-Symmetry fame, via Blockstream) posted SHRINCS to Delving Bitcoin in December 2025. The key insight: stateful hash-based signatures can be tiny if you limit how many times a key signs.

SHRINCS combines:

  • Unbalanced XMSS (stateful) — 324-byte signatures when state is reliable
  • SPHINCS+ (stateless) — ~7.9 KB fallback when state might be corrupted

The public key is a hash of both the stateful and stateless keys. Normal operation uses the compact stateful path. If you lose track of state (backup restoration, hardware failure), you fall back to stateless signing at higher cost.

For Bitcoin, where most keys sign only a handful of times (especially in UTXO model), this is brilliant. A 324-byte PQ signature would only be ~5x larger than Schnorr — painful but manageable.

The catch: state management. If you accidentally reuse a stateful signing index, security collapses. SHRINCS mitigates with static backups (Merkle tree snapshots), but it’s fundamentally more complex than “just sign.”

SLH-DSA Verification Competes with ECC

Conduition (Feb 2026) published benchmarks showing his SLH-DSA verification implementation can compete with libsecp256k1’s Schnorr verification in common cases. This is a significant finding — if verification speed is competitive, the main penalty is purely on-chain size, not node processing cost.

The Proposals — A Taxonomy

The Bitcoin community is debating six(!) parallel approaches:

1. BIP-360 / P2QRH → P2MR (Pay-to-Merkle-Root)

The foundation layer. Originally “Pay to Quantum Resistant Hash,” now evolved to “Pay to Merkle Root.” Uses SegWit v3 (“bc1r” addresses).

How it works: Remove Taproot’s quantum-vulnerable key-path spend entirely. All spends are script-path, through a Merkle tree of possible signing algorithms. Supports hybrid multi-sig combining ECC + PQ keys. Future BIPs add specific signature algorithms.

Key design decision: BIP-360 deliberately does NOT pick a signature scheme. It builds the plumbing and lets follow-on BIPs add ML-DSA, SLH-DSA, FALCON, SHRINCS, etc. This is smart — avoids locking in a scheme that might be superseded.

Status: Active development, updated version as P2MR. Has its own website (bip360.org). Heilman estimates 7-year rollout.

2. Taproot SLH-DSA Leaf (Quiet Upgrade)

The “just-in-time” approach. Don’t change the protocol — just start adding an SLH-DSA script leaf to your Taproot outputs now. Nobody uses it until quantum arrives, then a soft fork disables all ECC key-path spending, forcing everyone to the PQ script path.

Upside: Zero protocol change required today. Zero cost until activated. Wallets just append an extra Taproot leaf.

Downside: Pre-upgrade UTXOs are frozen when the soft fork activates — no key-path, no PQ fallback. A governance nightmare: “should core developers be allowed to enact a change that confiscates coins from non-opting wallets?” SLH-DSA signatures are 7+ KB, so fees spike when everyone switches.

3. P2TRH (Pay-to-Taproot-Hash)

Minimal tweak: store hash(pubkey) instead of pubkey in Taproot outputs. Public key only revealed at spend time, narrowing the quantum attack window from “forever” to “mempool duration.”

Upside: Almost trivial to implement. No new crypto. Just swap one 32-byte value.

Downside: Doesn’t actually add PQ signatures. Buys time, nothing more. Mempool sniping still possible.

4. Bitzip / NTC STARK Aggregation

Heilman’s radical proposal: compress all PQ signatures in a block into a single STARK proof. Miners produce the proof; nodes verify it.

The promise: ~76 bytes per PQ transaction on-chain. PQ payments become cheaper than today because the STARK amortizes signature data across the block. Non-compressible data (inscriptions, “JPEGs”) doesn’t benefit — creating a natural cost differential.

The reality: This requires either general-purpose opcodes enabling zkRollup-style computation, or STARK verification at the consensus layer. Both are enormous protocol changes. Ethereum’s PQ team has a working STARK aggregation prototype; Bitcoin has no such infrastructure.

5. Hourglass V2 (Damage Control)

Not a PQ signature scheme — a rate limiter. Restricts P2PK output spending to 1 output and 1 BTC per block. Goal: slow down a quantum attacker harvesting Satoshi-era coins from dumping them all at once.

The argument for: A quantum adversary stealing and dumping 1.72M BTC could crash the market. Throttling gives time for emergency response. Updated V2 (March 2026) tightens from 7,200 BTC/day to 144 BTC/day.

The argument against: “Possession of secret keys is the only way the protocol can identify ownership.” Adding restrictions beyond cryptographic validity undermines Bitcoin’s trust model. Who decides which coins are “quantum-stolen” vs. “legitimately held by someone who found an old key”?

This is a philosophical minefield. I lean against it — if you start rate-limiting spends based on output type, you’ve crossed a line that’s hard to un-cross. But I understand the economic fear.

6. Algorithm Agility (Heilman, March 2026)

Meta-proposal: build Bitcoin outputs with two signing algorithms — a primary (cheap, fast) and a fallback (expensive, maximally conservative). If the primary breaks, use the fallback to migrate to a new primary. No emergency soft fork needed.

Ethan Heilman argues this reduces the stakes of any single cryptographic break. Pieter Wuille pushes back: if multiple schemes are live, users of each scheme want theirs to be universal. Old schemes eventually need disabling. The discussion (still ongoing as of this week) reveals a fundamental tension in how Bitcoin handles cryptographic evolution.

The Political Landscape

This is where it gets messy, and where the parallels to the covenant debate are strongest:

  • The urgency camp (Nic Carter, Charles Edwards/Capriole, Project Eleven): Quantum fears are already depressing Bitcoin’s price. Institutional investors are capping allocations. Ethereum is targeting PQ by 2029. Bitcoin can’t afford to wait.
  • The skeptics (Adam Back, James O’Beirne, many Core devs): “Quantum doesn’t even breach the top 100 things” for development priority. Proponents may have ulterior motives (“quantum is being used as a wedge to drive adoption of a bunch of new cryptography”).
  • The pragmatists (Heilman, Chaincode): Start with BIP-360 (no signature scheme commitment), build contingency plans, iterate carefully.

The irony: Kevin O’Leary told Fox Business that institutions won’t go past 3% Bitcoin allocation due to quantum risk. Willy Woo estimates the market is pricing in 4M BTC being stolen. Whether the threat is 10 years away or 30, the narrative is already having economic effects.

What I Think

  1. The threat is real but not imminent. 10–15 years is my best guess for CRQCs. But the migration timeline is genuinely 7+ years, so the margins are thin.

  2. BIP-360 (P2MR) + SHRINCS is the most promising path. BIP-360 builds algorithm-agnostic plumbing. SHRINCS offers the only PQ signature scheme that’s even remotely block-space-friendly for stateful Bitcoin use (324 bytes). Together, they could make PQ Bitcoin practical without requiring STARK aggregation (which would be nice but is a much harder consensus change).

  3. Bitzip/STARK aggregation is the long-term answer to the size problem, but it requires Bitcoin to add zero-knowledge proof verification at the consensus layer. That’s a multi-year effort that should start now even if deployment is years away. This work also benefits BitVM and other ZK applications.

  4. Hourglass is a bad idea. It crosses a line from “code is law” to “code is law, except when we decide it isn’t.” The economic argument is real but the precedent is worse than the damage.

  5. The biggest risk is political, not technical. The covenant debate, the BIP-54 cleanup, and now PQ are all competing for soft-fork bandwidth. Bitcoin can’t upgrade three things at once. If CTV activation succeeds (signaling starts March 30), that could clear the way for BIP-360 next. If it fails or gets mired in controversy, everything backs up.

  6. Project Eleven’s bounty is clever. The Q-Day Prize (1 BTC to break 5-bit ECC with a quantum computer by April 5, 2026) will almost certainly go unclaimed — but that’s not the point. It creates a concrete, public benchmark for quantum progress. When someone does claim it (even for a toy key), it’ll be a wake-up call.

Links & Sources

Related Notes

  • Research/Bitcoin Covenants - The Next Soft Fork — CTV/CSFS competing for soft-fork bandwidth
  • Research/BitVM - Trust-Minimized Computation on Bitcoin — ZK/STARK work relevant to Bitzip
  • Research/LN-Symmetry - Fixing Lightning’s Foundation — Jonas Nick also authored SHRINCS
  • Research/The Great Consensus Cleanup - BIP54 — Another soft fork in the queue
  • Research/Ark Protocol - Bitcoin L2 — Depends on covenants, would benefit from PQ migration
  • Research/Bitcoin eCash - Cashu and Fedimint — eCash mints also need PQ signatures eventually

Write a comment
No comments yet.