Bitcoin Can Be Quantum-Resistant in Two Upgrades, Bitcoin Core Dev Says—Here’s the Plan

That framing, reported by Bitcoinist, cuts through a lot of quantum doomposting. The risk is real in theory, but the mitigation path can be incremental, opt-in at first, then coercive only if and when the threat gets credible. ^[2]

Why "quantum risk" is mostly a signature problem

The nuance, and this is where many devs stay calm, is exposure: ^[4]

• For common output types like P2PKH (legacy "1..." addresses) and P2WPKH (SegWit "bc1q..."), the public key is not visible on-chain until you spend. That creates a window where a quantum attacker would need to: see your spend hit the mempool, derive the key, and front-run a conflicting spend before confirmation.
• Some coins are already exposed because their public keys are on-chain permanently (classic P2PK outputs, reused addresses, and various script patterns). If a powerful quantum adversary existed, these would be the low-hanging fruit.

The "two upgrades" plan, translated into Bitcoin plumbing

The Core dev's "two steps" idea is best understood as a migration playbook:

Step 1: Add a quantum-resistant spend path (new address type or script)

First, Bitcoin needs a way for users to lock coins to a post-quantum (PQ) signature scheme. That means introducing a new output type, script template, or opcode combination that validates PQ signatures.

This is the non-drama part. If it is designed as a soft fork, it can be deployed without forcing everyone to move on day one. Users who care (exchanges, custodians, whales with sleepy UTXOs, anyone holding long-term) can start sending to PQ-secured outputs as tooling matures.

The open question is which PQ scheme fits Bitcoin's constraints:

• Signature size and verification cost matter because every extra byte hits block space, fees, and node resource requirements.
• Security assumptions matter because the community will not swap one hard-to-audit primitive for another just to check a "quantum resistant" box.

Some of the research chatter around this topic has pointed to draft ideas like BIP 360, which is discussed as an approach to reducing quantum exposure, but it is not a finalized, universally accepted plan. Consider it an example of the direction of travel, not a shipped spec. ^[5]

Step 2: Deal with the legacy coins that never migrate

There are a few ways this could be implemented in practice, each with different levels of pain:

• A deadline-based migration policy: coins in vulnerable output types must be moved to PQ outputs before a certain block height. After that, spending them becomes invalid under consensus.
• Targeted restrictions for already-exposed public keys: focus on UTXOs whose public keys are known on-chain today, since those are the easiest to rob under a quantum scenario.
• Graduated policy: start by discouraging risky patterns, later tighten rules if quantum capability becomes more than theoretical.

If you are hearing "soft confiscation," you are not wrong. Any rule that makes certain legacy outputs unspendable would strand coins that are lost, abandoned, or simply never upgraded. That includes the elephant in the room: old, untouched stashes with public keys already visible, depending on their script type.

This is why many Bitcoin developers have historically treated quantum preparedness as a "not yet" issue. The engineering is hard, but the social layer is harder. ^[6]

Market structure angle: who would actually move first?

If Bitcoin ever adds a PQ output type, expect the first wave of migration to be highly identifiable:

• Exchanges and custodians: They hold big, consolidated UTXOs and have the most to lose from being a public example.
• Publicly known treasuries: ETFs, corporates, and foundations that cannot hand-wave a security model change.
• Whales with dormant bags: Especially those sitting on old address formats or coins tied to address reuse.

This will create an on-chain tell. You would likely see a measurable shift in the UTXO set toward the new script type, plus fee spikes if migration becomes time-sensitive.

What could go wrong (and what would make this plan credible)

This two-upgrade framing is clean, but it rests on several non-trivial assumptions:

• PQ cryptography must be conservative: Bitcoin tends to pick boring primitives after years of scrutiny. A rushed selection would be a non-starter.
• Block space externalities are real: Many PQ signatures are larger than today's signatures. If Bitcoin adopts something heavy, fees and validation costs go up, and that affects everyone, not just the people opting in.
• The transition policy must be politically survivable: Any step that risks burning coins will trigger fierce debate about property rights, precedent, and what Bitcoin is allowed to do at the consensus layer.

On the flip side, the thesis becomes more credible if three things happen in sequence:

1. A serious draft BIP gets traction and review from multiple cryptographers.
2. Wallets and major infra providers commit to supporting PQ outputs.
3. The community converges on a long grace period that makes Step 2 feel like risk management, not a surprise rewrite of the rules.

Takeaway: the path is short on paper, long in practice

The risk is timing and coordination. If quantum capability stays hypothetical, Step 1 can sit in the toolbox for years. If credible quantum attacks start looking imminent, the migration trade becomes brutally real: higher fees, contentious politics, and a race to move funds before any restriction date.

Key invalidation point for the whole plan is simple: if the community cannot agree on a PQ scheme that is efficient enough for Bitcoin's block space constraints and conservative enough for Bitcoin's security culture, the "two upgrades" story turns into "two upgrades plus a decade of arguments."