Google's Quantum Breakthrough: What New ECC Attack Estimates Mean for Blockchain and Beyond

Abstract

Key Points at a Glance

• ~10× spacetime-cost reduction: The paper's compiled circuits for the 256-bit ECDLP require roughly 1,200 logical qubits with 90M Toffoli gates, or 1,450 logical qubits with 70M Toffoli gates — an order-of-magnitude improvement over previous single-instance estimates.
• <500K physical qubits: Under standard superconducting-hardware assumptions (10⁻³ physical error rate, planar connectivity), the attack may be feasible with fewer than half a million physical qubits — far below widely cited "millions of qubits" figures.
• Zero-knowledge verification: The authors do not publish the attack circuits. Instead, they provide a ZK proof — via the SP1 virtual machine and Fiat–Shamir construction — supporting their claim that they possess size-bounded circuits for the key secp256k1 point-addition subroutine underlying their resource estimates.
• Three attack classes: The paper introduces a taxonomy of on-spend (mempool race), at-rest (dormant key recovery), and on-setup (one-time quantum → reusable classical exploit) attacks — each with distinct feasibility thresholds.
• On-spend attacks are plausible on fast-clock architectures: Precomputation reduces the relevant attack time to 9–12 minutes, overlapping with Bitcoin's 10-minute block interval.
• Ethereum's attack surface extends far beyond accounts: Admin keys, smart-contract logic, validator keys, and ZK-proof trusted setups create five distinct vulnerability categories.
• Dormant assets (~2.3M BTC) are a hard legacy problem: Successful forward migration does not protect coins whose owners are absent or whose keys are already lost, which is why the paper turns to governance and policy responses as well as technical ones.

1. The Headline Numbers — A 10× Cost Reduction

The central quantitative result concerns the circuit resources needed to run Shor's algorithm against the 256-bit ECDLP on secp256k1. The authors present two primary circuit variants, differing in their space–time trade-off:

These figures assume a superconducting architecture with physical error rates of 10⁻³, planar qubit connectivity, and a control-system reaction time of approximately 10 μs. The authors claim roughly a 10× improvement in overall spacetime cost compared to the best prior single-instance estimates for this problem.

To contextualise this: earlier widely-cited resource estimates for breaking ECC often quoted millions of physical qubits. The sub-500K figure significantly compresses the timeline implied by hardware roadmaps from IBM, Google, and other quantum computing companies. As we noted in our analysis of the harvest-now, decrypt-later (HNDL) threat, a 20× resource reduction for RSA-2048 was already demonstrated in early 2025. This paper extends the same downward pressure to ECC in the cryptocurrency setting. More broadly, it adds to the case that other security-critical systems built on ECDLP-based cryptography — including the X25519 key exchange widely used in TLS 1.3 — should not assume older resource estimates remain the right planning benchmark.

2. Verify Without Revealing — The Zero-Knowledge Approach

Perhaps the most methodologically unusual aspect of the paper is what it does not publish. The authors argue that the field has reached a maturity where publishing better cryptanalytic circuits creates tangible misuse risk. A complete circuit specification for the ECDLP on secp256k1 is, in effect, a blueprint for stealing cryptocurrency. They therefore withhold the circuits themselves.

This creates an obvious problem: how can the community evaluate claims it cannot inspect? The paper's answer is a zero-knowledge proof (ZKP) that supports the resource estimates without revealing the underlying circuits, though the proof is narrower than a full disclosure of an end-to-end attack implementation. The construction works as follows:

This construction does not constitute a full mathematical proof that the authors have published a complete end-to-end ECDLP attack circuit. Instead, it provides narrower evidence about the correctness of the point-addition subroutine on sampled inputs — a meaningful credibility boost, though not the same as full public circuit disclosure. However, it raises the credibility threshold substantially above a bare assertion. The approach is also significant as a precedent: it establishes a model for responsible disclosure in quantum cryptanalysis, analogous to coordinated vulnerability disclosure in software security.

For practitioners, the key takeaway is pragmatic: treat these estimates as credible lower bounds. Even if the exact circuits require further refinement, the direction of travel is unambiguous — the cost of attacking ECC is falling, and it is falling faster than many public roadmaps assumed.

3. Three Kinds of Quantum Attack on Blockchains

One of the paper's most useful contributions is a structured taxonomy of quantum attacks against blockchain systems. Rather than treating "quantum breaks crypto" as a monolithic event, the authors identify three operationally distinct attack classes, each with different timing requirements, capability thresholds, and mitigation profiles:

This taxonomy matters because it breaks the simplistic narrative that "quantum will break everything at once." In reality, the three attack classes will become feasible at different points on different hardware platforms. As we explored in our analysis of Bitcoin's quantum vulnerability, the at-rest attack is the most forgiving for the attacker — exposed keys from 2009 P2PK addresses can be targeted without any time pressure. The on-spend attack, by contrast, requires not just a sufficiently large quantum computer but a sufficiently fast one.

The on-setup attack is perhaps the category with the most severe long-term consequences. If a quantum attacker recovers the toxic-waste parameters from a ZK-proof trusted setup, they obtain the ability to forge proofs indefinitely using only classical computation. This converts a single quantum computation into a permanent backdoor — an asymmetry that substantially amplifies the threat.

4. Fast Clock vs. Slow Clock — When Timing Changes Everything

The paper introduces a crucial architectural distinction that determines which attacks become feasible first. Quantum hardware platforms differ dramatically in their native gate speeds and error-correction cycle times:

The distinction is consequential. On a fast-clock superconducting machine, the full ECDLP attack completes in 18–23 minutes. But the authors demonstrate that an attacker can precompute approximately the first half of the attack, since that portion depends only on shared protocol parameters (the curve generator point, field modulus, etc.) rather than the victim's specific public key. Once the target's public key appears in the mempool, the attacker resumes from this primed state, reducing the relevant response time to approximately 9–12 minutes.

For slow-clock architectures (neutral atoms, ion traps), the ECDLP computation would take substantially longer due to slower error-correction cycles. These platforms would likely enable at-rest attacks first — recovering private keys from long-exposed public keys over a period of days. On-spend mempool races would remain impractical until clock speeds improve or parallelism compensates. This means the order in which attacks become feasible depends on which hardware platform matures first — a variable that is increasingly difficult to predict as multiple architectures advance simultaneously.

The timing analysis also has direct implications for our earlier discussion of TLS 1.3 quantum vulnerabilities. The same precomputation technique applies to any protocol where the victim's ephemeral ECDH public key is transmitted before session establishment completes — making the window for harvest-now, decrypt-later attacks even narrower than a static analysis of qubit counts would suggest.

5. Beyond Bitcoin — Ethereum's Expanded Attack Surface

While Bitcoin's quantum risk centres primarily on signature forgery and exposed keys, Ethereum presents a substantially broader attack surface. The paper organises Ethereum-specific vulnerabilities into five categories, each exploiting different layers of the platform's cryptographic and governance infrastructure:

The admin vulnerability category deserves particular attention. Many high-value Ethereum smart contracts — DeFi protocols, bridges, treasuries, token systems — depend on administrator keys for upgrades and governance. These keys are often standard EOAs. Compromising an admin key does not merely steal one account's funds; it can alter the logic of the entire contract system, potentially affecting millions of users. This is qualitatively different from Bitcoin's key-exposure problem and represents a systemic risk amplifier.

The code vulnerability category connects directly to the paper's on-setup attack class. Protocols that embed ECC-based assumptions in application logic — privacy systems like Tornado Cash, cross-chain bridges, or advanced cryptographic constructions — can be attacked once with a quantum computer to produce classical exploits that remain effective indefinitely. The quantum computer becomes a one-time key that unlocks a permanent backdoor. This is one of the paper's most important observations, and it underscores a point we made in our discussion of key exchange vs. digital signatures: the distinction between ephemeral key agreement and long-lived cryptographic commitments has profound security implications in a post-quantum world.

6. The Dormant Asset Problem That Forward Migration Alone Cannot Fix

Our previous analysis of Bitcoin's quantum vulnerability covered the "Lost Coins Dilemma" — Satoshi's estimated 1.1 million BTC on exposed P2PK addresses. The Google paper extends this analysis and arrives at a starker conclusion: dormant vulnerable assets constitute a fixed future target that protocol-level migration, by itself, cannot address.

The numbers are significant: over 1.7 million BTC are locked in P2PK outputs where the public key is visible on-chain from creation. Including reused addresses and other exposed key types, the total vulnerable dormant pool may reach approximately 2.3 million BTC. Because many of the original owners are absent, deceased, or have lost access, voluntary migration to quantum-safe addresses may be impossible for a large share of this class of assets.

The paper outlines four broad community responses under discussion:

1. Do nothing: Accept that these coins will eventually be claimable by whoever achieves quantum capability first.
2. Burn: Render vulnerable dormant coins unspendable via a protocol-level change — effectively destroying potentially billions of dollars in value.
3. Hourglass recovery: Implement a time-delayed recovery mechanism that allows owners to prove ownership through non-quantum-vulnerable means (e.g., hash-based challenges) before the quantum deadline.
4. "Bad sidechain": Route recovered assets through a dedicated sidechain that attempts to identify rightful owners using off-chain proofs — mnemonic phrases, notarized records, identity registries. The "bad sidechain" analogy borrows from the "bad bank" concept used to manage distressed financial assets.

The paper's policy discussion — unusual for a cryptography paper — proposes "digital salvage" as a regulatory framework: the recovery of dormant quantum-vulnerable assets would be treated as a regulated activity, analogous to maritime salvage law. This reflects the authors' recognition that technical fixes cannot address the full scope of the problem; legal and governance frameworks must co-evolve with the cryptographic transition.

7. What This Means for Your Post-Quantum Roadmap

The practical implications of this paper are most immediate for the blockchain community, but they also matter more broadly for systems that still rely on ECDLP security — including TLS key exchange, code signing, IoT device authentication, and public-key infrastructure (PKI). Here is how the paper's findings, together with the broader conclusions we draw from them, connect to the migration strategies we have covered across our publication series:

Hybrid key exchange is the immediate defence. Strictly speaking, the paper does not directly analyze hybrid deployment in TLS. But its lower attack-cost estimates reinforce the urgency of deploying hybrid X25519 + ML-KEM-768 key exchange in TLS and other protocols. Hybrid mode ensures that even if ECC falls sooner than expected, the lattice-based component maintains confidentiality. BSI and NIST both recommend this approach, as we detailed in our BSI compliance analysis.

Signatures must transition too. That specific recommendation goes beyond the paper's cryptocurrency focus, but it follows naturally from the same pressure on elliptic-curve assumptions. Key exchange protects future confidentiality, but digital signatures protect authenticity and integrity. Code signing, firmware updates, and software supply chains all depend on ECC signatures today. Our analysis of post-quantum code signing outlines the migration path for this critical use case.

Constrained devices cannot wait. This is a broader PQC planning conclusion rather than a direct claim of the paper, but it is a reasonable one: IoT and embedded systems have the longest upgrade cycles and the most restrictive resource constraints. As we explored in our PQC in IoT analysis, devices deployed today with 10–15 year lifespans will operate well into the period where these attacks may become practical. Firmware update mechanisms and crypto-agility must be engineered in now.

SMBs need a structured migration roadmap. Again, this is our broader implementation takeaway rather than the paper's direct recommendation. For small and medium businesses that lack dedicated cryptographic expertise, our PQC SMB roadmap provides a phased approach: inventory → prioritise → pilot → deploy. The compressed timeline implied by this paper means the inventory phase should begin immediately.

PQC is the pragmatic choice; QKD is a complement, not a substitute. The paper itself is about post-quantum migration in cryptocurrencies, not a direct PQC-versus-Quantum Key Distribution (QKD) comparison. But as we argued in our PQC vs. QKD comparison, post-quantum cryptographic algorithms provide software-deployable, internet-scale protection. QKD offers specialised advantages for specific high-value links but cannot replace the need for algorithmic migration.

The paper's closing message aligns with the consistent theme across our real-world PQC deployment analysis: the quantum threat to elliptic-curve cryptography is no longer a theoretical abstraction to be addressed "someday." It is a concrete engineering and governance challenge with quantifiable parameters, hardware-dependent timelines, and asymmetric consequences for those who act late. A prudent assumption is that capability may arrive with less warning and less public visibility than many observers expect. The time to prepare is now.

Further Reading

For a detailed walkthrough of how hybrid post-quantum key exchange works in practice — including the algorithms, the TLS handshake changes, and who is already shipping it — see our technical briefing:

References

1. Google Quantum AI. (2026). Securing Elliptic Curve Cryptocurrencies against Quantum Vulnerabilities: Resource Estimates and Mitigations. https://quantumai.google/static/site-assets/downloads/cryptocurrency-whitepaper.pdf