Quantum computers threaten blockchain signatures, not hashes

Every few weeks a headline says quantum computers will “break Bitcoin’s hashing”. Google’s own paper says the opposite about hashes. What it puts at risk is the signatures.

Hashes stay. Signatures move. And the thing that exposes your key is your first transaction.

TL;DR

• Google Quantum AI estimates that breaking secp256k1, the curve behind Bitcoin and Ethereum signatures, needs at most 1,200 logical qubits. That is far fewer than earlier estimates, but no such machine exists yet.
• SHA-256 and Keccak-256 are not the weak link. A quantum miner would be hundreds of times slower than one ASIC, even in the paper’s most generous case.
• An Ethereum address hides its public key behind a hash until the account signs its first transaction. After that, the key is public for good.

What did Google actually publish?

On March 30, 2026, Google Quantum AI published a whitepaper with authors from UC Berkeley, the Ethereum Foundation and Stanford. It estimates what it takes to run Shor’s algorithm against the 256-bit elliptic curve secp256k1.

Their two circuits need at most 1,200 logical qubits and 90 million Toffoli gates, or 1,450 qubits and 70 million gates. On a superconducting machine with a 0.1% physical error rate, that comes to fewer than half a million physical qubits. The paper calls this a nearly 20-fold drop from earlier estimates.

One detail is new for this kind of research. Google didn’t publish the attack circuits. It published a zero-knowledge proof that the circuits exist and work, so anyone can check the numbers without getting a recipe.

A second Google result made the news this week. Its magic state cultivation paper reports 40 times fewer errors on a key ingredient of fault-tolerant computing, run on the Willow chip. That is progress on hardware, not an attack.

Which parts of a blockchain does this break?

Two quantum algorithms matter here, and they hit very different things.

Shor’s algorithm solves the discrete logarithm problem. That breaks elliptic-curve cryptography outright: the ECDSA signatures on accounts, the BLS signatures validators use, and the KZG commitments behind Ethereum’s data availability sampling.

Grover’s algorithm speeds up brute-force search, which is what attacking a hash function means. The speedup is only quadratic, and the paper says error correction overheads eat almost all of it.

Can a quantum computer break SHA-256?

Yes, according to the paper. It works through a case it calls “fantastical”: a quantum computer that evaluates SHA-256 in a single 1-microsecond error correction cycle.

Under realistic assumptions, the paper says the quantum number drops by over 10 orders of magnitude. Grover also doesn’t parallelize well, and mining is all about parallel hardware.

The same goes for addresses. Keccak-256 and SHA-256 lose some margin, but nobody is reversing them with a quantum computer.

When does your public key become public?

This is the part I wanted to see for myself. An Ethereum address is the last 20 bytes of the Keccak-256 hash of the public key. As long as only the address is known, Shor has nothing to work on.

A signed transaction changes that. Anyone holding its raw bytes can recover the sender’s public key from the signature. I checked it with viem and a fresh key. The transaction is signed but never sent:

import { generatePrivateKey, privateKeyToAccount } from 'viem/accounts';
import { keccak256, parseTransaction, recoverPublicKey,
  serializeTransaction } from 'viem';

const account = privateKeyToAccount(generatePrivateKey());
const raw = await account.signTransaction({
  chainId: 11155111, type: 'eip1559', nonce: 0, gas: 21000n,
  to: '0x000000000000000000000000000000000000dEaD', value: 10n ** 15n,
  maxFeePerGas: 2_000_000_000n, maxPriorityFeePerGas: 1_000_000_000n,
});

// From here on, only the raw bytes are used
const { r, s, yParity, ...unsigned } = parseTransaction(raw);
const hash = keccak256(serializeTransaction(unsigned));
const recovered = await recoverPublicKey({ hash, signature: { r, s, yParity } });
console.log((raw.length - 2) / 2, recovered === account.publicKey); // 119 true

This is ordinary Ethereum, not a quantum trick. ecrecover works this way on purpose. But it means every account that has ever sent a transaction has its public key on chain.

What’s the difference between on-spend and at-rest attacks?

The paper splits attacks by how much time the attacker has.

• On-spend: the attacker sees your signed transaction in the public mempool, breaks the key and gets a competing transaction in first.
• At-rest: the attacker goes after keys that have been public for a long time, such as any account that has sent before.

On-spend is a race against block time. The paper estimates about 9 minutes per key for a “primed” machine, one that has already run the half of the algorithm that is the same for every key.

Bitcoin’s 10-minute average is uncomfortably close to that. Ethereum’s 12-second slots are not, so the paper doesn’t expect early machines to pull off on-spend attacks there.

For Ethereum the problem is at-rest. The paper estimates that one fast machine could break the keys of the 1,000 richest Ethereum accounts, about 20.5 million ETH, in under nine days. An account can’t change its key either: a new key means a new address.

What is Ethereum doing about it?

The Ethereum Foundation runs a post-quantum hub. It says the protocol upgrades could be done by 2029, with no fixed date, and the rest of the migration taking longer.

Two parts of the plan stood out to me:

• Validators would move from BLS to leanXMSS, a hash-based signature. The fix for broken curves is built from hashes.
• Accounts would move through account abstraction, so each account can switch its signature check without a flag day. Falcon, Dilithium and SPHINCS+ are the candidates under evaluation.

Account abstraction already exists as ERC-4337 user operations, and EIP-7702 lets an existing account run code. The paper is blunt about the limit, though: these help, but transactions still start from an elliptic-curve account today.

What does this change for developers today?

Not much this week. Nothing here is an emergency. But some habits age badly:

• Long-lived hot keys. An agent or service that signs from the same key for years has a public key that has been exposed for years.
• Keys that can’t rotate. Admin keys on contracts, multisig signers and oracle keys are on the paper’s list of at-rest risks.
• Assuming “it’s hashed, so it’s safe”. True for the address, but only until the first signature.

As for my own corner: hashspan traces transactions, it doesn’t protect them. The time between a send span and its confirm span shows how long a signed transaction sat in public. It’s a number to know, not a defence.

Try it yourself

The check above runs offline, with no chain and no API key. Save it as key.mjs and run it with Node.js 22 or later (I ran it on 22.14 and 24.21):

npm install viem@2.57.2
node key.mjs   # 119 true

Every run makes a new key, so the key changes and the answer doesn’t.