Published on

Bitcoin's Quantum Clock Is Ticking

Authors

The Walls Are Closing In

Nine minutes. That's the figure coming out of Google's Quantum AI team — but before anyone runs for the exits, the number requires context. A lot of it.

The whitepaper published March 30–31 by Google Quantum AI, co-authored by Justin Drake of the Ethereum Foundation, Dan Boneh of Stanford, and six Google Quantum AI researchers led by Ryan Babbush and Hartmut Neven, models a specific type of attack against Bitcoin's elliptic curve cryptography. The researchers built two quantum circuits implementing Shor's algorithm for Bitcoin's secp256k1 curve. They then modeled what they call a "primed" attack: a quantum machine precomputes half of the key-derivation algorithm and sits in a ready state until a target transaction appears in the mempool. When it does, the machine completes the derivation in approximately nine minutes. Bitcoin's average block confirmation time is ten minutes. The overlap produces a roughly 41% probability that an attacker completes the key derivation and broadcasts a fraudulent replacement transaction before the original confirms.

These figures are conditional — not unconditional claims about what any quantum computer can do today. They rest on a superconducting quantum architecture operating at standard gate speeds and error rates, with surface-code overhead for fault tolerance, plus classical pre- and post-processing. With eleven such primed machines running in parallel, the speedup reaches 6.5×. Under conservative hardware parameters consistent with Google's existing processors, a single primed machine lands at that nine-minute window. The paper notes that more aggressive hardware assumptions could push required qubit counts below 100,000 — but those designs require qubit connectivity patterns not yet demonstrated in real devices. The point is not that the attack is imminent. The point is that the attack is now measurably closer to the ground than anyone thought.

Notably, Google did not publish the actual circuits. Instead, the team used a zero-knowledge proof — generated via the SP1 ZK virtual machine — to verify their claims without revealing the implementation details. It's the first time a ZK proof has been used to disclose a novel quantum cryptanalysis result. Google says it engaged with the U.S. government before publishing.

bitcoins quantum clock is ticking 1

The Numbers Got Worse

For years, the comfortable rebuttal to quantum doomsayers was simple arithmetic: breaking Bitcoin's elliptic curve cryptography (ECDSA) would require millions of physical qubits. Google's best chip, Willow, has 105. Sleep soundly.

That comfort is now considerably less comfortable — though the math deserves careful unpacking before anyone draws the wrong conclusions.

The new research demonstrates that the physical qubit requirement may be fewer than 500,000 — a roughly 20-fold reduction from prior estimates. Here it is worth pausing on a distinction the article cannot afford to blur: logical qubits and physical qubits are not the same thing, and conflating them produces a badly misleading picture.

The two circuits the researchers built use fewer than 1,200 logical qubits (90 million Toffoli gates) and fewer than 1,450 logical qubits (70 million Toffoli gates), respectively. Logical qubits are the error-corrected, usable units of computation. Physical qubits are the noisy raw hardware underneath them. The conversion between the two depends on the error correction scheme and target gate fidelity — and that overhead is substantial. On a superconducting architecture with standard surface-code assumptions, those 1,200–1,450 logical qubits translate to fewer than 500,000 physical qubits after error correction is applied. To be explicit: a 1,200-qubit device cannot break Bitcoin. A device with up to 500,000 physical qubits, operating under the paper's assumed error rates and connectivity, potentially could — under this model.

The previous state-of-the-art estimate, from a 2023 paper by Litinski, required roughly 9 million physical qubits — but that figure applied to a photonic architecture, not a superconducting one. Architecture matters enormously here: different hardware designs have different qubit connectivity, gate fidelity, and error correction costs. The Google team's reduction reflects a combination of algorithmic improvements to the circuit implementation of Shor's algorithm for the secp256k1 curve, more efficient use of Toffoli gates, and better modeling of surface-code overhead under realistic superconducting hardware assumptions. The sensitivity to hardware parameters is real: different gate fidelity assumptions move the number. But even under conservative parameters, the gap between "theoretical threat" and "operational threat" shrank by an order of magnitude. 1

Before anyone treats this as a tomorrow problem, a brief list of what still has to go right for an attacker: sufficient physical qubit count with the required connectivity topology, gate fidelities consistent with the paper's assumptions, fault-tolerant error correction at scale, and the classical-quantum orchestration required to run the full primed-attack pipeline. None of that exists today. Google's Willow chip has 105 qubits. The distance between 105 and 500,000 — with all the error correction overhead implied — is not a rounding error. But it is a distance that is now, demonstrably, shrinking.

The attack surface isn't small. Roughly 6.9 to 7 million BTC — valued at approximately $440 to $466 billion as of late March 2026 (Bitcoin was trading near $67,600 around the time of the source material; prices will have moved by the time you read this) — sits in wallets with permanently exposed public keys. That's approximately one-third of Bitcoin's total supply. Included in that figure: 1 million BTC attributed to Satoshi Nakamoto, worth roughly $67.6 billion at those prices, and 1.7 million BTC from early Pay-to-Public-Key (P2PK) addresses baked into Bitcoin's earliest blocks.

Taproot: The Upgrade That Backfired

Here's a development that nobody in the 2021 Taproot hype cycle seemed eager to discuss at length: Bitcoin's most celebrated recent upgrade may have expanded its quantum attack surface — though the mechanics deserve more precision than the usual hand-waving. 2

Taproot (BIP-340/341/342), activated in November 2021, introduced Schnorr signatures and a Merkleized script tree structure. A Taproot output (P2TR) encodes a 32-byte "tweaked" public key directly in the scriptPubKey. There are two spending paths: the key path (provide a valid Schnorr signature for the tweaked key) and the script path (reveal one branch of the Merkle tree and satisfy its conditions). The quantum vulnerability is specifically in the key path: the tweaked public key is visible on-chain from the moment the output is created, regardless of which spending path will eventually be used.

This is a meaningful distinction from legacy P2PKH addresses, which only reveal a hash of the public key until coins are actually spent. With P2PKH, a quantum attacker would need to observe the public key during the mempool window — roughly that ten-minute race condition — and move fast enough to front-run the transaction. That window is narrow and operationally demanding. P2TR key-path outputs change the calculus: the public key is exposed at output creation, not at spend time. An attacker can begin computing the private key the moment the output appears on-chain — potentially days, weeks, or years before the owner ever moves the funds. There is no mempool race required; the attacker simply works at their own pace. This "at-rest" attack category is generally considered more tractable than the on-spend variant, since it imposes no time pressure on the quantum machine.

Script-path spends are a partial exception worth noting. If a P2TR output is only ever spent via the script path, the internal key is not directly revealed in the spending transaction itself. However, the tweaked public key — which encodes information about the internal key — is still visible in the scriptPubKey from the moment the output is created. In practice, this distinction provides limited protection: the tweaked key is sufficient for a quantum attacker to derive the internal key, and therefore the private key.

What's worse, the architecture creates a paradox: you could theoretically write a perfectly quantum-resistant Dilithium signature check inside a Taproot script leaf and still be completely vulnerable, because a quantum attacker would simply bypass your carefully constructed script entirely and spend through the key path. A quantum-resistant script inside a quantum-vulnerable container. The BTQ project discovered this the hard way when implementing Dilithium opcodes in tapscript — a user could construct a P2TR output with a Dilithium script leaf and believe their funds were quantum-safe. They were not. 2

The proposed fix is BIP-360's Pay-to-Merkle-Root (P2MR) format, which removes the key path entirely — committing only to the Merkle root of a script tree with no public key exposed on-chain. It was merged into the official Bitcoin Improvement Proposal repository in February 2026. It has received, by most accounts, negligible developer consensus or coordinated implementation momentum.

The Governance Problem Nobody Wants to Solve

Google has set an internal 2029 deadline for migrating its own authentication services to post-quantum cryptography, citing progress in quantum hardware and error correction. The NSA's CNSA 2.0 framework calls for quantum-safe systems by 2030. Meanwhile, Bitcoin's response is best described as a committee that hasn't agreed on whether to form a committee.

Nic Carter, one of Bitcoin's most prominent advocates, said the quiet part out loud this week. He described Ethereum's approach as "best in class" — a coordinated, multi-team engineering effort spanning eight years, now formalized with the launch of pq.ethereum.org on March 25, weekly shipping devnets across 10+ client teams, and a detailed roadmap spanning four hard forks targeting full migration by 2029.

Bitcoin's approach, Carter said, was "worst in class." One proposal. Zero buy-in from top developers. No coherent strategy. No roadmap. Carter added, pointedly: "ETHBTC will start to reflect the divergence in prioritization." He was careful to note he wasn't saying this to wound anyone — he said it to spur action.

That critique deserves both weight and qualification. Carter is a Bitcoin advocate, not a detractor, and his criticism reflects genuine alarm rather than competitive point-scoring. But it should be noted that Bitcoin's developer community is not uniformly silent. Some developers have pointed to BIP-360 as evidence of forward motion. The "Hourglass" concept — which would gradually restrict the spendability of vulnerable coins unless migrated, giving owners time to act while reducing theft risk — is being actively debated. Coinbase has established an independent quantum advisory board comprising cryptographers and academics, signaling that quantum preparedness is becoming a business-critical concern. Charles Guillemet, CTO of Ledger, has publicly noted that the Bitcoin community already possesses the cryptographic tools required for a post-quantum migration and must act promptly. The debate is real and substantive.

The structural problem is that debate is not a roadmap, and Bitcoin's governance architecture makes the gap between the two unusually wide. There is no Ethereum Foundation equivalent — no central authority to set deadlines, no coordinated engineering team to execute them, and a governance culture that treats urgency with deep suspicion. The last major cryptographic upgrade — Taproot — took years of debate before activation. The quantum threat, by contrast, appears to be operating on a tighter schedule than Bitcoin's consensus process has historically accommodated.

The Philosophical Mess Nobody Asked For

Even if Bitcoin's developer community somehow coalesced around a migration plan tomorrow, there remains a genuinely thorny philosophical debate about what to do with the vulnerable coins that don't migrate in time.

The options are roughly as follows:

Option A: Freeze the coins. Render quantum-vulnerable outputs unspendable via soft fork unless migrated before a deadline. Jameson Lopp has argued this is not "confiscation" but rather "burning" — placing funds out of reach of everyone rather than allowing them to be swept by whoever first acquires quantum hardware. The counterargument is that this violates Bitcoin's foundational neutrality. As Nima Beni, founder of Bitlease, put it: "Bitcoin's structure treats all UTXOs equally." Creating exceptions, even for security reasons, changes that architecture permanently.

It's also worth being precise about what a "freeze" would actually require. This is not a policy switch. It would require a soft fork — meaning broad social consensus across a decentralized developer community that has historically moved slowly. The implementation risks are significant: chain splits if consensus is incomplete, legal challenges around property rights in jurisdictions that treat cryptocurrency as property, and the centralization pressure that comes from establishing any precedent for rendering coins unspendable. Georgii Verbitskii, founder of TYMIO, raised a relevant technical problem: the network has no reliable way to distinguish between coins that are genuinely lost and coins that are merely dormant. "From a protocol perspective, there is no reliable way to tell the difference," he noted. Freezing coins means potentially burning the savings of people who simply haven't moved their funds in years — an outcome that is hard to square with Bitcoin's property-rights ethos even if the security rationale is sound.

Option B: Let the code be law. Paolo Ardoino, CEO of Tether, has suggested that allowing old coins to re-enter circulation via quantum breakthroughs may be preferable to rewriting consensus rules. If cryptography evolves, coins move. The market absorbs it. The counterargument is that this amounts to the largest wealth redistribution in Bitcoin's history — handed to whoever first acquires a sufficiently powerful quantum machine. Lopp described such actors memorably: "Quantum miners don't trade anything. They are vampires feeding upon the system."

Option C: Voluntary migration with lead time. A third path — voluntary migration to quantum-resistant output types, with sufficient runway for owners to act — is theoretically available and is arguably what BIP-360 gestures toward. It avoids the coercive elements of Option A and the catastrophic wealth redistribution of Option B. The catch is that it requires the kind of coordinated, deadline-driven engineering effort and community-wide communication campaign that Bitcoin's governance structure has never been asked to produce at this pace. It also does nothing about genuinely lost coins or the Satoshi holdings, which will remain exposed regardless of what voluntary migration options exist.

Neither of the first two options is comfortable. The third is theoretically appealing but practically demanding. The Bitcoin community has not resolved this debate, and the clock on having to resolve it is running.

The Bull Case (Such As It Is)

To be fair — and I can manage fairness on a good day — not everyone is sounding the alarm at the same volume.

Ark Invest published a report arguing that quantum computing is a long-term consideration rather than an imminent crisis. Their logic: a breakthrough capable of threatening Bitcoin would likely disrupt broader internet security first, triggering coordinated global responses before Bitcoin-specific attacks become viable. They also estimate that the majority of Bitcoin's supply already sits in quantum-resistant addresses, and the remainder could be migrated given sufficient time.

CoinShares has noted that only about 10,200 BTC is concentrated enough in vulnerable legacy addresses to cause "appreciable market disruption" if stolen — the remaining exposed supply is scattered across 32,000+ wallets averaging about 50 BTC each, making them slow and unprofitable to crack individually.

These are not unreasonable points. The engineering gaps between "theoretically possible" and "operationally deployed" remain real, and the paper's own conservative estimates assume hardware parameters that don't yet exist at scale. To recap those gaps explicitly: no quantum computer today has anywhere near 500,000 physical qubits with the connectivity and gate fidelity the attack model requires. Error correction at the surface-code overhead levels assumed in the paper has not been demonstrated at scale. The classical-quantum orchestration pipeline for a primed attack adds further complexity. The distance between Google's 105-qubit Willow chip and a cryptographically relevant quantum computer is enormous — it has simply become less enormous than it was twelve months ago.

Justin Drake of the Ethereum Foundation, however, estimates at least a 10% probability of a cryptographically-relevant quantum computer by 2032 — a figure he says has risen "significantly" following Google's research. That's not a certainty. But 10% on an outcome with $466 billion in potential exposure is not the kind of number a prudent person dismisses over coffee.

bitcoins quantum clock is ticking 2

The Verdict

Google has set its deadline. Ethereum has its roadmap. The NSA has issued its guidance. And Bitcoin — the largest, most valuable, most ideologically rigid cryptocurrency in existence — has a merged proposal that nobody has agreed to implement, a philosophical debate that nobody has resolved, and a governance structure uniquely ill-suited to the kind of coordinated, deadline-driven engineering effort the situation demands.

Maybe Ark Invest is right and the timeline is long enough that Bitcoin's slow-moving consensus process will eventually produce something adequate. Maybe the quantum hardware trajectory stalls. Maybe the optimists collect their winnings.

Or maybe, nine minutes from now, someone somewhere is running a very different kind of algorithm.

Footnotes

  1. Securing Elliptic Curve Cryptocurrencies against Quantum Attacks — Google Quantum AI

  2. Why Taproot Is Quantum-Vulnerable — The Quantum Intelligencer 2