You’ve seen the headlines. Google says a quantum computer could crack a Bitcoin private key in 9 minutes. Most of the coverage has been an alarm. This is the explanation.
On March 31st, Google Quantum AI published a paper co-authored with Justin Drake of the Ethereum Foundation and Dan Boneh of Stanford. The same day, Caltech and Oratomic published a second paper showing the hardware is much closer than anyone assumed. Together, they put specific numbers behind a threat that the crypto world has been hand-waving about for years.
Here’s what the papers actually found, how much is at stake, and what the timeline looks like now.
The 9-Minute Attack
Every crypto wallet relies on a pair of keys. Your public key is like your address: it’s how the network identifies your account. Your private key is the password that controls your funds. The entire security model rests on a simple assumption: that nobody can work backward from the public key to derive the private key. Today’s computers can’t. A quantum computer running Shor’s algorithm could.
The headline finding from the Google paper: on a fast-clock quantum architecture (superconducting qubits), that derivation takes 9 to 12 minutes.
Think about what that means in practice. When you send crypto, the network briefly exposes your public key during the transaction. Normally, that’s fine because reversing the key is computationally impossible. But a sufficiently powerful quantum computer could see your public key, derive your private key, and redirect your funds before the network confirms the block. Google’s team calls this an “on-spend attack,” and 9 to 12 minutes falls within the confirmation window of most major blockchains.
Previous estimates put the hardware requirement for this kind of attack in the millions of physical qubits, which made it feel safely distant. The Google paper cut that number to fewer than 500,000 physical qubits (roughly 1,200 logical qubits and 90 million Toffoli gates). That’s a 20x reduction.
Two Types of Attacks
The paper distinguishes between two scenarios, and the difference matters for how you assess your exposure.
On-spend attacks target transactions in flight. Your public key is briefly visible between broadcast and confirmation. On fast-clock quantum systems, the attacker can race the block clock and win. On slower architectures (neutral atom, ion trap), the math doesn’t work within block times, so on-spend attacks aren’t practical on those platforms yet.
At-rest attacks target funds sitting in wallets where the public key is already visible on the blockchain. Some older address formats (called P2PK) store the public key permanently. Reusing an address exposes it too, because the public key becomes visible the first time you send funds from that address. And Taproot (P2TR), Bitcoin’s newest format adopted in 2021, also exposes the public key by default. For all of these, the attack takes 18 to 23 minutes on fast-clock systems, but there’s no clock to race. The attacker has all the time they need.
The at-rest category is where the scale of exposure gets serious.
What’s Actually Exposed
The Google team quantified the vulnerable surface across both major chains.
Bitcoin: 6.9 million BTC sit in addresses where the public key is already visible. That includes the Satoshi-era P2PK outputs, reused addresses, and Taproot. The paper calls Taproot a quantum regression: a 2021 upgrade intended to improve privacy and efficiency that inadvertently made the quantum problem worse by exposing public keys that newer address formats had previously kept hidden.
Ethereum: Approximately 20.5 million ETH sits in accounts with exposed public keys. The paper estimates the top 1,000 vulnerable Ethereum accounts could be cracked in under 15 hours.
The Citi Institute’s January 2026 report, co-authored by QuSecure’s Rebecca Krauthamer and Garrison Buss, put a dollar figure on Bitcoin’s exposure specifically: roughly 25% of all BTC, approximately $500 to $600 billion at current prices, is potentially quantum-exposed.
How Much Closer Is the Hardware?
This is where the Caltech paper comes in. Published the same day, it shows that Shor’s algorithm (the quantum algorithm that breaks public-key cryptography) can run on as few as 10,000 reconfigurable atomic qubits using a newer class of error-correcting codes called qLDPC.
The significance: previous resource estimates assumed surface codes, which require roughly 1,000 physical qubits per logical qubit. The Caltech team’s qLDPC codes require 161 times fewer physical qubits for equivalent error correction. That collapses the hardware requirement from millions of qubits to tens of thousands.
Current neutral atom arrays have demonstrated trapping of up to 6,100 atoms. The gap between demonstrated array sizes and a cryptographically relevant machine narrowed from three orders of magnitude to roughly a factor of four.
The engineering challenges are real (scaling atomic arrays, maintaining error rates, optimizing operations across larger systems), but the Caltech team laid out a concrete architecture, not a theoretical projection.
Why Crypto Can’t Wait for the Protocol Fix
Banks can patch servers overnight. Blockchains require community consensus, protocol upgrades, and in many cases, contentious hard forks that take months or years to coordinate.
The Google paper identifies five specific Ethereum attack vectors beyond simple key theft, including validator slashing exploits and blob transaction vulnerabilities. It proposes mitigations (commit-reveal schemes, private mempools, key rotation), but each requires protocol-level changes the community hasn’t started building.
Bitcoin faces its own version of this coordination problem. The paper discusses policy options for the millions of BTC in quantum-vulnerable addresses: forced migration deadlines, burn mechanisms, recovery sidechains. Every option is politically contentious. The governance timeline is measured in years. The hardware timeline is accelerating in months.
What the Authors Chose Not to Publish
There’s one detail in this paper that has no precedent in the history of quantum computing research.
The Google team used zero-knowledge proofs to validate their results. That means they proved their attack methodology works without revealing exactly how to execute it. Quantum computing papers have been describing theoretical attacks on cryptography for decades, and the authors have always published their full methodology. This team decided that was no longer safe.
That editorial choice says something the qubit counts and timing estimates don’t. The researchers themselves, working at the institution with one of the most advanced quantum computing programs on Earth, concluded that the specifics of this attack are dangerous enough to withhold. When the people doing the research start treating their own findings as a security risk, the timeline question answers itself.
What to Do Now
If you operate a crypto exchange, custodial service, DeFi protocol, or wallet infrastructure:
Audit your exposure. Identify which addresses under your control have exposed public keys. This includes P2PK, reused addresses, and Taproot outputs. The Google paper provides a methodology for quantifying exactly how much is at risk.
Protect the infrastructure around the chain now. The on-chain cryptography (the key pairs securing wallets and transactions) can only change through protocol upgrades, and those take time. But exchanges, custodial platforms, and node operators also depend on classical encryption (TLS, API authentication, internal communications) that is just as vulnerable to quantum attack and entirely within your control to upgrade today. Post-quantum cryptographic standards (FIPS 203, 204, 205) are finalized. Network-layer quantum-safe encryption can wrap these systems without waiting for a hard fork or ripping out what’s already running.
Plan for the governance timeline. If your protocol requires a hard fork to implement quantum resistance, the engineering and political work needs to start now. The responsible disclosure bought the community time to prepare. Use it.
For individual holders: If your funds sit in addresses with exposed public keys (including Taproot), the safest near-term action is migrating to addresses that only expose the public key at transaction time, and minimizing the value held in any single address. Watch for protocol-level migration proposals from core development teams.
QuSecure provides post-quantum cryptographic protection at the network layer, enabling organizations to deploy quantum-safe encryption without infrastructure overhaul. Learn more at qusecure.com.
