Qubits and Blockchain

Whenever another news story appears about Google, IBM, or some new superconducting qubit, experts crawl out of every corner announcing: “Bitcoin is finished.” “The blockchain will be hacked.”

“Crypto will die.” Nonsense. And nonsense on several levels at once. First, most people have no idea which part of a blockchain quantum computing could actually attack. Shor's algorithm does not “break” SHA-256 or Keccak hash functions. For these, there is Grover's algorithm, which gives a quadratic speed-up in brute-force search.

That means roughly 2¹²⁸ operations instead of 2²⁵⁶. Yes, that is a very large number. But 2¹²⁸ is still so astronomical that a practical attack remains beyond reasonable reach. The real problem lies elsewhere.

ECDSA. Digital signatures are the potentially vulnerable part of most blockchains. Shor's algorithm can efficiently solve the elliptic-curve discrete logarithm problem. If you have a public key:

For an elliptic-curve public key \(Q=dG\), the best known general classical attacks on a suitable curve require work exponential in the key's bit length; that is not a proof that every possible classical algorithm must be exponential. Shor's algorithm makes discrete logarithms polynomial on a sufficiently capable fault-tolerant quantum computer. The same issue affects Schnorr signatures, not just ECDSA.

That does not automatically mean Bitcoin's death. An address and a public key are different things. A fresh P2PKH output normally hides the public key until spending, provided the same key has not been revealed elsewhere. Reused keys and outputs that already expose a public key, including P2PK and Taproot outputs, do not have that protection. Hiding behind HASH160 is not permanent quantum security either: an idealized generic preimage search on a 160-bit hash has about 2^80 quantum-query complexity, not 2^128.

The blockchain stores only:

HASH160(pubkey)

For a previously hidden key, spending reveals it and can open a race before confirmation. If the same key controls other unspent outputs, confirming one transaction does not make those other outputs safe. The short spending window therefore applies only to a particular case, not to all bitcoin.

Confirmation time varies with block arrival, fees and congestion; it is not a fixed number of minutes. In that particular race an attacker would need to:

1. Retrieve the transaction from the mempool.
2. Extract the public key.
3. Run Shor's algorithm.
4. Recover the private key.
5. Sign its own transaction.
6. Get that transaction included before the original.

A machine capable of doing this in minutes would threaten far more than blockchains. But infrastructure would not all collapse automatically: the impact depends on which keys and algorithms a system uses and whether it has migrated to post-quantum protection.

TLS, SSH, PGP, VPNs, corporate PKI, government signatures, banking HSMs and military communications can all contain quantum-vulnerable public-key components. They can also be upgraded, and some already use hybrid or post-quantum mechanisms. “The entire internet turns into a pumpkin” is rhetoric, not a technical consequence of Shor's algorithm.

Quantum computers do not break all cryptography. Shor threatens RSA and elliptic-curve systems; symmetric ciphers and hashes face different attacks and can retain useful security with suitable parameters. Post-quantum signatures such as ML-DSA (derived from CRYSTALS-Dilithium) and SLH-DSA (derived from SPHINCS+) are standardized. Falcon is another signature family. A blockchain migration requires protocol design, consensus, key migration and a policy for dormant coins; merely saying “hard fork” does not solve those questions. Which sector suffers more cannot be inferred from the algorithms alone.

Hybrid signature schemes can be introduced. UTXOs can be migrated gradually. But upgrading billions of embedded devices, old industrial controllers, military equipment, satellites, banking HSMs, IoT devices, and corporate legacy code is an entirely different level of hell.

There is a more interesting problem, though. For some reason, everyone treats quantum computers purely as hacking tools. That is an extremely primitive view. The real revolution will begin when machines appear that can accelerate particular classes of optimisation problems.

Portfolio optimisation. Logistics. Finding extrema. Modelling materials. Cryptanalysis. Training certain classes of models. Solving combinatorial optimisation problems. Imagine a fund able to calculate market scenarios even a few orders of magnitude faster than its competitors. These are research directions and hypothetical advantages, not a general proven speedup for portfolios, trading or arbitrary NP-hard optimization. Practical advantage must include data loading, error correction and comparison with the best classical methods.

Imagine a market maker able to optimise thousands of strategies simultaneously. Imagine a state gaining an asymmetric advantage in cryptanalysis. That would be a real nightmare. The world's distributed nature rests neither on democracy nor on humanism.

It rests on computing resources being more or less available to everyone. Yes, some people have more servers. Yes, some people have more money. But fundamentally, anyone can download Linux, run a Bitcoin node, write their own engine in Rust or Python, and play by roughly the same rules.

Quantum computing could potentially break that arrangement. If a technology appears that is available only to a handful of states and corporations, we could see genuine computational feudalism for the first time in a long while.

A new technological aristocracy. Not landowners. Not factory owners. The owners of computation. At that point, worrying about a few hacked crypto wallets will look about as absurd as discussing candle prices during the fall of the Roman Empire.

We are still a very long way from that point, however. Today's quantum computers resemble the computers of the 1950s in their stage of development. Beautiful laboratory toys. Thousands of engineering problems.

Noisy qubits, coherence limits and error correction remain serious engineering problems. Resource estimates for attacking secp256k1 depend on the algorithm, physical error rates, architecture and target runtime. There is no universal threshold of “millions of qubits”; a bare qubit count without those assumptions is not a useful forecast.

A reliable date for a cryptographically relevant quantum computer is unknown. That uncertainty is a reason to prepare migration, not to promise decades of safety. If vulnerable systems remain in service when such machines arrive, the problem will be broader than cryptocurrency: it will affect digital trust wherever those systems are used.

For the last fifty years, we have built our civilisation on the assumption that certain mathematical problems are computationally intractable. If that assumption ceases to hold, we will have to rewrite almost the entire digital world from scratch.