You Cannot Classify Your Way Out of an Algorithm

On March 30, 2026, Google Quantum AI published "Securing Elliptic Curve Cryptocurrencies against Quantum Vulnerabilities: Resource Estimates and Mitigations." Most of the coverage that followed fixed on one number: nine minutes to derive a Bitcoin private key. That number is real, and it matters. It is not the most important thing in the paper for anyone who builds or defends systems.

The most important thing is what happened to the disclosure in the eleven weeks after it shipped. Google followed a recognizable responsible-disclosure playbook. It withheld the attack circuits, substantiated the claim with a zero-knowledge proof, and engaged the U.S. government before publishing. Within two months, an independent researcher had rediscovered the withheld optimization, the author who had self-censored confirmed he had been sitting on it, an open challenge had already improved on the result, and a security firm had forged the proof itself by attacking its software rather than its math. As harm reduction, that playbook worked. As containment, it did not. The cryptography held, the secret did not, and the proof inherited an attack surface the moment it was written in code. That gap is the lesson.

This paper states the result precisely, separates what is actually vulnerable from what is not, and gives an honest read on the timeline. Its real subject is the disclosure itself: a case study in what happens when cryptanalysis, disclosure policy, public incentives, and software assurance collide in a single artifact, and why that collision, rather than the nine-minute number, is the part security architects should study hardest.

1. The result, stated precisely

Google compiled two quantum circuits implementing Shor's algorithm against the 256-bit elliptic curve discrete logarithm problem (ECDLP-256) on secp256k1, the curve behind Bitcoin and Ethereum signatures:

• one circuit using no more than 1,200 logical qubits and 90 million Toffoli gates
• one circuit using no more than 1,450 logical qubits and 70 million Toffoli gates

Compiled onto a superconducting surface-code architecture with a 10⁻³ physical error rate and planar degree-four connectivity, these circuits require fewer than 500,000 physical qubits. That is roughly a 20-fold reduction in physical qubits over the prior best single-instance estimate (Litinski, 2023, about 9 million physical qubits), and roughly an order-of-magnitude reduction in spacetime volume.

The runtime depends on priming. The raw variants run in about 23 and 18 minutes. Precomputing the first half of the algorithm, which depends only on fixed curve parameters, roughly halves that, bringing the 70-million-gate variant to about 9 minutes. Because Bitcoin's average block time is 10 minutes, the paper estimates approximately a 41% probability that a primed fast-clock machine could derive a key and submit a competing transaction inside the confirmation window. That nine-minute figure is a boundary condition under favorable assumptions stacked together (fast-clock hardware, priming, an already-exposed public key, and cooperative mempool timing), not a forecast and not a planning baseline.

Two things the paper did not claim are as important as the numbers. It did not claim a quantum computer capable of this exists. The most advanced processor in production, Google's Willow, has 105 physical qubits. And it did not publish the circuits. It published a zero-knowledge proof built on the SP1 zkVM and a Groth16 SNARK, attesting that a circuit meeting the stated resource bounds correctly performs secp256k1 point addition across roughly 9,000 random inputs, without revealing the circuit.

Translation discipline for non-specialists. When a reader hears "1,200 qubits to break Bitcoin" and looks at a 1,000-qubit processor, the instinct is that we are close. We are not. Those are noisy physical qubits. The 1,200 figure is logical, error-corrected qubits, and each one costs hundreds of physical qubits under sustained fault tolerance. The honest framing is the height of a ladder nobody has built yet.

2. What is actually vulnerable, and what is not

For many blockchain systems, "harvest now, decrypt later" is an imperfect metaphor. Many of the relevant public keys are already public, or become public the moment an address is spent from. For those keys there is no traffic to collect and store: the input to an at-rest attack has been sitting in the open for years. The harvest step, where it applies at all, is trivial.

Exposed today (at-rest): Bitcoin pay-to-public-key (P2PK) outputs, Taproot (P2TR), and any address that has been reused, since reuse exposes the key on first spend. Estimates for vulnerable Bitcoin run to several million BTC, on the order of a third of supply, including a large tranche of early P2PK coins, Satoshi-era among them, that have never moved and so can never be migrated by anyone. On Ethereum, any account that has ever sent a transaction has exposed its key, and the consensus and data-availability layers rely on BLS signatures and KZG commitments that are quantum-vulnerable.

Exposed only to fast machines (on-spend): Live transactions in the public mempool. The paper's fast-clock versus slow-clock distinction is the operational heart of this. Superconducting, photonic, and silicon-spin systems have short error-correction cycles, around a microsecond, and could plausibly finish inside a block time. Neutral-atom and ion-trap systems run two to three orders of magnitude slower and would be capable of at-rest attacks long before they could touch a live transaction.

Not vulnerable in this threat model: Proof-of-work mining (it relies on hash preimage resistance, not ECDLP). Addresses that have never spent and remain hidden behind a hash. Chains that have already moved to post-quantum signatures.

3. The honest timeline

This is where most commentary, including an earlier draft of my own thinking, leaned harder than the evidence supports.

No cryptographically relevant quantum computer exists. The gap from 105 physical qubits to roughly 500,000 fault-tolerant physical qubits is measured in sustained engineering breakthroughs across qubit quality, error correction, thermal management, and scale. Those are years, not months.

The most useful calibration comes from one of the paper's co-authors, and it is worth noting both that his estimate moved and that he is not a neutral party. In his March 31 thread reacting to the paper, Justin Drake, an Ethereum Foundation researcher, put the odds of a quantum computer recovering a secp256k1 private key from an exposed public key at 10% or higher by 2032, and called a CRQC before 2030 still unlikely. In a follow-up thread on June 2, after the independent rediscovery and the open-challenge gains described in the next section, he raised those figures to a 10% probability by 2030 and a 50% probability by 2032, and called the U.S. government's 2035 NIST and NSA migration timeline outdated. These are his personal estimates, and as both a co-author and an Ethereum researcher he has a direct stake in migration urgency, so they are useful color rather than consensus. Both the Google paper and the parallel neutral-atom paper deliberately avoided naming a Q-Day. Google's own internal post-quantum migration deadline is 2029. NIST, CISA, and the FBI flagged 2026 as a year to take quantum security seriously.

The threat is also not gated on a single hardware bet, though the alternatives are slower than the headlines suggest. A parallel preprint from Oratomic, Caltech, and UC Berkeley (Cain et al., arXiv:2603.28627, March 31, 2026) reuses Google's circuits on neutral-atom hardware and shows that as few as roughly 10,000 reconfigurable atomic qubits could run the attack, with a 26,000-qubit configuration bringing the discrete-log runtime on the P-256 curve down to a few days. Those are day-scale, at-rest computations under assumptions the authors are still refining in public, on hardware not yet demonstrated at this scale, not a faster route to a minutes-scale on-spend attack. The narrow planning point is only this: at-rest exposure does not depend on superconducting qubits specifically.

So the responsible read is not "Q-Day is 2028." It is narrower and more useful. The resource estimate dropped about 20x, which removes the comfort of treating post-quantum migration as a problem for the 2030s and replaces it with a planning horizon that now overlaps the working lifetime of systems being deployed today. The direction is settled. The date is probabilistic, and the people closest to the work are saying so out loud.

One caveat in the paper deserves to travel with every timeline estimate. The challenge ladder that planners use, watching for a 32-bit ECDLP demonstration before worrying about 256-bit, may not give the warning everyone assumes. If a leading architecture clears its scaling barriers, the jump from breaking a small curve to breaking secp256k1 could arrive with little runway. A public demonstration of Shor on a 32-bit curve should be read as a sign that migration has already failed, not as the starting gun.

4. The disclosure was the experiment

Here is the part that should interest anyone whose job is the gap between a claim and a deployed system.

Google's disclosure strategy was among the most careful the field has produced. The argument behind it is sound: as resource estimates shrink toward feasible hardware, publishing the exact circuit starts to look like handing out a blueprint. The zero-knowledge proof was meant to let the world verify the scale of the threat without leaking the method.

What followed was not one failure but three different kinds of pressure on the disclosure, and collapsing them into a single "containment failure" is too clean. They are a knowledge-control event, an incentive-design event, and a software-assurance event. None was a quantum breakthrough. The point is precisely that they are not the same failure. Once a result this important enters the world as a verifiable software artifact, the risk stops being a single thing to classify and moves across disciplines.

Knowledge-control event: independent rediscovery. On June 1, 2026, about nine weeks after the paper, André Schrottenloher (Univ Rennes, Inria) published "Optimized Point Addition Circuits for Elliptic Curve Discrete Logarithms" (arXiv:2606.02235, IACR ePrint 2026/1128), independently reconstructing the withheld optimization. For secp256k1 his circuit lands within about 1.5% more qubits and 6.5% to 10% fewer Toffoli gates than Google's. He matched the result the zero-knowledge proof was protecting, in the open, as a single researcher, missing only a few of Google's minor refinements. Craig Gidney, the Google researcher behind the RSA-2048 estimates, then said publicly that he no longer thinks the zero-knowledge approach was the right call, that its benefits were negligible and its costs many. When a co-author of the disclosure says the secrecy was not worth it, the case that classification bought delay rather than secrecy is not coming from a critic on the outside.

Incentive-design event: open improvement. An open "Shor-at-home" challenge at ecdsa.fail, run by Eigen Labs, reuses the project's own zero-knowledge verifier as an automatic filter for valid submissions, with the metric set as logical qubit count times Toffoli gate count against the Litinski baseline. By Drake's June 2 post, submissions had improved on Google's circuit by 8.4%. The contributor pool by then included experts, amateurs, a teenager, and AI-assisted "autoresearch" attempts by non-experts. That last detail matters because of a rumor worth killing before it reaches a conference hallway: the widely repeated claim that language models re-derived the result in two days and then beat Google by 44% in fifteen days has no primary source and contradicts the documented 8.4% figure. Drake's own March 31 thread stated that AI had not yet been tasked at all. The honest version is more modest and more interesting. The same artifact built to prove the result without leaking it became the scoring function for beating it, and the people and tools chipping away at it are exactly who you would expect once a verifiable scoreboard exists.

Software-assurance event: breaking the proof, not the math. On April 17, Trail of Bits (Keegan Ryan) published a forged proof that beat Google on all three reported metrics: 8,288,880 operations, 1,164 qubits, and zero reported Toffoli gates, against Google's best variant of 1,175 qubits and roughly 2.1 million Toffolis. No quantum circuit was improved. The forgery exploited two flaws in Google's Rust prover: an out-of-range operation type that jumps past the Toffoli counter (the bounds check had been disabled with an unchecked deserialization to save proving cost), and register aliasing that let a qubit be reset to zero in violation of reversibility. The forged proof verified cleanly against Google's unpatched verifier and was cryptographically indistinguishable from a proof of a genuine algorithmic breakthrough. The honest reading cuts both ways. Releasing the verifier publicly is exactly what let the bugs be found and fixed before any hardware exists; Google patched the prover in version 2 of the paper, and the scientific claims stand. That is the resilience side, and it is real. It does not erase the structural point. The verification artifact became part of the attack surface. As Trail of Bits put it, a zero-knowledge system does not remove the trust problem, it relocates it, from the opinions of scientific experts onto compilers, languages, and proof systems. A verifier that trusts a buggy prover will attest to things that are not true.

There is a charitable reading worth stating in full, because it is partly right. In it, the disclosure did not fail at all. Google avoided being the first to publish a working circuit, bought the field weeks to months, forced the migration conversation into the open, and exposed the proof artifact to scrutiny while the hardware that would weaponize it still does not exist. Independent rediscovery was inevitable and scientifically healthy. The open challenge improved defensive understanding. Trail of Bits found and helped fix software flaws without touching the result. Read that way, this is responsible disclosure working in a field where permanent secrecy was never on the table. That reading is correct about harm reduction, and I am not waving it away. It is incomplete about containment. The narrower claim survives it: classifying an important result buys delay rather than secrecy, verification turns into infrastructure, and any artifact used to substantiate the claim becomes part of the system under attack.

Put the three together and the integration view is hard to miss. The cryptanalysis, the disclosure policy, the open-challenge incentive structure, and the prover's memory safety are not four separate stories. They are one system that failed and held in different places, for reasons drawn from different disciplines. That is the part of this episode that generalizes far beyond quantum.

This is also where the title has to earn its keep, and where it has to be careful. Independent rediscovery is the historical norm in cryptanalysis, not a surprise. Differential cryptanalysis was known inside IBM and the U.S. government in the mid-1970s and stayed quiet until Biham and Shamir rediscovered and published it around 1990. Public-key cryptography was worked out at GCHQ years before Diffie, Hellman, Rivest, Shamir, and Adleman reached it in the open. In those cases secrecy held for fifteen to twenty-five years, so classification plainly can buy time. Here it held for nine weeks. The difference is the mechanism worth carrying into any disclosure decision. Google published a verifiable, scored target, and a verifiable target turns rediscovery into a well-posed optimization problem with a public scoreboard. The disclosure created the competition that defeated the secrecy. That is the precise version of the claim, and it is sturdier than the slogan: you cannot classify your way out of an algorithm once you have also published the means to check the answer.

5. What this means for architects

The migration problem is older and more boring than the quantum result, and it is where the real work lives. You cannot migrate what you have not inventoried, and most organizations cannot answer where their cryptography lives, what curve it depends on, or who owns the decision to change it. A scanner reporting TLS 1.3 tells you what was negotiated, not what the configuration actually enforces, and that gap is the real surface.

For enterprises:

1. Build a cryptographic inventory before designing a migration. Name an owner for it. Treat "we do not know" as a finding, not a delay.
2. Design for crypto-agility, so that the next algorithm change is a configuration event rather than a re-architecture. The first migration is one-time. The capacity to keep migrating is the actual deliverable.
3. Start the simpler at-rest mitigations now, in parallel with planning, rather than waiting for a complete solution.

For protocol and platform teams: the lesson is migration governance, not individual wallet hygiene. Address reuse, legacy P2PK outputs, Taproot exposure, Ethereum account history, BLS signatures, and KZG commitments all illustrate one architectural problem: once public-key exposure is embedded in system history, migration becomes a coordination problem rather than a patch. Some holders can move their value; dormant or abandoned exposed value cannot be migrated by anyone, which is a permanent structural exposure rather than a bug to be fixed. That is why post-quantum planning belongs in protocol governance now, not after a public small-curve demonstration forces the question.

For researchers and disclosure teams publishing high-impact cryptographic claims, the disclosure story turns into a checklist of its own. The point is not that Google was wrong to withhold the circuit or to reach for a zero-knowledge proof. The reasoning behind both was sound, and a co-author has since said the secrecy was not worth its cost, which is the field correcting itself in the open. The point is that a verifiable claim expressed as software is a system, and a system needs software assurance and an eventual-disclosure plan, not only peer review of the mathematics.

1. Treat the proof system, verifier, benchmark harness, and any challenge infrastructure as production attack surface, not as documentation. The Trail of Bits result is the proof of concept.
2. Threat-model not only misuse of the result but the optimization pressure that forms around the artifact once it can be scored.
3. Separate "verifiable without disclosure" from "safe to operationalize as a public scoreboard." They are different decisions with different blast radii.
4. Require software assurance on the proof path itself, including memory safety and deserialization handling, rather than relying on peer review of the math to cover the code. Borrow the embargo discipline from coordinated vulnerability disclosure: a verifiable claim is not a substitute for an eventual, patchable release.

Bottom line

The nine-minute number is a headline. The durable findings are that breaking ECDLP-256 now looks about 20x cheaper than it did, that the threat is real and the hardware to realize it does not exist, that one co-author, an Ethereum Foundation researcher with a stake in the answer, now publicly prices a break at 10% by 2030 and 50% by 2032 (up from 10% by 2032 eleven weeks earlier), and that a careful responsible-disclosure effort reduced harm but did not contain the result. Within weeks it was independently rediscovered, improved on an open scoreboard, and its proof was forged through a software bug. For a security architect, the quantum number sets the deadline and the disclosure story sets the lesson. You cannot classify your way out of an algorithm, and the moment you express a cryptographic claim as code, you own a software problem too.

References

1. Babbush, Gidney, Zalcman, Broughton, Khattar, Neven, Bergamaschi, Drake, Boneh. "Securing Elliptic Curve Cryptocurrencies against Quantum Vulnerabilities: Resource Estimates and Mitigations." Google Quantum AI, March 30, 2026. arXiv:2603.28846 (patched proof in v2). Whitepaper PDF: https://quantumai.google/static/site-assets/downloads/cryptocurrency-whitepaper.pdf. ECDLP-256 estimates, ZK proof (SP1 zkVM + Groth16), on-spend 41% figure, fast/slow-clock distinction.
2. Google Research blog. "Safeguarding cryptocurrency by disclosing quantum vulnerabilities responsibly." March 31, 2026. https://research.google/blog/safeguarding-cryptocurrency-by-disclosing-quantum-vulnerabilities-responsibly/. U.S. government engagement; PQC recommendations.
3. Schrottenloher, André (Univ Rennes, Inria, CNRS, IRISA). "Optimized Point Addition Circuits for Elliptic Curve Discrete Logarithms." June 1, 2026. arXiv:2606.02235 [quant-ph]; IACR ePrint 2026/1128 (https://eprint.iacr.org/2026/1128). Abstract states roughly 1.5% more qubits and 6.5–10% fewer Toffoli gates than Babbush et al. for secp256k1.
4. Trail of Bits (Keegan Ryan). "We beat Google's zero-knowledge proof of quantum cryptanalysis." April 17, 2026. https://blog.trailofbits.com/2026/04/17/we-beat-googles-zero-knowledge-proof-of-quantum-cryptanalysis/. Forged proof (8,288,880 ops, 1,164 qubits, 0 reported Toffolis); two prover bugs; Google patched in 2603.28846v2. PoC code: https://github.com/trailofbits/quantum-zk-proof-poc
5. Drake, Justin (@drakefjustin). X thread, June 2, 2026 (https://x.com/drakefjustin/status/2061793725299224676): updated personal Q-Day estimate to 10% by 2030 and 50% by 2032; ecdsa.fail at 8.4% improvement; calls the 2035 U.S. timeline outdated. Earlier thread, March 31, 2026 (https://x.com/drakefjustin/status/2038847732152996108): ≥10% by 2032, and "AI was not (yet) tasked." Secondary write-up: The Crypto Times, June 2, 2026.
6. Cain, Xu, King, Picard, Levine, Endres, Preskill, Huang, Bluvstein (Oratomic, Caltech, UC Berkeley). "Shor's algorithm is possible with as few as 10,000 reconfigurable atomic qubits." arXiv:2603.28627 [quant-ph], March 31, 2026. Reuses Google's circuits on neutral-atom hardware; as few as ~10,000 atomic qubits, with ~26,000 qubits giving a few-day runtime for P-256 discrete logs; assumes error rates and connectivity not yet demonstrated at scale.
7. Fireblocks, "What Google's New Quantum Research Means for Institutional Crypto Security," April 1, 2026; The Quantum Insider, March 31, 2026; Quantum Computing Report, April 4, 2026. (Corroborating coverage for resource estimates, the several-million-BTC exposure figures, the Oratomic timing context, and the hardware-gap framing.)
8. Gidney, Craig (Google Quantum AI), public statement on the zero-knowledge disclosure strategy ("the benefits are negligible, and the costs are many"), quoted by Frédéric Jacobs, June 1, 2026 (https://mastodon.social/@fj/116679394830680442); ecdsa.fail challenge run by Eigen Labs (https://ecdsa.fail). Schrottenloher implementation: Inria GitLab, gitlab.inria.fr/capsule/qarton-projects/ec-point-addition.
9. Chevignard, Fouque, Schrottenloher. "Reducing the Number of Qubits in Quantum Discrete Logarithms on Elliptic Curves." EUROCRYPT 2026 (IACR ePrint 2026/280). Prior width-optimized ECDLP work, ~1,193 logical qubits at high gate count; predates and is distinct from the June 2026 Schrottenloher rediscovery in ref. 3.

Note on sourcing: the four primary assertions (Google resource estimates, the Trail of Bits proof break, the Schrottenloher rediscovery, and Drake's probability and timeline claims) are cited above to primary sources with identifiers. The "AI improved the result 44% in 15 days" claim circulating on some aggregator sites has no primary source and is contradicted by the documented 8.4% figure and by the paper's co-author; it has been deliberately excluded.