The Quantum Threat to Bitcoin and Ethereum, Measured

TL;DR

Nobody has broken a 256-bit elliptic curve key on quantum hardware. The largest one broken in public is 15 bits, awarded Project Eleven's 1 BTC Q-Day Prize on 24 April 2026, up from a 6-bit break in September 2025. secp256k1 is 256 bits. Everything else in this argument is a resource estimate on paper. Three of those landed in 2026. The two that state a logical qubit count agree closely: roughly 1,200 to 1,457 logical qubits running 39 to 90 million Toffoli gates. The third reports physical atoms only. They disagree by 25x on physical qubits — under 500,000 in Google's estimate against 19,397 in IonQ's — because physical count tracks assumed error rate and error-correcting code, not the algorithm. Google's own BigQuery analysis in March 2026 counted about 6.9 million BTC in quantum-vulnerable scripts, roughly 1.7 million of it in P2PK outputs. Taproot made this worse rather than better: P2TR writes the public key on chain in the clear. Ethereum's largest exposure is not user wallets at all. It is 37 million ETH of consensus stake behind BLS signatures and 15 million ETH behind KZG commitments.

When Will Quantum Computers Break Bitcoin? Start With the Demonstrated Number

There is one number in this debate that is not a projection. On 24 April 2026 Project Eleven awarded its 1 BTC Q-Day Prize to Giancarlo Lelli for deriving a private key from a public key over a 15-bit elliptic curve — a search space of 32,767 — on publicly accessible quantum hardware, using a variant of Shor's algorithm. The previous public record was a 6-bit break by Steve Tippeconnic in September 2025. That is a 512x improvement in seven months, and it leaves the state of the art 2^241 short of secp256k1. The attribution of the 6-bit result comes from Project Eleven's own write-up rather than a paper I read.

Hold that next to the two other things that have been built. Quantinuum's Helios has the strongest commercially published encoding rate: 98 physical trapped-ion qubits giving 94 error-detected logical qubits at roughly 1:1, or 48 error-corrected ones at 2:1, at 99.921% two-qubit and 99.9975% single-qubit gate fidelity. The product page says 50 logical, the November 2025 commercial launch release said 48, and I could not resolve which is current. Google's Willow processor demonstrated surface code scaling from distance-3 to distance-7 with roughly 2x error suppression per step, from 105 physical qubits, published in Nature in December 2024.

So the demonstrated column reads: 15-bit curve broken, 48 to 50 logical qubits built, error correction improving as codes grow. The projected column asks for around 1,450 logical qubits running tens of millions of gates — roughly a 29x shortfall.

The gate depth gap matters more and almost nobody reports it. Public fault-tolerant demonstrations run handfuls of logical operations. The blueprints call for 39 to 90 million Toffoli gates, each of which has to succeed. A 29x shortfall in qubit count and a shortfall of seven orders of magnitude in circuit depth are not the same kind of problem, and headlines that count only qubits hide the second one.

The Global Risk Institute's Quantum Threat Timeline Report 2025 surveyed 32 experts and put a cryptographically relevant quantum computer at 19–34% probability within ten years and 5–14% within five, up from 17–31% and 4–11% in the 2023 edition. Those figures reach me through a secondary summary, so treat them as indicative. One caveat outweighs the sourcing: the survey defines a CRQC as one that breaks RSA-2048 within 24 hours, and the 2026 papers put secp256k1 one to two orders of magnitude easier on the same machine. Do not quote those percentages as a Bitcoin timeline.

Three 2026 Resource Estimates, and Why They Do Not Contradict Each Other

Three blueprints for computing a 256-bit elliptic curve discrete log landed inside six months. Coverage treated them as competing headlines and usually reported whichever number was smallest. They are not competing.

Read the logical column, then the physical column. The logical figures agree to within about 20%, because the algorithm is the same algorithm. The physical figures differ by 25x between Google and IonQ, and by 50x once the Oratomic floor of 10,000 atoms is counted, because physical count is set by the assumed error rate and the code family, not by Shor. Runtime differs by a factor of roughly 1,600 to 2,000 because gate clock speed does.

Google's paper, Securing Elliptic Curve Cryptocurrencies against Quantum Vulnerabilities↗, is dated 30 March 2026, authored by Ryan Babbush, Adam Zalcman, Craig Gidney, Michael Broughton, Tanuj Khattar and Hartmut Neven of Google Quantum AI, with Thiago Bergamaschi of UC Berkeley, Justin Drake of the Ethereum Foundation and Dan Boneh of Stanford. Its headline is either 1,200 logical qubits with 90 million Toffolis or 1,450 with 70 million — you trade width for depth. It states the result "could be realized with fewer than half a million physical qubits (nearly a 20 fold reduction over prior estimates)", against Litinski's earlier figure of roughly 9 million. Assumptions: superconducting hardware, 10^-3 physical gate error, planar degree-four connectivity, surface code with yoked dense storage.

The authors attested the circuit costs with a zero-knowledge proof — SP1 with a Groth16 SNARK — rather than publishing the attack circuits. Responsible disclosure, and it also means the core claim is not independently reproducible from the paper alone. Google is a commercial quantum vendor with a reason to make its own hardware path look nearest, and the paper carries a financial conflict of interest statement I did not read.

IonQ describes its blueprint↗ as the first fully compiled, end-to-end design of its kind: a trapped-ion architecture using 19,397 physical qubits for 1,457 logical ones, 39 million logical Toffolis, computing a secp256k1 discrete log in 25.7 days. Assumptions are 10^-4 two-qubit gate error, 10^-5 single-qubit, 10^-7 ion loss, 10^-5 leakage, with qLDPC codes on a "Walking Cat" architecture. Prior trapped-ion estimates ranged from 1.2 million to 9.4 million physical qubits. Two corrections on the headline: "26 days to break a key" is wrong, because success probability is 40.7% rigorous to 63.3% heuristic per attempt, so it is 26 days per attempt at roughly even odds. And the paper was a day old when I wrote this, has had no independent scrutiny, and its scale maps onto IonQ's own stated 2027–2028 roadmap.

The Caltech and Oratomic paper↗ is the most misquoted of the three. It claims Shor's runs at cryptographically relevant scale on as few as 10,000 reconfigurable neutral atoms, with P-256 discrete log in a few days at 26,000 physical qubits, and puts RSA-2048 one to two orders of magnitude slower than P-256 on the same machine. The abstract hedges plainly: "Although substantial engineering challenges remain, our theoretical analysis indicates that an appropriately designed neutral-atom architecture could support quantum computation at cryptographically relevant scales." The demonstrations it cites are three experiments on three different machines, none of which is the proposed architecture.

Google notes that more aggressive assumptions cut its own count further. The "bicycle" 2-gross qLDPC and "Pinnacle" architectures approach 100,000 physical qubits, but need degree-seven and degree-ten non-planar connectivity "that has yet to be demonstrated in actual superconducting qubit devices", and Pinnacle lacks efficient decoders and would need nearly a month of runtime.

Fast Clock or Slow Clock Decides the Attack Class

This is the most useful concept in the Google paper and the one least covered elsewhere. Gate clock speed does not just change how long an attack takes. It changes which attack is possible.

Google splits hardware into fast-clock — superconducting, silicon spin and photonic: Google, IBM, Amazon, Rigetti, IQM, PsiQuantum, Xanadu, Diraq, Intel — and slow-clock, meaning trapped ion and neutral atom: IonQ, Quantinuum, AQT, QuEra, Infleqtion, Atom Computing, Pasqal, Logiqal. Surface code rounds run around 1 microsecond on the first group and around 100 microseconds on the second.

On fast-clock hardware, 70 to 90 million Toffolis resolve in 18 to 23 minutes of wall clock, assuming reaction-limited execution with a 10 microsecond control-system reaction time and 50% overhead per Toffoli. Bitcoin's block time is 10 minutes. Worse, the first half of Shor's for an elliptic curve discrete log depends only on the curve parameters, not the target key, so a machine can sit primed and start real work the moment a public key appears. That precomputation halves the post-key-reveal window to roughly 9 or 12 minutes depending on the circuit variant, which Google simplifies to about 9 minutes on average for a first-generation fast-clock CRQC. Sustaining it needs about 500,000 magic states per second — at 50,000 qubit-rounds per T state and 1 microsecond rounds, about 25,000 physical qubits for production, small next to the half million the algorithm wants. On slow-clock hardware the same rate would need roughly 2.5 million physical qubits for the factories alone.

The consequence:

• On-spend attack. Your public key is revealed when you broadcast a spend. An attacker races to derive the private key and get a conflicting transaction confirmed first. Only fast-clock hardware can do this. Private mempools and commit-reveal defeat it.
• At-rest attack. Your public key already sits visible on chain in an unspent output. The attacker takes as long as they like. Both hardware families can do this. Nothing defeats it except moving the coins.

Google frames two scenarios. In Scenario 1, fast-clock hardware arrives first and both attack classes become viable at essentially the same moment. In Scenario 2, slow-clock scales faster and at-rest attacks arrive meaningfully earlier. The mitigations differ, which is why the distinction belongs in any design conversation. I go through the protocol-level responses in Post-Quantum Migration for Blockchain Teams.

The RSA Baseline Moved First, and It Reset Everyone's Priors

Before the 2026 elliptic curve papers there was Craig Gidney's May 2025 result on RSA. How to factor 2048 bit RSA integers with less than a million noisy qubits↗ cut the requirement from 20 million noisy qubits in 8 hours — the Gidney–Ekerå figure from 2019 — to under 1 million in under a week: a 20x reduction in qubits bought with roughly 20x more runtime, through approximate residue arithmetic, yoked surface codes and magic state cultivation.

The trend here is not hardware improving faster than expected. It is algorithms and error-correction schemes getting cheaper on paper — and none of those revisions moved a single physical qubit into existence. Both are true at once, and most coverage picks one.

Which Bitcoin Is Actually At Risk

Google ran the numbers against bigquery-public-data.crypto_bitcoin. In March 2026, roughly 6.9 million BTC across all script types were quantum-vulnerable. About 1.7 million of that — nearly 9% of all bitcoin — sits in P2PK outputs, including Satoshi-era mining rewards. Dormant quantum-vulnerable bitcoin "may reach 2.3 million BTC when all script types are considered".

The methodology matters as much as the number. P2PK, P2MS and P2TR were counted 100% vulnerable. P2PKH, P2SH, P2WPKH and P2WSH were counted vulnerable only where the address has already appeared in an input and still holds unspent outputs — key reuse.

Independent counts cluster nearby and none share a methodology: Coinbase's Quantum Advisory Council reported at roughly 7 million BTC, Glassnode at 6.04 million or 30.2% of supply, Deloitte at over 4 million, and Project Eleven at roughly 7 million under a long-exposure definition — the figure Galaxy Research cites rather than reproduces. Those reach me through secondary reporting. Cite methodology and measurement date with any of them.

The Taproot regression

Here is the finding that should change practical advice and has not. Every guide says "use a modern address type and never reuse it". That advice is wrong for Bitcoin's newest script type.

P2TR — the bc1p addresses — writes the tweaked public key straight into the locking script, with no hash in front of it. Google's paper says it directly: P2TR "stores the tweaked public key directly in the locking script without hiding it behind a hash value which brings back the quantum vulnerability of P2PK and P2MS addresses". Pay-to-public-key-hash removed that exposure in 2009. Taproot put it back. This is not a fringe script type: measured across blocks 877,259 to 930,340, P2TR moved roughly 16.8 million BTC during 2025 and made up 21.68% of all Bitcoin transactions that year.

So the correct guidance is narrower and more awkward than the folklore:

• bc1q (P2WPKH or P2WSH) with no address reuse is at-rest safe. The chain sees a hash, not a key.
• bc1p (P2TR) is at-rest exposed by construction, reuse or not.
• Every address type, including a fresh bc1q, is on-spend exposed the moment the signature hits the mempool.

If you write wallet guidance or teach custody, that distinction belongs in the material. I cover key handling in how to store Bitcoin safely and the underlying script model in what a blockchain actually is.

Grover does not break mining

Google's paper gives two structural reasons Bitcoin's proof-of-work is not meaningfully threatened by Grover's algorithm. The quadratic speedup "is all but consumed by the overheads of quantum error correction", and Grover does not parallelise well, while mining's entire advantage comes from hardware acceleration and massive parallelisation. Neither reason depends on hardware progress. The threat to blockchains is to signatures over secp256k1, not to SHA-256 and not to mining.

Ethereum's Exposure Is BLS and KZG, Not Your Wallet

Coverage of Ethereum's quantum exposure stops at the account model: your public key leaks when you first transact, account abstraction lets you rotate later, done. That is one of five exposures Google enumerates in Table II of the same whitepaper, and it is neither the largest nor the one users can do least about.

Thirty-seven million ETH of consensus stake rests on BLS signatures. Fifteen million ETH of L2 and protocol value rests on KZG commitments. Neither is fixable by user action, wallet upgrade or address rotation. KZG is a binding commitment scheme whose security reduces to discrete log, so after Q-day an attacker could equivocate on blob data availability — the thing rollups lean on for their security argument. The replacement, STARK-based or lattice-based commitments, is still open research. That is why the honest timeline is not sooner.

All five classes are at-rest attacks. Ethereum's 12-second slots and its move to private mempools through TEE-based BuilderNet mean an early fast-clock machine is, in Google's assessment, unlikely to launch on-spend attacks against Ethereum. The flip side: Google estimates a fast-clock CRQC could crack the 1,000 highest-net-worth ETH accounts — about 20.5 million ETH — in under nine days, which holds only if the machine attacks from the primed state at roughly nine minutes a key rather than the 18 to 23 minutes a cold run takes.

The Foundation's plan at pq.ethereum.org↗ splits across three protocol layers with milestone labels: I* for a post-quantum key registry in consensus, J* for signature precompiles in execution, L* for post-quantum attestations plus leanVM, M* for aggregation and blobs. Consensus replaces BLS with leanXMSS hash-based signatures, aggregated through leanVM, a minimal zkVM cited at roughly 250x data compression. Around ten client teams are building post-quantum consensus clients against leanSpec. The stated timeline: "L1 protocol upgrades could be completed by 2029, with full execution-layer migration taking additional years beyond that." That is the Foundation's own assessment.

What the Proposals Actually Are, and What They Are Not

Three specifications get cited as though Bitcoin and Ethereum are shipping post-quantum cryptography. None of them contains a post-quantum signature algorithm.

BIP-360 was renamed Pay-to-Merkle-Root, or P2MR, from the earlier Pay-to-Tapscript-Hash. Authors are Hunter Beast, Ethan Heilman and Isabel Foxen Duke, created 18 December 2024. It defines SegWit version 2 with mainnet prefix bc1z, and is essentially P2TR with the quantum-vulnerable key-path spend removed, so new coins stop being at-rest exposed. The post-quantum signature schemes were split into a future BIP so P2MR can be debated without settling the algorithm argument. A first signet P2MR transaction was reported on 10 September 2025, and the BIP merged into the bitcoin/bips repository on 11 February 2026.

BIP-361, "Post Quantum Migration and Legacy Signature Sunset", is the contested one. Authors are Jameson Lopp, Christian Papathanasiou, Ian Smith, Joe Ross, Steve Vaile and Pierre-Luc Dallaire-Demers, created 11 February 2026, Draft, Informational. Phase A, at roughly 160,000 blocks — about three years — after activation, prohibits sending to quantum-vulnerable outputs. Phase B, two years later, tightens ECDSA and Schnorr spend rules, which effectively freezes whatever has not moved. Adam Back has pushed optional upgrades against the scheduled freeze, and critics call it confiscatory. Lopp's own framing: "I know folks don't like it. I don't like it myself. I wrote it because I like the alternative even less." He adds that it "isn't a spec, nor is it proposed for activation."

Both BIPs are Draft. Neither has a BIP-9 or BIP-8 activation mechanism, deployment parameters, or a Bitcoin Core merge. The reported 2026 merge dates refer to the documentation repository only. Nothing here is coming to Bitcoin on a schedule.

Ethereum's user-facing vehicle is EIP-8141, Frame Transaction↗, Draft since 29 January 2026, with authors including Vitalik Buterin, Felix Lange, Yoav Weiss and Toni Wahrstätter. It defines three verification schemes: ARBITRARY at 0x0, SECP256K1 at 0x1 with 65-byte signatures, P256 at 0x2 with 128-byte signatures. The spec says it "provides a native off-ramp from the elliptic curve based cryptographic system used to authenticate transactions today, to post-quantum (PQ) secure systems" — through the extensible scheme field. No post-quantum scheme is defined in it. EIP-8141 was moved to Scheduled for Inclusion for the Hegotá fork on the All Core Developers Execution call of 27 August 2026 and designated a must-ship proposal, but Hegotá follows Glamsterdam and is targeted for 2027 with no activation date set.

Ethereum's own current user advice is one line, and it is the right one: "Right now: nothing. Your funds are safe."

The Dormant Coin Problem Nobody Can Engineer Away

Roughly 1.7 million BTC in P2PK outputs have no plausible owner coming back to move them. Google estimates the full P2PK trove would be drained over months in Scenario 1 and years in Scenario 2. The options canvassed in the Bitcoin community:

• Do nothing. Property rights preserved. Accepts a supply shock when the coins start moving.
• Burn. Render dormant coins unspendable after a date. Expropriates anyone who missed the migration.
• Hourglass. Rate-limit dormant spends, one per block say, to smooth the shock. Invites bidding wars that route abandoned wealth to miners.

Google proposes a fourth, a "bad sidechain" using off-chain cryptographic ownership proofs, plus three policy paths: regulated digital salvage, a national security response, and engagement with the Bitcoin community. Its core argument should end the "just make it illegal" reflex: "Without protocol changes, laws criminalizing the taking of these coins merely ensure they are eventually taken by nefarious agents."

Harvest Now, Decrypt Later, and Where It Actually Applies

Executive Order 14412 of 22 June 2026 names the threat in its first section: adversaries "collecting United States information now, and decrypting it later once large-scale quantum computers are operational." That is a confidentiality argument, and correct for confidentiality.

It does not transfer to signatures. A quantum computer cannot retroactively forge a signature that was already verified and accepted. Authenticity risk starts at Q-day; confidentiality risk started whenever someone first recorded your ciphertext. That distinction tells you what to migrate first.

The data classes where harvest-now-decrypt-later genuinely bites are the ones whose secrecy has to outlive the machine: genomic and health records, defence and diplomatic traffic, long-retention financial records, source code and intellectual property. Ephemeral data is safe by construction — a session token is worthless to decrypt in 2035. Peter Gutmann of the University of Auckland is the sharpest published sceptic of blanket harvest-now framing, though I am working from secondary summaries rather than the original.

Blockchains are pure authenticity systems, so they should be a Q-day problem rather than a today problem. Bitcoin is the exception: its public keys are permanently published, so the 1.7 million BTC in P2PK outputs have been harvested since 2009 in every sense that matters. The attacker holds the target material and is waiting on the machine. It is the one place a signature scheme has a real harvest-now exposure, and the fix is the oldest one in the book — move the coins.

What a Team Should Do This Year

Not panic. The demonstrated state of the art is a 15-bit key. But "do nothing" is also wrong, because two of these are cheap and one is already late.

1. Inventory your cryptography. Where is secp256k1, where is BLS12-381, where is KZG, where is RSA, and what is the confidentiality lifetime of each thing they protect. Executive Order 14412 Section 5(d) directs CISA to publish minimum elements for a cryptographic bill of materials within 270 days, which tells you the format this is standardising on.
2. Migrate key establishment before signatures. Harvest-now hits confidentiality. If you run TLS termination or store long-lived encrypted records, hybrid post-quantum key agreement is available now and browsers already speak it.
3. Audit address types if you hold or custody Bitcoin. P2PK, P2MS and P2TR are at-rest exposed, and so is any reused P2PKH or P2WPKH address. Consolidating into fresh bc1q outputs with no reuse removes the at-rest class today, with no protocol change and no waiting.
4. Design for signature agility, not a specific algorithm. The EIP-8141 pattern — an extensible scheme field with no algorithm chosen — is the right shape for application code too. Wherever your protocol hardcodes a curve, put an identifier there instead: ordinary upgradeability discipline applied to cryptographic primitives.
5. Stop citing draft documents as settled deadlines. Check which deadline actually binds you. Executive Order 14412 sets 31 December 2030 for post-quantum key establishment and 31 December 2031 for post-quantum signatures on federal high-value assets and high-impact systems; most of the other dates in circulation come from drafts and vendor timelines, not from binding rules. I go through which documents actually bind whom in the migration guide.
6. Watch the two-qubit gate error rate and the magic-state rate, not the qubit count. Physical qubit headlines move 25x on assumptions. Those two numbers turn a blueprint into a machine.

If you are evaluating a chain marketed as post-quantum, I run that comparison in Quantum-Resistant Blockchains Compared and take one case apart in Quantus Network: What Actually Shipped. For a second pair of eyes on a protocol or custody stack, let's talk about your project.

Key Takeaways

• The demonstrated record is 15 bits, not 256. Project Eleven's Q-Day Prize went to Giancarlo Lelli on 24 April 2026 for a 15-bit curve, up from 6 bits in September 2025 — still 2^241 short of secp256k1.
• The two blueprints that state a logical qubit count agree, and they differ 25x on physical qubits. Roughly 1,200–1,457 logical for Google and IonQ; under 500,000 physical for Google at 10^-3 error against 19,397 for IonQ at 10^-4. The Oratomic and Caltech paper reports no logical count at all, and its 10,000-atom floor widens the physical spread to 50x.
• Circuit depth is the bigger gap. Blueprints call for 39–90 million Toffoli gates; public fault-tolerant demonstrations run handfuls of logical operations.
• About 6.9 million BTC sit in quantum-vulnerable scripts, per Google's March 2026 BigQuery analysis, roughly 1.7 million of it in P2PK — and rival counts disagree because none share a methodology.
• Taproot reversed a 2009 protection. P2TR writes the tweaked public key on chain in the clear and moved roughly 16.8 million BTC during 2025, 21.68% of that year's transactions. bc1q with no reuse is the at-rest-safe subset, not "any modern address".
• Ethereum's largest exposures cannot be fixed by users. 37 million ETH of stake behind BLS, 15 million ETH behind KZG, against an L1 target of 2029.
• Harvest-now-decrypt-later is a confidentiality problem, not a signature problem — except on Bitcoin, where public keys have sat on a permanent ledger since 2009.

About the Author

I'm Uvin Vindula — a Web3 and AI engineer based between Sri Lanka and the UK. I have shipped production smart contracts and I run Bitcoin education at uvin.lk, which is why I care that the quantum advice people repeat about address types is wrong for Taproot. You can see my work at iamuvin.com or reach out about a project at hello@iamuvin.com↗.

If you are auditing a custody stack or a protocol for quantum exposure, that work sits next to the security checklist I use on smart contracts.