A tweet from Justin Drake kicked off a familiar cycle on crypto Twitter: panic, memes, denial, and a lot of people suddenly pretending they had strong opinions about Toffoli gates.
Under the noise, there is a real story here.
Two new papers pushed the estimated cost of breaking secp256k1, the elliptic curve behind Bitcoin signatures and many Ethereum wallets, lower than a lot of people were comfortable with. One came from Google Quantum AI. The other, discussed in the same thread, came from Oratomic, a startup working on neutral-atom quantum architectures.
The headline is not that Bitcoin gets hacked tomorrow.
The headline is that the conversation has moved from hand-wavy “someday quantum breaks crypto” talk to specific resource estimates, specific hardware assumptions, and specific wallet exposure models.
That matters.
The 3 questions that actually matter
Before getting lost in the qubit-count Olympics, the useful questions are:
- What got better in the attack?
- Which crypto systems are exposed first?
- Does this threaten wallets, mining, or both?
Those questions cut through most of the drama.

What the Google paper actually says
The Google Quantum AI paper, Securing Elliptic Curve Cryptocurrencies against Quantum Vulnerabilities, focuses on Shor’s algorithm against the 256-bit elliptic curve discrete logarithm problem on secp256k1.
That is the thing that matters for wallet keys and digital signatures.
It is not about brute-forcing seeds. It is not about mining. It is about recovering a private key from a public key when the cryptographic assumptions behind ECDSA or Schnorr no longer hold against a fault-tolerant quantum computer.
The paper’s most important claims are these:
- a low-qubit variant using about 1,200 logical qubits and 90 million Toffoli gates
- a low-gate variant using about 1,450 logical qubits and 70 million Toffoli gates
- under a fast-clock, superconducting-style architecture with aggressive but explicit assumptions, that could translate to a key recovery time measured in minutes, not years
- the paper frames this as roughly under 500,000 physical qubits in a surface-code style system
That is why the tweet thread landed so hard.
The scary part is not just the qubit count. It is the latency window.
If a future fault-tolerant machine can derive a private key in something like 9 to 23 minutes, then a mempool transaction with an exposed public key stops being a theoretical concern and starts looking like an attack surface.
Why this is a bigger deal than older quantum warnings
For years, most quantum-risk discussion in crypto had a vague shape.
Yes, Shor’s algorithm breaks RSA and elliptic curves in theory. Yes, a strong enough quantum computer would be catastrophic for today’s public-key cryptography. But the hardware requirements still felt like they lived in the same drawer as fusion timelines and room-temperature-superconductor rumors.
What changed here is the attack got tighter.
Google is not claiming they built the machine. They are claiming the resource estimate for a cryptographically relevant attack is lower than many previous estimates, and they went far enough to publish a zero-knowledge proof of the circuit claim instead of releasing the full optimized attack details.
That last part is weird and important.
They basically said: we can prove we have the optimized construction without publishing the blueprint.
That should reset how people think about the quantum-security timeline. Public papers may stop being the full frontier. The visible academic state of the art could lag the real one.
The Oratomic angle, lower qubit count, slower clock
The second paper in the Drake thread is the more speculative-feeling one, at least from the outside.
The broad claim, repeated in the thread and in follow-up reporting, is that a neutral-atom architecture using higher-rate error correction could potentially bring the physical qubit requirement way down, to the tens of thousands instead of the hundreds of thousands.
The number that spread fastest was roughly 26,000 atomic qubits for a time-efficient setup, with a runtime closer to 10 days for one Shor run. A more space-efficient setup was discussed as being even smaller, but dramatically slower.
That tradeoff matters.
The Google-style framing is: more physical qubits, faster clock, attack in minutes.
The Oratomic-style framing is: fewer physical qubits, slower clock, attack in days.
That means these two papers are not saying the same thing.
They are tightening different layers of the stack.
- Google squeezes the logical circuit
- Oratomic is described as squeezing the physical implementation and error-correction overhead
Put together, that is why people reacted so strongly.
I want to be careful here: I was able to verify the Google paper directly. The Oratomic claims are consistent across the Drake thread and secondary reporting I reviewed, but I have not independently verified the full original paper text to the same standard. So treat that section as credible but less directly verified.
Bitcoin wallets are the first obvious blast radius
This is where the conversation gets practical.
The important distinction is between public keys that are already exposed and public keys that only become exposed when you spend.
In Bitcoin, those are very different risk profiles.
At-rest risk
Some Bitcoin outputs are already sitting on-chain with public keys exposed.
That includes old P2PK outputs, plus any construction that directly reveals the public key on-chain. Those coins are the easiest long-term quantum target because an attacker does not need to wait for a spend. They can just work on the exposed key.
The Google paper also flags Taproot key-path outputs as reintroducing a form of at-rest exposure because the tweaked public key is on-chain.
That does not mean Taproot is broken today. It means in a future quantum setting, the exposure model is worse than hash-hidden constructions.
On-spend risk
Other Bitcoin outputs, like standard P2PKH and P2WPKH, hide the public key behind a hash until spend time.
That sounds safer, and it is safer against at-rest attacks.
But the moment you spend from one of those outputs, your public key appears in the transaction flow. If a cryptographically relevant quantum computer can recover the private key before confirmation, an attacker could attempt an on-spend attack by racing your transaction with a higher-fee theft transaction.
This is why people in the thread kept obsessing over the 9-minute estimate.
Bitcoin’s average block interval is about 10 minutes. That is uncomfortably close.
It does not mean every spend becomes instantly stealable. Real attacks would depend on mempool visibility, network propagation, fee competition, attacker prep, and whether the runtime estimate survives contact with engineering reality.
But it is the first time the theoretical attack window starts to line up with a major chain’s actual settlement rhythm in a way that feels concrete.
Ethereum has a different shape of risk
Ethereum is not magically safe here. It is just exposed differently.
The short version:
- Bitcoin has a larger near-term on-spend narrative because of the 10-minute block interval and public mempool dynamics
- Ethereum has shorter block times, around 12 seconds, which makes the classic on-spend race much less practical
- but Ethereum still has deep at-rest and protocol-level exposure because it has long-lived accounts, validators, contracts, bridges, and more complicated state surfaces
So if you ask, “would a future quantum attacker drain Ethereum the same way they might race a Bitcoin transaction?” the answer is probably not in the same way.
But if you ask, “does Ethereum still have a serious post-quantum migration problem?” absolutely.
There are too many keys, too many persistent identities, and too many protocol dependencies for this to be someone else’s problem.
That is partly why Ethereum has already spent time on post-quantum planning while a lot of the broader market was still treating quantum risk like science-fiction branding.
What this means for regular crypto wallets
Most wallet users should think about this in 4 buckets.
1. Address reuse starts looking worse
If you keep reusing addresses, you increase the amount of time your public key or key relationships stay exposed and easy to target.
That was already bad hygiene. Quantum pressure makes it worse.
2. Wallet design matters more than coin branding
A lot of people talk about “is Bitcoin safe” or “is Ethereum safe” like there is one answer.
There isn’t.
The better question is: what exact wallet construction, script type, and transaction flow are you using?
Hash-hidden outputs are better than always-exposed public keys. Private transaction relay is better than screaming your spend intent into a public mempool if the threat model shifts. Key rotation and migration tooling become more important.
3. Cold storage is not one thing
Some cold-storage setups are mainly exposed only at spend time. Others may leak more structure or rely on long-lived exposed keys.
The future gap between “safe enough until migration” and “quietly sitting on a quantum time bomb” may come down to pretty boring implementation details.
4. Exchanges and custodians have the ugly job
Retail users can migrate slowly and imperfectly.
Large custodians cannot.
Anyone managing huge balances, exposed pubkeys, old address formats, staking infrastructure, validator fleets, or institutional signing systems is staring at a much nastier operational problem. They need staged migration plans, monitoring, wallet inventory, key exposure audits, and probably a lot of uncomfortable spreadsheet work.
That part will not be glamorous. It will matter anyway.
What about mining?
This is where a lot of people get the story wrong.
These papers are much more about signatures than mining.
That distinction matters because crypto people tend to hear “quantum” and immediately imagine someone vaporizing Bitcoin miners with magic ASICs from the future.
That is not what the Google paper says.
The mining angle is mostly about Grover’s algorithm, which offers a quadratic speedup for brute-force style search problems. In theory, that sounds relevant to proof-of-work. In practice, the paper’s message is pretty blunt: commercially meaningful quantum mining is not the near-term issue.
Why?
- Grover speedups get mauled by quantum error-correction overhead
- proof-of-work is massively parallel in the classical world already
- quantum mining does not inherit the same kind of clean, near-term attack window that signature recovery does
So if you are ranking risks:
- wallet signatures and exposed public keys
- protocol migration to post-quantum signatures
- custodial key management and address exposure
- mining
Mining is on the list. It is just not at the top of the list.

Justin Drake made this point directly in the tweet thread too: Bitcoin PoW is not the main quantum story here.
I think that is right.
The real ramification is strategic, not theatrical
The most useful takeaway is not “sell your coins” or “lol quantum FUD.”
The useful takeaway is that the industry now has to treat post-quantum migration like a real engineering program.
That means:
- inventory which wallets and outputs expose public keys today
- reduce address reuse
- favor constructions that keep public keys hidden until needed
- think seriously about private relay or transaction-protection mechanisms
- design migration paths before the emergency
- stop assuming the public research literature is the full frontier
That last one is easy to miss.
The Google team’s use of a zero-knowledge proof to attest to a sensitive attack construction without publishing it is a signal all by itself. If future breakthroughs are partially withheld, the market may get less warning than it expects.
That does not mean hidden super-quantum agencies are stealing your wallet next Tuesday.
It does mean the old comfort blanket, “we’ll know when it’s close because the papers will tell us,” has gotten thinner.
So, are we close to q-day?
That depends what “close” means.
We are not close in the sense that a laptop or a lab toy machine is about to crack secp256k1.
We are closer in the sense that the attack model is starting to look architecturally believable if hardware keeps compounding.
That is a very different sentence.
And it is the one people should focus on.
The honest posture is somewhere between complacency and hysteria:
- no, this is not game over tomorrow
- yes, the security margin looks thinner than it did before
- yes, wallets and chains should be preparing now
- no, mining is not the main story
- yes, exposed public keys are where the pain concentrates first
That is enough to justify serious action.
Final take
The biggest shift from these papers is psychological.
Quantum attacks on crypto used to live in the category of distant inevitabilities. Now they are starting to look like engineering roadmaps with rough budgets attached.
Once that happens, the conversation changes.
Wallet safety stops being just a question of seed backups and phishing resistance. It becomes a question of cryptographic migration timing, key exposure minimization, and whether the system can evolve before the threat window opens.
That is the part worth paying attention to.
Sources
- Justin Drake thread on X: https://x.com/drakefjustin/status/2038847732152996108
- Google Quantum AI, Securing Elliptic Curve Cryptocurrencies against Quantum Vulnerabilities: https://quantumai.google/static/site-assets/downloads/cryptocurrency-whitepaper.pdf
- Quantum Computing Report, The Decryption Threshold — Re-estimating the Quantum Threat to Blockchain Infrastructure: https://quantumcomputingreport.com/the-decryption-threshold-re-estimating-the-quantum-threat-to-blockchain-infrastructure/
