Apparently quantum computers are going to destroy Bitcoin while politely respecting the rest of the financial system.

A thoughtful arrangement. Very considerate of them.

The serious version of the argument deserves attention: a sufficiently capable quantum computer could threaten cryptography Bitcoin uses to authorize spending. That is a real reason to investigate, prepare, and debate changes. It is not a reason to imagine that mathematics distinguishes between a Bitcoin holder and someone who prefers a bank account.

A machine does not ask whether you approve of cryptocurrency before solving a mathematical problem.

But there is a second mistake waiting nearby. Saying “banks have the same problem” does not make Bitcoin safe. If several buildings have faulty locks, pointing at the building next door is not a repair.

We need to ask which locks are vulnerable, what they protect, and how they can be replaced before someone learns to open them.

Which part of Bitcoin?

“Break Bitcoin” compresses several different claims into one convenient headline.

Bitcoin uses cryptography for different jobs. Hashing and digital signatures are not interchangeable. The threat to a signature scheme is not automatically a demonstration that mining, every password, or every encrypted file falls apart in exactly the same way.

The important concern here is authorization. Bitcoin's current ECDSA and Schnorr signatures use elliptic-curve cryptography. A cryptographically relevant quantum computer could threaten those signatures, potentially allowing an attacker to derive a private key from an exposed public key and authorize a spend.

That is a rather more specific problem than a mysterious machine making every bitcoin disappear.

Exposure matters. A public key already visible on-chain presents a different situation from one that has not yet been revealed. Address and script choices, reuse, and the timing of transactions affect the discussion. A slogan about “the blockchain” does not tell us whose funds are exposed or what defenses would actually address that exposure.

Nor should we invent a comfortable arrival date. A proposal's urgency is not proof that a practical attacker exists today. Conversely, uncertainty about when one might exist is not proof that preparation can wait.

That is the unpleasant thing about uncertainty. It refuses to support either team's preferred certainty.

The rest of the world uses mathematics, too

The wider concern is public-key cryptography. RSA and widely used elliptic-curve methods help support authentication, key establishment, and digital signatures across modern systems.

In 2023, CISA, NSA, and NIST jointly urged organizations, especially those supporting critical infrastructure, to prepare for migration to post-quantum cryptography. Their guidance calls for work on cryptographic inventories, vendors, and migration plans.

They did not publish that guidance because everyone had accidentally installed a Bitcoin wallet.

The implication reaches beyond cryptocurrency. Financial services, communications, and infrastructure can depend on vulnerable cryptographic components. But the word “can” is doing necessary work there.

We should not turn that observation into a movie trailer in which every traffic light changes at once, aircraft lose control, and hospitals stop functioning. A threat to an algorithm is not a complete account of a system's failure modes. We would need to know the actual deployment, exposure, dependencies, safeguards, and upgrade state.

Some failures concern confidentiality. Others concern impersonation or forged authorization. Those are different routes to harm, and they require different analysis.

The comparison is useful because it widens the question. It becomes misleading when it substitutes a universal catastrophe for a Bitcoin-only catastrophe.

We have improved the scenery without improving the reasoning.

An upgrade is a social problem wearing a technical coat

Post-quantum cryptography offers a path for replacing vulnerable mechanisms. That does not mean someone presses “quantum-safe” and goes to lunch.

Institutions need to find where cryptography is used, identify dependencies, obtain compatible products, test changes, and maintain service during migration. A system with a central operator may have an identifiable authority that can approve a rollout. That authority may also have old infrastructure, competing priorities, and an impressive collection of reasons to postpone maintenance.

Bitcoin has another coordination problem. A proposed consensus change is not a bank issuing instructions to its software department. Developers can propose rules; the ecosystem must evaluate and adopt them. Wallets, custodians, exchanges, and users have practical work to do as well.

That difference matters. Shared mathematical exposure does not guarantee equal readiness, equal attack costs, or equal recovery options.

BIP 361 proposes a post-quantum migration and a sunset for legacy signatures. It raises difficult questions about vulnerable funds and what happens to holders who do not migrate. Its existence establishes that a serious proposal is being discussed. It does not establish that its protections are already operating.

The distinction between “someone wrote a proposal” and “your money is protected” is worth preserving. People have lost rather a lot by treating those as synonyms.

Who gets to decide?

The most interesting part of the Bitcoin debate may be the part that cannot be solved by selecting an algorithm.

What should happen to coins whose owners never move them? What if an owner has lost access? What if a proposed defense restricts spending to prevent theft? How do you distinguish protection from dispossession when both can leave a person unable to use their property?

Leaving vulnerable funds exposed can reward an attacker. Restricting them can harm a legitimate holder. Pretending either choice has no cost makes the argument easier and the decision worse.

Those questions deserve open examination. They touch the very principles that make self-custody meaningful: control, consent, predictable rules, and the ability to verify what others are asking you to accept.

Centralized institutions have their own accountability questions. Who is responsible for migration? What has actually been tested? What evidence supports a reassuring announcement? Who bears the loss if the assurance proves premature?

“Trust us, we are preparing” is a starting statement. It is not the completed audit.

A better question

If someone claims quantum computing makes Bitcoin uniquely doomed, ask which cryptographic mechanism they mean and why their comparison excludes other systems that rely on vulnerable public-key methods.

If someone claims Bitcoin has nothing to worry about because banks also face exposure, ask what defense has actually been deployed.

Apply the same standard to both.

Do not demand perfect certainty before beginning preparation. Do not accept confident speculation as evidence that failure is inevitable. Do not confuse a new standard, an ambitious proposal, and a completed migration.

And do not let the argument become so tribal that you forget the people whose savings, communications, and choices depend on the outcome.

The point of understanding a shared threat is to make preparation more honest. It is not to win a competition over whose lock will fail first.

The future does not check your portfolio.

Your defenses should not wait for it to ask.

Axion Redshift
cypherpunkgear.com