Abstract
This proposal follows the implementation of post-quantum (PQ) output type (P2QRH) and introduces a pre-announced sunset of legacy ECDSA/Schnorr signatures. It turns quantum security into a private incentive: fail to upgrade and you will certainly lose access to your funds, creating a certainty where none previously existed.
- Phase A: Disallows sending of any funds to quantum-vulnerable addresses, hastening the adoption of P2QRH address types.
- Phase B: Renders ECDSA/Schnorr spends invalid, preventing all spending of funds in quantum-vulnerable UTXOs. This is triggered by a well-publicized flag-day roughly five years after activation.
- Phase C (optional): Pending further research and demand, a separate BIP proposing a hard fork to allow recovery of legacy UTXOs through ZK proof of possession of BIP-39 seed phrase.
Copyright
This document is licensed under the 3-clause BSD license.
Motivation
We seek to secure the value of the UTXO set and minimize incentives for quantum attacks. This proposal is radically different from any in Bitcoin’s history just as the threat posed by quantum computing is radically different from any other threat in Bitcoin’s history. Never before has Bitcoin faced a truly existential threat to its cryptographic primitives. A successful quantum attack on Bitcoin would result in significant economic disruption and damage across the entire ecosystem. Beyond its impact on price, the ability of miners to provide network security may be significantly impacted.
Accelerating quantum progress.
NIST ratified three production-grade PQ signature schemes in 2024; academic road-maps now estimate a cryptographically-relevant quantum computer as early as 2027-2030. [McKinsey]
Quantum algorithms are rapidly improving.
The envelope of safety is shrinking by dramatic increases in algorithms even if the pace of hardware improvements is slower. Algorithms are improving up to 20X, lowering the theoretical hardware requirements for breaking classical encryption. [Source: Google Security Blog]
Bitcoin’s exposed public keys.
Roughly 25% of all bitcoin have revealed a public key on-chain; those UTXOs could be stolen with sufficient quantum power.
We may not know the attack is underway.
Quantum attackers could compute the private key for known public keys then transfer all funds weeks or months later, in a covert bleed to not alert chain watchers. Q-Day may be only known much later if the attack withholds broadcasting transactions in order to postpone revealing their capabilities.
Private keys become public.
Assuming that quantum computers are able to maintain their current trajectories and overcome existing engineering obstacles, there is a near certain chance that all of Satoshi’s (and other vulnerable outputs) private keys will be found and used to steal the funds.
Impossible to know motivations.
Prior to a quantum attack, it is impossible to know the motivations of the attacker. An economically motivated attacker will try to remain undetected for as long as possible, while a malicious attacker will attempt to destroy as much value as possible.
Upgrade inertia.
Coordinating wallets, exchanges, miners and custodians historically takes years. The longer we postpone migration, the harder it becomes to coordinate. A clear, time-boxed pathway is the only credible defense. Coordinating distributed groups is more prone to delay, even if everyone has similar motivations. Historically, Bitcoin has been slow to adopt code changes, often taking multiple years to be approved.
Benefits at a Glance
- Resilience: Bitcoin protocol remains secure well past 2030 without waiting for last-minute emergency.
- Certainty: Bitcoin users and stakeholders gain certainty that a plan is both in place and being implemented to effectively deal with the threat of quantum theft of bitcoin.
- Clarity: A single, publicized timeline aligns the entire ecosystem (wallets, exchanges, hardware vendors).
- Supply Discipline: Abandoned keys that never migrate become unspendable, slightly reducing supply, as Satoshi described in his Bitcointalk thread.
Specification
| Phase | What Happens | Who Must Act | Time Horizon |
|---|---|---|---|
| Phase A | Disallow spends to legacy script types. Permitted sends are from legacy scripts to P2QRH scripts. | Everyone holding or accepting BTC. | 3 years after BIP-360 implementation. |
| Phase B | Disallow spends from quantum vulnerable outputs. At a preset block-height, nodes reject transactions that rely on ECDSA/Schnorr keys. | Everyone holding or accepting BTC. | Multi-year transition window. |
Rationale
Even if Bitcoin is not a primary initial target of a cryptographically relevant quantum computer, widespread knowledge that such a computer exists and is capable of breaking Bitcoin’s cryptography will damage faith in the network. An attack on Bitcoin may not be economically motivated - an attacker may be politically or maliciously motivated and may attempt to destroy value and trust in Bitcoin rather than extract value. There is no way to know in advance how, when, or why an attack may occur. A defensive position must be taken well in advance of any attack.
Bitcoin’s current signatures (ECDSA/Schnorr) will be a tantalizing target: any UTXO that has ever exposed its public key on-chain (roughly 25% of all bitcoin) could be stolen by a cryptographically relevant quantum computer.
Existing Proposals are Insufficient.
Any proposal that allows for the quantum theft of “lost” bitcoin is creating a dilemma. There are 3 types of proposals:
- Allow anyone to steal vulnerable coins.
- Allow throttled theft of coins, which leads to RBF battles and ultimately miners subsidizing their revenue from lost coins.
- Allow no one to steal vulnerable coins.
Minimizes attack surface.
By disallowing new spends to quantum vulnerable script types, we minimize the attack surface with each new UTXO. Upgrades to Bitcoin have historically taken many years; this will hasten and speed up the adoption of new quantum resistant script types. With a clear deadline, industry stakeholders will more readily upgrade existing infrastructure to ensure continuity of services.
Minimizes loss of access to funds.
If there is sufficient demand and research proves possible, submitting a ZK proof of knowledge of a BIP-39 seed phrase would provide a trustless means for legacy outputs to be spent in a quantum resistant manner, even after the sunset.
Stakeholder Incentives
| Stakeholder | Incentive to Upgrade |
|---|---|
| Miners |
|
| Institutional Holders |
|
| Exchanges & Custodians |
|
| Everyday Users |
|
| Attackers |
|
Key Insight
As mentioned earlier, the proposal turns quantum security into a private incentive: fail to upgrade and you will certainly lose access to your funds, creating a certainty where none previously existed. This is not an offensive attack, rather, it is defensive: the Bitcoin ecosystem wishes to defend itself and its interests against those who would prefer to do nothing and allow a malicious actor to destroy both value and trust.
"Lost coins only make everyone else's coins worth slightly more. Think of it as a donation to everyone."
If true, the corollary is:
"Quantum recovered coins only make everyone else's coins worth less. Think of it as a theft from everyone."
The timelines that we are proposing are meant to find the best balance between giving ample ability for account owners to migrate while maintaining the integrity of the overall ecosystem to avoid catastrophic attacks.
Backward Compatibility
As a series of soft forks, older software will continue to operate without modification. Non-upgraded nodes, however, will consider all post-quantum witness programs as anyone-can-spend scripts. They are strongly encouraged to upgrade in order to fully validate the new programs.
Non-upgraded wallets can receive and send bitcoin from non-upgraded and upgraded wallets until Phase A. After Phase A, they can no longer receive from any other wallets and can only send to upgraded wallets. After Phase B, quantum vulnerable funds become unspendable until such time as a quantum safe recovery scheme is implemented and adopted.
Pseudocode Implementation
// This section is a placeholder for the technical pseudocode.
// Detailed implementation logic will be added here.
Changelog
No entries yet.