Bitcoin’s Quantum Timeline Is Not RSA’s Quantum Timeline

Scan the quantum computing coverage of Bitcoin and you will find a remarkable pattern. Article after article cites the same RSA-2048 qubit estimates – 20 million noisy physical qubits (Gidney–Ekerå), <1 million (Gidney 2025, surface-code assumptions), and ~100,000 (Pinnacle Architecture 2026, QLDPC-code assumptions). These estimates are not directly comparable because they assume different fault-tolerance architectures and hardware constraints. – then pivots to reassure readers that Bitcoin is safe because quantum computers cannot yet factor 2,048-bit numbers. The problem with this framing is simple: Bitcoin does not use RSA. It has never used RSA. Every transaction signature, every key derivation, every proof of ownership on the Bitcoin network depends on a single cryptographic foundation: elliptic curve cryptography (ECDSA and Schnorr signatures) over the secp256k1 elliptic curve, a 256-bit scheme that requires dramatically fewer quantum resources to break than RSA-2048. The RSA timeline is the wrong benchmark. And using it leads analysts, journalists, and even some security professionals to systematically underestimate how soon Bitcoin faces a real quantum threat.

This article is not another end-to-end quantum risk assessment of Bitcoin. I’ve done those before. It focuses on a single, specific, and widely overlooked point: the quantum security inversion between ECC and RSA, what it means for Bitcoin specifically, and why anyone modeling quantum timelines for cryptocurrency needs to use the right numbers.

The wrong benchmark: why RSA-2048 timelines do not apply to Bitcoin

RSA and ECC achieve equivalent classical security at vastly different key sizes. A 256-bit elliptic curve key (like secp256k1) provides roughly 128 bits of classical security – the same as a 3,072-bit RSA key. The reason is that the best classical attack on ECC (Pollard’s rho) runs in $$O(\sqrt{r})$$ time – requiring roughly $$2^{128}$$ operations for a 256-bit curve – while the best classical attack on RSA (General Number Field Sieve) runs in sub-exponential time, requiring 3,072-bit keys to reach the same security level. ECC’s math is classically harder per bit, so it needs fewer bits. That is the entire reason the industry adopted it.

Shor-type algorithms give polynomial-time quantum attacks on both factoring and ECDLP. In practice, concrete cost is dominated by circuit constants (e.g., Toffoli/T counts and depth), parallelism limits, and fault-tolerance overhead – not just big‑O. Key size is a first-order driver of Shor-type costs, but concrete resource needs also depend heavily on circuit design, hardware constraints, and fault-tolerance assumptions – so ‘bit-length alone’ can mislead. And 256 is a much smaller number than 2,048 – let alone 3,072.

When commentators cite the latest RSA-2048 qubit estimate and then apply it to Bitcoin, they are comparing the wrong numbers. The correct comparison is secp256k1 (256-bit ECC) versus RSA-3072 (its classical security equivalent) – and at that comparison, the disparity is dramatic.

The resource gap: what the research actually says about breaking secp256k1

The quantum resource estimates for 256-bit ECC come from a distinct body of research, separate from the RSA factoring literature. Because both curves live over ~256-bit prime fields, leading-order quantum resource estimates are comparable. Exact constants can still vary with circuit design and coordinate/formula choices. The Roetteler et al. (2017) formula depends on field size $$n$$, not on the specific curve equation $$y^2 = x^3 + 7$$ versus P-256’s parameterization.

Here is what the peer-reviewed and pre-print literature estimates for breaking 256-bit ECC:

Roetteler, Naehrig, Svore, and Lauter (2017) established the baseline: 2,330 logical qubits and $$1.26 \times 10^{11}$$ Toffoli gates for P-256. They explicitly compared this with RSA-3072 (the classical security equivalent), citing Häner, Roetteler, and Svore (2016) estimates of 6,146 logical qubits and $$1.86 \times 10^{13}$$ Toffoli gates for that problem. The ratio: ECC needs 2.6× fewer qubits and 148× fewer gates at equivalent classical security.

Webber et al. (2022), from the University of Sussex, mapped these logical requirements to physical qubits under surface code error correction, framing their analysis around Bitcoin’s secp256k1 (using underlying quantum circuits from Häner et al. 2020, developed for P-256 but functionally identical for any 256-bit prime-field curve). Their time-versus-qubit tradeoff: 317 million physical qubits for a 1-hour attack, 13 million for a 1-day attack, and approximately 1.9 billion for a 10-minute attack (the Bitcoin block interval).

Ha et al. (2024) in Nature Scientific Reports estimate $$N_phy ≈ 5.81×10^6$$ for n=256 under their assumptions (e.g., $$εp={10^-3}$$, pfail=0.01), with a corresponding runtime of ~5.37×$$10{^6}$$ seconds (~62 days) in their baseline table—useful for long-range/offline attack modeling, but not directly comparable to “10-minute” or “1-hour” mempool-window estimates without normalizing time, parallelism, and architectural assumptions.

Gouzien, Ruiz, Le Régent, Guillaud, and Sangouard (2023), published in Physical Review Letters, took a radically different architectural approach using repetition cat qubits, which exploit exponential bit-flip suppression. Their estimate: 126,133 physical cat qubits and 9 hours – roughly 60× fewer physical qubits than conventional surface code implementations.

Litinski (2023), in an unreviewed preprint, used PsiQuantum’s active-volume photonic architecture — which assumes logarithmic-depth non-local inter-module connections not yet available in hardware — to estimate that a 256-bit elliptic curve private key could be computed with only ~50 million Toffoli gates, potentially enabling one key break every 10 minutes with ~6.9 million physical qubits. Under a conventional 2D-local layout, Litinski’s own analysis gives a higher figure of ~109 million Toffoli gates per key. These numbers are dramatic improvements over Roetteler’s $$1.26 \times 10^{11}$$ baseline, but the active-volume model has not been applied to RSA for an equivalent comparison, so direct cross-problem comparisons should be made with caution.

Now compare these with the latest RSA-2048 estimates. Gidney’s May 2025 preprint (from Google Quantum AI, with publicly available code but not yet peer-reviewed) achieved ~1,409 logical qubits, ~6.5 billion Toffoli gates, and ~898,000 physical qubits (surface code) with less than a week of runtime (under the paper’s stated surface-code assumptions).

An important nuance is that RSA‑2048 and ECC‑256 do not sort cleanly by “bits alone” once you include modern circuit optimizations. For example, a 2025 RSA‑2048 estimate reports 1,409 logical qubits and ~6.5 billion Toffoli operations under specific surface-code assumptions, while the Roetteler‑2017 ECC baseline for a 256‑bit curve reports 2,330 logical qubits and ~1.26×10^11 Toffolis. On these particular baselines, RSA‑2048 is cheaper than the unoptimized ECC‑256 circuit. The “ECC is easier than RSA” claim is most defensible when you compare comparable classical security levels (ECC‑256 vs RSA‑3072), where the same Roetteler table reports ECC requiring fewer logical qubits and far fewer Toffolis than RSA‑3072. Bottom line: the correct lesson is not “ECC always falls before RSA‑2048,” but that Bitcoin risk modeling must use matched assumptions and matched security levels, rather than importing RSA‑2048 headlines as a generic proxy.

The bottom line: a CRQC threshold sufficient for large-scale ECDLP attacks does not map cleanly onto RSA thresholds. At comparable classical strength (ECC‑256 vs RSA‑3072), published logical estimates favor ECC being cheaper – but RSA‑2048 can be cheaper than some ECC circuit baselines. Avoid using RSA‑2048 as a proxy for Bitcoin either way; compare like-for-like assumptions and security levels.

Where ECC sits in Bitcoin – and why it matters

Bitcoin’s entire ownership model rests on elliptic curve cryptography over secp256k1. A 256-bit private key $$k$$ is multiplied by the curve’s generator point $$G$$ to produce a public key $$Q = kG$$. This public key is then double-hashed – SHA-256 followed by RIPEMD-160 – to produce a 160-bit address. The hash layer is quantum-resistant: Grover’s algorithm reduces SHA-256’s preimage resistance from $2^{256}$ to $2^{128}$ operations, and RIPEMD-160’s from $2^{160}$ to $2^{80}$. Because Grover’s algorithm must be executed sequentially and cannot be effectively parallelized, $2^{80}$ quantum operations remain entirely infeasible for a quantum computer. The quantum vulnerability is not in the address hash. It is in the ECDSA signature, which requires revealing the full public key.

Different Bitcoin address types expose the public key at different moments. P2PK outputs were dominant in Bitcoin’s earliest period (2009) and remain present in legacy UTXOs; they embed the public key directly on-chain – permanently and irrevocably visible. P2PKH and P2WPKH (SegWit) addresses hide the public key behind the hash until the owner spends funds, at which point the full public key must appear in the transaction script. P2TR (Taproot) – activated in November 2021 and now accounting for a significant fraction of UTXOs – embeds a 32-byte x-only tweaked public key directly in the output, exposed from the moment funds arrive. BIP-360’s authors explicitly flagged Taproot’s key-path spend as a quantum vulnerability.

This creates a patchwork of exposure. An attacker who can solve the ECDLP on secp256k1 faces three distinct scenarios, each with very different time constraints:

Long-range attack (no time pressure): For P2PK outputs, P2TR addresses, and any address whose public key was previously revealed through spending or reuse, the attacker can download the blockchain, extract public keys, and compute private keys offline over days or weeks. This is feasible the moment any CRQC can solve 256-bit ECDLP, regardless of runtime.

Mempool interception (~10-minute window): For spends that reveal a public key at broadcast, the vulnerability window is driven by time-to-confirmation – often minutes but sometimes longer depending on fees and congestion. Webber et al. estimated this requires ~1.9 billion physical qubits – far more demanding than the long-range attack.

Active transaction replacement: A quantum-capable attacker could extract public keys from pending transactions and substitute their own, requiring quantum hardware and potentially mining hashrate (though simply broadcasting a replacement transaction with a massive Replace-By-Fee bribe might suffice to incentivize existing miners).

The critical implication: the long-range attack becomes feasible years before the mempool interception attack. A CRQC that needs a full day to break one key poses zero threat to fresh transactions from hashed addresses – but devastating risk to exposed P2PK and P2TR outputs.

How much bitcoin is exposed?

Multiple independent analyses have quantified the directly vulnerable portion of Bitcoin’s supply – the coins behind already-exposed public keys, susceptible to the long-range attack with no time constraint.

Several analyses have tried to quantify how much BTC sits behind already-exposed public keys (i.e., directly vulnerable to long-range/offline attacks once secp256k1 ECDLP becomes tractable). Deloitte (Itan Barmes, Bram Bosch, and Olaf Haalstra) reported “over 4 million BTC (about 25% of all Bitcoins)” as potentially vulnerable at the time of their analysis, with ~2M in P2PK and ~2.5M in reused P2PKH. Chaincode’s 2025 report broadens the discussion to 20–50% (4–10M BTC) potentially vulnerable, and cites ~6.26M BTC as “immediately quantum-vulnerable” based on Project Eleven’s estimate (Jan 2025). CoinShares offers a different lens: while acknowledging legacy P2PK exposure, it argues that only ~10,200 BTC sits in UTXOs large enough to create “appreciable market disruption” if stolen rapidly—an operational/market-impact framing rather than a claim that the remaining exposed coins are cryptographically safe. Deloitte also cautions that large-scale theft could crash price and erode confidence, creating broader harm beyond the directly compromised UTXOs.

Why Bitcoin is more exposed than traditional infrastructure at the ECC threshold

A thought experiment clarifies the stakes. Imagine a CRQC that can solve 256-bit ECDLP in one day but cannot yet factor RSA-2048. What breaks? Every system relying on 256-bit ECC is vulnerable — and that includes Bitcoin, Ethereum (also secp256k1), TLS 1.3 key exchange (X25519/P-256), Signal’s Double Ratchet (X25519), passkeys (P-256), and code signing (P-256). But most of these systems have centralized remediation paths: certificate authorities can revoke and reissue, banks can freeze accounts, Apple and Google can push wallet updates.

Bitcoin’s properties make it uniquely brittle at this threshold. Its ledger is immutable – stolen coins cannot be reversed. Its public keys are permanently committed on-chain — exposed keys cannot be un-exposed. Its governance is decentralized and slow – SegWit took ~2 years from proposal to activation; Taproot took ~4 years; Chaincode Labs estimates a comprehensive post-quantum migration would take approximately 7 years. And the trajectory of algorithmic improvement and hardware roadmaps suggests 5–10 years may be all that is available.

This is not to say traditional infrastructure is safe. TLS 1.3 key exchange via ECDHE is equally quantum-vulnerable, and the HNDL (Harvest Now, Decrypt Later) threat applies to any recorded session. But the distinction matters for risk modeling: traditional systems can rotate keys and patch software under centralized authority; Bitcoin cannot. The CRQC-breaks-ECC-but-not-RSA window is the period of maximum relative danger for Bitcoin specifically.

The Bitcoin community knows – and is already working on it

It would be unfair to suggest the Bitcoin developer community is unaware of this problem. Active work is underway on multiple fronts.

BIP-360 (Pay-to-Merkle-Root / P2MR), authored by Hunter Beast, Ethan Heilman, and Isabel Foxen Duke, was merged into the official BIP repository on February 11, 2026. It introduces a new SegWit v2 output type that eliminates the quantum-vulnerable key-path spend from Taproot, committing only to a Merkle root of a Tapscript tree. BIP-360 is a framework – it does not specify a post-quantum signature algorithm, leaving space for NIST-standardized ML-DSA or SLH-DSA.

The Chaincode Labs whitepaper by Milton and Shikhelman provides the most comprehensive technical roadmap to date, analyzing signature size constraints (current ECDSA signatures are ~71 bytes; ML-DSA runs 2.4–4.6 KB, SLH-DSA 7.8–49 KB), block capacity implications, and migration path options. Bitcoin developer discussions have also explored Winternitz one-time signatures via OP_CAT and cross-input signature aggregation to manage the bandwidth overhead.

On the tooling side, Project Eleven – a crypto security startup that raised a $20 million Series A led by Castle Island Ventures with participation from Coinbase Ventures – has built the open-source Bitcoin Risq List to continuously track quantum-vulnerable addresses across the entire network. They have also deployed “yellowpages,” a protocol that lets Bitcoin holders generate post-quantum keys and bind them to existing addresses without on-chain migration – essentially a pre-positioning step so that when a consensus-level PQC upgrade arrives, users already have quantum-resistant key material ready. Project Eleven has additionally built and open-sourced the first post-quantum testnet for Solana, replacing Ed25519 with NIST-standardized ML-DSA, demonstrating that end-to-end quantum-resistant transactions are practical even on high-throughput chains.

The debate over unmigrateable coins – particularly Satoshi’s ~1 million BTC – remains unresolved. Jameson Lopp has proposed a phased approach: a multi-year grace period for voluntary migration followed by consensus-level rejection of all legacy signatures. Others argue any freezing of coins violates Bitcoin’s core property guarantees. This governance debate will intensify as quantum hardware advances – but it is, at least, happening.

Getting the framing right matters

When analysts, journalists, and security professionals write about quantum risk to Bitcoin, they owe their readers the right benchmark. The relevant research is not Gidney’s RSA-2048 estimate. It is Roetteler et al. (2017), Webber et al. (2022), Ha et al. (2024), Gouzien et al. (2023), and Litinski (2023) – the body of work specifically quantifying quantum attacks on 256-bit elliptic curves. The Kudelski Security quantum attack resource estimator provides a useful consolidated reference for comparing RSA and ECC requirements side by side.

The difference is not academic. At equivalent classical security (P-256 ≈ RSA-3072), ECC requires 2.6× fewer logical qubits and 148× fewer Toffoli gates. The implication is that there might exists a window during which a CRQC can break secp256k1 but cannot yet factor RSA-2048 or RSA-3072. During that window, billions of dollars in bitcoin sit behind permanently exposed public keys with no centralized mechanism for remediation. Analysts who benchmark Bitcoin’s quantum exposure against RSA timelines are, in effect, giving their readers a false sense of how much time remains.

The Bitcoin community is not helpless. BIP-360 exists. The research is progressing. The governance conversations, however painful, are underway. But none of that changes the mathematical reality at the core of this analysis: Shor’s algorithm does not respect classical security equivalences. It cares primarily about the size of the numbers involved — though constants, circuit structure, and architecture assumptions complicate any simple comparison. At only 256 bits, Bitcoin’s numbers are far smaller than the RSA keys that dominate the headlines. Whether that makes Bitcoin’s ECC fall first, or merely differently, is a question the current research cannot definitively answer — and that uncertainty alone should give pause to anyone using RSA-2048 timelines as a proxy for Bitcoin’s quantum exposure.