Bitcoin Under Post-Quantum Stress: What Actually Breaks in the Infrastructure Around It

This is the first article in a two-part series on Bitcoin's quantum transition as an infrastructure problem. The second article explores an intermediate architectural response — a STARK-based one-way shelter model.

Everyone keeps asking "when will quantum computers break Bitcoin?" That's the wrong question. The right question is what happens to the infrastructure built around Bitcoin — bridges, wrapped assets, custody models, peg assumptions — when the signature layer can no longer be trusted.

I've spent enough time building and evaluating cross-chain systems to know that the damage doesn't start when the threat materializes. It starts earlier — when the infrastructure around the base asset hasn't been designed to handle the transition. Bridges, wrapped BTC, custodial reserves, peg mechanics — none of these are built for a world where the underlying key format might be compromised. And right now, almost nobody is designing for that world.

Google Quantum AI's March 2026 whitepaper made the timeline conversation harder to defer. Two optimized Shor-based circuits for ECDLP-256 — one at roughly 1,200 logical qubits, the other at ~1,450 — both under 500,000 physical qubits. That's roughly a 20x resource reduction over prior estimates. No cryptographically relevant quantum computer (CRQC) exists today; credible hardware timelines cluster around 2035–2040. But the gap between "theoretically possible someday" and "inside a planning horizon" just narrowed in a way that infrastructure teams can no longer treat as background noise.

Two Attack Vectors, Two Different Infrastructure Problems

Any serious analysis of quantum risk to Bitcoin starts by separating two fundamentally different attack surfaces. Everything downstream — bridges, custody, migration — depends on which vector you're dealing with.

At-rest exposure targets addresses where the public key is already visible on-chain. The attacker downloads the blockchain, identifies outputs with exposed keys, and runs Shor's algorithm offline. Hours, days, weeks — doesn't matter. No time pressure. The commonly cited estimate is roughly 6 million BTC in this broad risk category, though the number depends on how you count edge cases: early P2PK outputs (including roughly one million BTC attributed to Satoshi), Taproot P2TR outputs where the x-only public key is embedded directly in the output script, and any address whose key has been exposed through prior spending. Not all of these are equally exploitable, but the aggregate exposure is large.

On-spend exposure targets the moment a transaction enters the mempool. When a user spends from a hash-protected address (P2PKH, P2WPKH), the public key appears in witness data for the first time. Google's paper models a "primed" attack where the remaining computation after key exposure could take roughly nine minutes. Bitcoin's average block time is ten. Under those assumptions, an attacker has a meaningful probability — the paper models around 41% — of extracting the private key and broadcasting a competing transaction before the original confirms.

These aren't two flavors of the same problem. They require different quantum hardware capabilities, different countermeasures, and they break different parts of the infrastructure stack.

At-rest exposure can be addressed by a relatively slow CRQC — one that takes days to factor a key works fine when the key has been on-chain for years. BIP 360's Pay-to-Merkle-Root format addresses this by hiding the public key behind a Merkle commitment. Targeted patch.

On-spend exposure requires a fast CRQC with low control latency, and it stays open for every existing transaction type until Bitcoin consensus supports post-quantum signatures. BIP 360 doesn't touch it. No proposed Bitcoin soft fork deployed on mainnet addresses it. This is the vector that makes the problem systemic.

The SegWit Paradox

Here's a fact that surprises most people who haven't examined address format internals: "old" SegWit native (P2WPKH, bc1q...) provides better quantum resistance for stored funds than "new" Taproot (P2TR, bc1p...).

SegWit stores only a hash of the public key in the output. Until the owner spends, the key is nowhere on-chain. Shor's algorithm attacks keys, not hashes. For funds sitting in unused SegWit addresses, the at-rest vector is closed.

Taproot, activated in 2021, embeds the x-only public key directly in the output per BIP 341. Intentional design — it enables efficient key-path spending, Schnorr aggregation, and script privacy through MAST. In the pre-quantum threat model, it's an excellent trade-off. In a post-quantum threat model, it reopens the exact at-rest exposure that hash-based formats had closed.

The major hardware wallets shipped in recent years — Ledger, Trezor, Coldcard, BitBox — and widely used software wallets like Electrum and Sparrow default to SegWit native. Users on these defaults are protected against at-rest attacks as long as they don't reuse addresses. Modern HD wallets (BIP 32/44/84) generate fresh addresses automatically. Most users have this protection without knowing it.

But the ecosystem has been migrating toward Taproot for privacy and efficiency gains. Lightning channels, multisig constructions, advanced scripts — increasingly P2TR. Every Taproot output created is a new at-rest exposure point. In effect, the ecosystem is expanding its future quantum attack surface even as the hardware to exploit it remains years away.

This isn't anyone's mistake. It's the predictable result of optimizing for today's threat model. But when migration becomes urgent, the scope of affected outputs will be larger than the historical P2PK legacy set. And it's still growing.

What Breaks Beyond the Base Asset

Most quantum-risk analysis stops at Bitcoin's signature scheme. But I've spent the last year writing about cross-chain bridge architectures and what breaks in them under stress. The base asset's security assumptions propagate through every system that touches it. Quantum stress is no different — it just hits a different layer.

Wrapped BTC and custodian exposure

wBTC (BitGo custody), cbBTC (Coinbase custody), and similar representations lock real BTC in custodian-controlled Bitcoin addresses and mint tokens on another chain. The security of that locked BTC depends entirely on the custodian's key management. If reserves sit in well-managed P2WSH multisig without address reuse, at-rest exposure is limited. If the custodian uses Taproot or reuses keys — which the end user cannot verify — the reserves are exposed.

Every rebalancing operation between cold and hot wallets creates on-spend exposure windows. I've written about this operational reality before: custodians move funds regularly. Each movement is an exposure event in the post-CRQC world. The user holds a token whose backing is only as secure as key management practices they cannot audit.

And the destination chain doesn't help. Ethereum uses the same secp256k1 curve for account signatures. Every Ethereum account that has ever sent a transaction has its public key permanently visible on-chain. Google's paper identifies multiple quantum attack vectors against Ethereum, with the aggregate value at risk exceeding $100 billion by some estimates. Moving BTC from Bitcoin to Ethereum via a wrapped token means moving from one set of vulnerable keys to another, while adding counterparty risk and bridge complexity.

Bridge signing infrastructure

Most production bridges — custodial, MPC-based, committee-secured — rely on threshold signature schemes over elliptic curves. The bridge operators' keys are the trust anchor. In a post-quantum environment, the bridge doesn't need to be "hacked" — its key material just needs to become derivable. A CRQC applied against a high-value bridge's signing committee could compromise the entire reserve in a single pass. That's a different risk profile than anything I covered in the bridge security analysis. Not a pool drain. Not a solver exit. A math problem that makes the trust model obsolete.

Peg fragility

Wrapped BTC tokens hold their peg because the market believes the locked BTC can be redeemed. Start doubting that the custodian's keys will survive the quantum transition, and the peg weakens. We saw a structural version of this with GBTC — persistent NAV discount for years driven by redemption mechanism uncertainty. The same dynamic could emerge for any wrapped BTC if the market begins pricing in custodian key vulnerability. You don't need a CRQC to break a peg. You need enough participants to believe one is coming.

The custodian coordination problem

Institutional custodians face the worst position. They need quantum-safe formats, but Bitcoin doesn't support quantum-safe signatures in consensus yet. They can move to SegWit and practice strict key hygiene — no reuse, no Taproot for cold storage — but that only closes at-rest exposure. The on-spend vector stays open every time they move funds. And they move funds regularly: rebalancing, settlement, operational needs. There's no clean way to hold and operate large BTC reserves in a quantum-threatened environment without protocol-level changes that don't exist yet.

The Signature Size Problem

Even once Bitcoin consensus supports post-quantum signatures — which requires at minimum a soft fork — the infrastructure consequences are substantial. The cryptography works. What changes is the economics of every transaction.

The leading NIST-standardized candidates give a sense of the scale:

Two orders of magnitude at the conservative end. Blocks fill faster. Fee markets restructure. Mempool dynamics shift. Hardware wallets need redesigned storage and computation pipelines. Exchanges, payment processors, Lightning nodes — anything that batches or verifies signatures at scale takes a throughput hit. The exact PQC scheme Bitcoin will adopt isn't settled; different candidates carry different size-performance tradeoffs, and the community hasn't converged.

I've seen this pattern in bridge design — when message payload sizes grow, the entire fee and throughput model changes. Different root cause here, but the operational disruption is structurally similar. This isn't a cryptography problem to be solved and forgotten. It's a permanent shift in Bitcoin's transaction economics that every downstream system needs to absorb.

Governance Latency: The Real Bottleneck

Bitcoin's upgrade history gives us the base rate. SegWit: roughly three years from proposal to activation, including a prolonged community conflict. Taproot: about two years, less controversial. Block size debate: four-plus years and a chain split.

BIP 360 is in the repository. Ethan Heilman, its co-author, estimates seven years for full migration if work starts immediately — roughly 2.5 years for BIP finalization and code review, half a year for activation, plus ecosystem-wide adoption. That's optimistic by Bitcoin's standards.

Full PQC signature integration is a harder upgrade than BIP 360. New opcodes, new transaction validation rules, ecosystem-wide wallet and infrastructure updates. If BIP 360 is a seven-year process, full PQC integration is ten to twelve years from serious start.

The timelines roughly overlap. CRQC hardware at 2035–2040. Full Bitcoin migration, started today, at 2036–2038. The margin is thin at best. Every year of governance delay, debate, or prioritization conflict compresses the window further.

Compare: NIST deprecates quantum-vulnerable algorithms after 2030, full prohibition after 2035. Large technology organizations — Google, Microsoft, major cloud providers — are already setting internal post-quantum migration deadlines years ahead of the expected hardware threat. They can mandate changes by executive decision. Bitcoin cannot. The same decentralized governance that makes Bitcoin censorship-resistant makes it slow to adapt. Feature in normal times. Structural vulnerability under time pressure.

HNDL: The Risk That's Already Crystallized

Harvest Now, Decrypt Later isn't theoretical. It's a documented intelligence strategy — collect encrypted material today, break it when quantum capability arrives. The US Federal Reserve has published specifically on HNDL risk to distributed ledger networks.

Bitcoin's exposure is uniquely direct. The blockchain is a public, permanent record. Every transaction that has ever revealed a public key is already available to anyone who downloads the chain. No interception needed. The data is already harvested. When a CRQC becomes operational, those keys can be attacked systematically, offline, at the attacker's pace.

The relevant window for protective action isn't "before a CRQC is built." It's "before funds are committed to formats where key exposure has already occurred." For BTC in legacy P2PK or Taproot outputs today, that window is already closed. The exposure is locked in. The only open question is when the computational capability catches up.

What This Means for Infrastructure Builders

For anyone building or evaluating systems that touch Bitcoin — bridges, custody platforms, wrapped asset protocols, payment infrastructure — the quantum transition is not a distant theoretical concern. It's a design constraint that should be entering architecture decisions now.

Bridges need to evaluate what key formats their Bitcoin reserves use, whether their signing infrastructure can be migrated to post-quantum schemes, and what happens to peg integrity if the market starts pricing in quantum risk before a CRQC actually exists.

Custody platforms need key management strategies that minimize exposure — SegWit formats, strict non-reuse, preparation for the eventual PQC soft fork — while planning for the operational disruption of dramatically larger signatures hitting every part of the transaction pipeline.

Wallet and account infrastructure needs migration pathways: how users move from current-generation keys to post-quantum formats, and what happens during the transition period when both types coexist on the same network. I've explored similar multi-format coexistence challenges in the account abstraction context — the coordination problems are structurally similar.

None of this requires panic. The CRQC timeline is measured in years, possibly over a decade. But the migration timeline is also measured in years — and Bitcoin's governance process doesn't accelerate under pressure. It slows down, because pressure creates disagreement.

The question isn't whether quantum computing will affect Bitcoin. The direction of the technical threat is clear enough, even if timelines remain debated. The harder question is whether the infrastructure built on top of Bitcoin — the bridges, the wrapped assets, the custody assumptions, the signature economics — will have been redesigned before the transition window closes.

Every system that touches Bitcoin should already be assessed through a cryptographic transition lens. Not as a compliance exercise. As an architecture constraint. The ones that start now will have options. The ones that wait will have emergencies.

Key Takeaways

• The quantum threat to Bitcoin splits into two distinct vectors: at-rest exposure (public keys already on-chain, attackable offline) and on-spend exposure (keys revealed in mempool, attackable in ~9 minutes)
• SegWit native provides better quantum resistance for stored funds than Taproot — the ecosystem is expanding its attack surface by migrating toward P2TR
• Wrapped BTC security depends on custodian key management practices that end users cannot audit — every rebalancing operation creates quantum exposure windows
• Bridge signing infrastructure (MPC, threshold schemes) becomes derivable under quantum attack, compromising entire reserves in a single pass
• Post-quantum signatures are 40–780x larger than current ones, permanently restructuring Bitcoin's transaction economics
• Bitcoin's governance process requires 7–12 years for full PQC migration — roughly overlapping with credible CRQC hardware timelines of 2035–2040