Google Quantum AI Cuts ECDSA Attack to 1,200 Qubits, but the Engineering Gap Remains Massive
Google Quantum AI published research showing they've tailored Shor's algorithm specifically for 256-bit elliptic curve discrete logarithm problems, the math that secures Bitcoin's ECDSA signatures. The resource requirements they've achieved on paper: fewer than 1,200 logical qubits, roughly 500,000 physical qubits, and executable in minutes. Google didn't publish the actual quantum circuits, just a zero-knowledge proof that their approach works, citing competitive and national security concerns. They're targeting 2029 for post-quantum readiness, aligning with NIST's timeline to deprecate RSA by 2030.
But before the headlines send anyone into a spiral, the physical engineering constraints of actually building these quantum computers remain enormous and largely unsolved. Google's paper describes 500,000 physical qubits. The largest quantum computer today has roughly 1,200 physical qubits (IBM's Condor), and those aren't the high-fidelity, error-corrected qubits needed for cryptographic attacks. Each "logical qubit" requires hundreds to thousands of physical qubits for error correction overhead. These machines operate at temperatures colder than outer space (15 millikelvin), require extreme isolation from electromagnetic interference, and face unsolved challenges in wiring, control electronics, and cryogenic cooling at scale. Getting from 1,200 noisy physical qubits to 500,000 fault-tolerant ones is not a software problem. It is a fundamental engineering problem that nobody has solved yet.
As Alex B pointed out, the gap between headline claims and engineering reality is even wider than it appears. Researchers at Caltech recently demonstrated a 6,000 logical qubit array using neutral atoms, but those qubits were not entangled, a hard requirement for running Shor's algorithm. The actual state of the art for entangled logical qubits under the neutral atom architecture? Ninety-six. Coherence time? One to two seconds. The time required to run the proposed attack algorithms? Days. That means entanglement capacity needs to increase by more than two orders of magnitude, and coherence must be maintained roughly 100,000 times longer than current capabilities allow. Nobody has a clear path to solving either problem, but that does not stop the headline-worthy papers from flowing.
That said, Bitcoin developers and cryptographers are not ignoring the threat. They're doing what good engineers do: preparing methodically. Jonas Nick introduced SHRIMPS, a new post-quantum signature scheme that produces 2.5KB hash-based signatures across multiple devices. It builds on SHRINCS, which achieved approximately 324-byte signatures for single-device use. SHRIMPS signatures are three times smaller than the NIST standard SLH-DSA, making them practical for Bitcoin's block space constraints. This follows Nick's December 2025 paper "Hash-based signatures for Bitcoin" co-authored with Mikhail Kudinov at Blockstream Research. If you want the full deep dive, Jonas and Mikhail joined us on the podcast to explain why Bitcoin's current signature scheme is theoretically broken in a post-quantum world and what the upgrade path looks like.
Meanwhile, BIP-360, authored by Hunter Beast, Ethan Heilman, and Isabel Foxen Duke, proposes Pay-to-Merkle-Root (P2MR), a new quantum-resistant output type that removes Taproot's quantum-vulnerable keypath spend. BIP-360 is already live on a Bitcoin testnet, with BTQ Technologies running transactions through it. The co-authors estimate the full upgrade could take up to seven years, which is why the research is happening now.
The key takeaway here is that the approach matters as much as the timeline. Rushing to implement quantum-resistant changes without rigorous testing and long-term thinking could introduce risks far worse than the quantum threat itself. A hasty soft fork or poorly vetted signature scheme deployed under panic could create vulnerabilities that are exploitable today, not in some theoretical future. Bitcoin's strength has always been its conservative upgrade process. The developers working on SHRIMPS and BIP-360 understand this. They're building the tools now so that when the time comes to deploy them, the protocol can upgrade deliberately, not desperately. Preparation without panic is the correct posture.
|