Bitcoin and the Quantum Clock: Why Swapping Signatures Is Hard

Most systems threatened by quantum computers can be fixed by their owners. A browser ships an update, a certificate authority changes its signing key, a bank rotates its certificates. Bitcoin is the interesting exception. Its security rests almost entirely on signatures, some of its keys are more than fifteen years old, and there is no one with the authority to replace them.

That makes Bitcoin the hardest real-world case of the problem this series has been circling: how do you swap out the cryptography of a system that is already running? This fifth post in our Quantum, Plainly series looks at it purely as a cryptography and engineering question. It is not about prices, and it is not investment advice.

What a quantum computer would break

Bitcoin uses two kinds of cryptography, and a quantum computer affects them very differently.

• Hashing (SHA-256) is used for mining and for addresses. Quantum computers only weaken hash functions modestly, as we explained in the first post, so this part is not the concern.
• Signatures prove that the person spending coins owns them. Bitcoin signs with ECDSA and Schnorr over a 256-bit elliptic curve. Shor's algorithm breaks this: given a public key, a large enough quantum computer can work out the private key, and with it spend the coins.

In March 2026, Google Quantum AI estimated that breaking this kind of 256-bit elliptic curve key would take fewer than 500,000 physical qubits and a runtime measured in minutes. No machine close to that exists. But the estimate was about twenty times lower than the previous one, which is why this discussion moved from the fringe to the mainstream of Bitcoin development this year.

Which coins are exposed

A quantum attacker needs the public key, and here Bitcoin's design helps. Most modern addresses do not contain the public key at all, only a hash of it. The key is revealed only when the owner spends from the address. Several situations break that protection:

• Early "pay to public key" outputs. Many of the coins mined in Bitcoin's first years, including coins widely attributed to its creator, sit in outputs that contain the public key directly.
• Reused addresses. Once an address has been spent from, its public key is on the blockchain forever. Any coins still sitting at that address are exposed.
• Taproot outputs. Bitcoin's 2021 Taproot upgrade put a (tweaked) public key directly in the output to make transactions smaller and more private, which also makes it visible to a future attacker.

Estimates vary with the method, but one widely cited analysis counts about 6.7 million BTC with exposed public keys, roughly a third of the supply, of which about 1.7 million sit in the oldest pay-to-public-key outputs.

There is a second, subtler exposure. Even a careful user reveals their public key the moment they broadcast a transaction, and it then waits a few minutes to be included in a block. A fast enough quantum computer could, in principle, derive the key in that window and send a competing transaction. Google's paper estimated that a machine prepared in advance might succeed in a meaningful fraction of cases within Bitcoin's ten-minute block time. That attack needs a much faster machine than simply breaking old exposed keys at leisure, but it means that "never reuse addresses" is not a complete defense.

Why the fix is hard

On a normal system, the fix is known: switch to post-quantum signatures. On Bitcoin, every part of that sentence is difficult.

Nobody can migrate on your behalf. A bank can reissue cards. In Bitcoin, only the holder of a private key can move coins to a new, quantum-safe address. If the key is lost, or its owner is gone, those coins can never be moved.

Changes need broad agreement. Bitcoin changes its rules through soft forks that the network has to adopt voluntarily. Upgrades like SegWit and Taproot took years from proposal to activation.

Signatures cost block space. Post-quantum signatures are much larger than today's, and every byte of a signature has to fit in a block of fixed size.

Larger signatures mean fewer transactions per block. The same analysis estimates that a block holding 2,500 to 3,000 transactions today would hold roughly 500 to 700 post-quantum ones, and that moving every exposed coin could take several years at realistic rates. This is the same size problem that slowed post-quantum certificates on the web, except that Bitcoin has no equivalent of a browser vendor who can redesign the system for everyone.

What developers have proposed

Three proposals shape the current discussion. None of them is active on the network today.

• BIP-360, Pay-to-Merkle-Root. Merged into Bitcoin's official proposal repository on February 11, 2026. It defines a new kind of output that is like Taproot but without the exposed public key: the output commits only to a tree of spending scripts. Being merged means the proposal is formally documented and under review, not that it has been adopted.
• BIP-361, a phased migration. Introduced in April 2026 by Jameson Lopp and co-authors. Roughly three years after activation, the network would stop accepting new payments to vulnerable output types. About two years after that, signatures from vulnerable outputs would stop being valid, freezing coins that were never moved. A third phase, a way to recover frozen coins by proving knowledge of the original wallet seed, is still research. The proposal is a draft with no activation timeline.
• SHRINCS, a Bitcoin-specific signature. Blockstream Research designed a hash-based signature scheme whose security rests only on SHA-256, which Bitcoin already depends on. It keeps signatures far smaller than the general-purpose standards by being stateful, meaning the wallet must track how many times a key has signed, with a larger fallback when it cannot. A first post-quantum-signed transaction ran on Blockstream's Liquid sidechain in March 2026.

The hardest question is not technical

The freeze in BIP-361 exposes the real dilemma. Suppose a quantum computer does arrive, and millions of coins in abandoned or lost wallets are still sitting behind exposed public keys. There are two options, and both are uncomfortable.

• Leave them spendable, and accept that whoever first builds the machine can take them. That respects the rule that nobody may touch your coins, but it could hand a huge sum to an attacker.
• Freeze them in advance, and accept that the network has overridden ownership for coins whose owners simply did not act in time.

There is no cryptographic answer to that, only a social one, and the Bitcoin community is debating it now precisely because consensus takes years to form.

What the rest of us can learn

You do not need to hold any cryptocurrency for this case to be useful. Bitcoin simply shows, in an extreme form, lessons that apply to every system.

• Hide keys until you need them. Publishing only a hash of a public key, as most Bitcoin addresses do, turned out to be quantum protection nobody designed on purpose.
• Long-lived keys are the real risk. The oldest keys in a system are the ones that are hardest to rotate and most exposed when the math changes.
• Build the upgrade path before you need it. A system that can change algorithms through configuration can react in months. A system where the algorithm is part of the rules can take a decade.
• Migration is a coordination problem. The cryptography for a quantum-safe Bitcoin largely exists. Getting everyone to use it is the hard part.

That last point is the thread running through this whole series. The new algorithms are standardized, the estimates for the threat keep falling, and the remaining work is mostly people, process and time. Starting early is the only reliable way to finish on time.

If you enjoy plain-language explanations like this one, subscribe below. We publish them alongside updates on what we are building at FirstPoint.