-
Notifications
You must be signed in to change notification settings - Fork 5.7k
BIP draft: Quantum Migration #1895
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,174 @@ | ||
<pre> | ||
BIP: TBD | ||
Title: Post Quantum Migration and Legacy Signature Sunset | ||
Layer: Consensus (soft fork) | ||
Author: Jameson Lopp <[email protected]> | ||
Christian Papathanasiou <[email protected]> | ||
Ian Smith <[email protected]> | ||
Joe Ross <[email protected]> | ||
Steve Vaile <[email protected]> | ||
Pierre-Luc Dallaire-Demers <[email protected]> | ||
Comments-Summary: No comments yet. | ||
Comments-URI: TBD | ||
Status: Draft | ||
Type: Standards Track | ||
Created: 2025-07-14 | ||
License: BSD-3-Clause | ||
Requires: P2QRH as described in BIP-360 | ||
jlopp marked this conversation as resolved.
Show resolved
Hide resolved
|
||
</pre> | ||
|
||
== Introduction == | ||
|
||
=== 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. | ||
jlopp marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
'''Phase A''': Disallows sending of any funds to quantum-vulnerable addresses, hastening the adoption of P2QRH address types. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It should be non-standard, instead of being entirely blocked. Because OP_CHECKSIG can still remain useful, if you will do something more, than just |
||
|
||
'''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. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It should be timelocked, and that timelock can be many years into the future. It could be also expressed as some future block number. Timelocking is better than burning, because then, future adjustments can be made as soft-forks, instead of being hard-forks. Also, in the meantime, people with frozen funds can still make second-layer transactions, protected by quantum proofs, to change on-chain coin ownership, without making any on-chain transactions, for the time when funds will be frozen. And then, the last coin owners could make a valid on-chain transaction, with classical ECDSA signature, and with quantum proof, that the whole chain of quantum signatures is correct. |
||
|
||
'''Phase C''' (optional): Pending further research and demand, a separate BIP proposing a method to allow quantum safe recovery of legacy UTXOs, potentially via ZK proof of possession of a corresponding BIP-39 seed phrase. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Legacy UTXOs should be moved in exactly the same way as they are today, to let old nodes understand it, and follow the heaviest chain in a backward-compatible way. New quantum commitments can be stored in the witness space, or some kind of second witness (which I call "commitment"). Existing non-quantum nodes should not process any quantum data at all, just like non-Segwit nodes don't know anything about witness space in Segwit transactions. For each and every OP_CHECKSIG call in any existing form, there should be a valid commitment, which would be processed only by upgraded nodes. It would also let some new quantum schemes to compete more fairly with others, because then, the size of the quantum proof is not restricted by the current max block size limit, and can be changed by a future soft-fork, if needed. For example: instead of |
||
|
||
=== 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 an 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, [https://www.mckinsey.com/~/media/mckinsey/business%20functions/mckinsey%20digital/our%20insights/the%20year%20of%20quantum%20from%20concept%20to%20reality%20in%202025/quantum-monitor-2025.pdf?shouldIndex=false per McKinsey]. | ||
|
||
'''Quantum algorithms are rapidly improving''' | ||
|
||
The safety envelope is shrinking by dramatic increases in algorithms even if the pace of hardware improvements is slower. Algorithms are [https://security.googleblog.com/2025/05/tracking-cost-of-quantum-factori.html improving up to 20X], lowering the theoretical hardware requirements for breaking classical encryption. | ||
|
||
'''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 P2PK (and other outputs with exposed pubkeys) 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 wallets, exchanges, miners, and custodians. 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 === | ||
|
||
'''Resilience''': Bitcoin protocol remains secure for the foreseeable future without waiting for a 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 remain unspendable, reducing supply, as [https://bitcointalk.org/index.php?topic=198.msg1647#msg1647as Satoshi described]. | ||
|
||
== Specification == | ||
|
||
{| class="wikitable" | ||
|- style="text-align:center;" | ||
! Phase | ||
! What Happens | ||
! Who Must Act | ||
! Time Horizon | ||
|- | ||
| A | ||
| Permitted sends are from legacy scripts to P2QRH scripts. | ||
jlopp marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| Everyone holding or accepting BTC. | ||
| 3 years after BIP-360 implementation. | ||
|- | ||
| B | ||
| At a predetermined block height, nodes reject transactions that rely on ECDSA/Schnorr keys. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'd be interested an expanded rationale for the approach of rejecting transactions that rely on ECDSA/Schnorr keys vs freezing quantum vulnerable outputs.
The approach you propose would definitely prevent more thief long term. What is the delta between this and freezing all quantum vulnerable outputs in terms of vulnerable bitcoins? Is the mechanism to determine if a transaction is reject, if OP_CHECKSIG appears in the script? If someone did a Schnorr CHECKSIG and a PQ signature CHECKSIG_ML, would that be rejected? Probably right, that would be the more simple check. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Added more details to say reject any of the checksig opcodes. I suppose the logic could be "reject all checksig opcodes unless there is also a checksig_ml opcode" if we felt like someone might footgun their funds. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That's a good approach since you can still have Schnorr OP_CHECKSIG tapscripts in tapleafs without breaking OP_CHECKSIG_ML tapscripts. This would break OP_CAT based covenants since they use OP_CHECKSIG in a quantum safe way to verify the txhash of the transaction on the stack. This suggests that if we want OP_CAT, we probably also want OP_PUSH_TXHASH so that people don't use OP_CHECKSIG for covenants. |
||
| Everyone holding or accepting BTC. | ||
| 2 years after Phase A activation. | ||
|- | ||
| C | ||
| Users with frozen quantum vulnerable funds and a HD wallet seed phrase can construct a quantum safe proof to recover funds. | ||
| Users who failed to migrate funds before Phase B. | ||
| TBD pending research, demand, and consensus. | ||
|} | ||
|
||
=== 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 . | ||
jlopp marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
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 redistribution dilemma. There are 3 types of proposals: | ||
|
||
1. Allow anyone to steal vulnerable coins, benefitting those who reach quantum capability earliest. | ||
|
||
2. Allow throttled theft of coins, which leads to RBF battles and ultimately miners subsidizing their revenue from quantum recovered coins. | ||
|
||
3. 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 corresponding to a public key hash or script hash would provide a trustless means for legacy outputs to be spent in a quantum resistant manner, even after the sunset. | ||
|
||
{| class="wikitable" | ||
|- style="text-align:center;" | ||
! Stakeholder | ||
! Incentive to Upgrade | ||
|- | ||
| Miners | ||
| • Larger size PQ signatures along with incentive for users to migrate will create more demand for block space and thus higher fees collected by miners.<br /><br />• Post-Phase B, non-upgraded miners produce invalid blocks.<br /><br />• A quantum attack on Bitcoin will significantly devalue both their hardware and Bitcoin as a whole. | ||
|- | ||
| Institutional Holders | ||
| • Fiduciary duty: failing to act to prevent a quantum attack on Bitcoin would violate the fiduciary duty to shareholders. <br /><br />• Demonstrating Bitcoin's ability to effectively mitigate emerging threats will prove Bitcoin to be an investment grade asset. | ||
|- | ||
| Exchanges & Custodians | ||
| • Concentrated risk: a quantum hack could bankrupt them overnight.<br /><br />• Early migration is cheap relative to potential losses, potential lawsuits over improper custody and reputational damage. | ||
|- | ||
| Individual Holders | ||
| • Peace of mind against theft and significant devaluation of holdings.<br /><br />• Sunset date creates a clear deadline and incentive to improve their security rather than an open-ended "some day" that invites procrastination. | ||
|- | ||
| Attackers | ||
| Economic incentive diminishes as sunset nears, stolen coins cannot be spent after Q-day. | ||
|} | ||
|
||
'''Key Insight''': As mentioned earlier, the proposal turns quantum security into a private incentive to upgrade. | ||
|
||
This is not an offensive attack, rather, it is defensive: our thesis is that 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." - Satoshi Nakamoto | ||
|
||
If true, the corollary is: | ||
|
||
"Quantum recovered coins only make everyone else's coins worth less. Think of it as a theft from everyone." | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
This is an opinionated framing of the situation. I believe I provided another framing of it as "additional proof-of-work mining along SHA-pow-mining" (see #1895 (comment) ). I suggest we keep the BIP as neutral as possible without inserting arbitrary framing that conveys some specific opinion whether something is positive or negative. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That framing is unfounded, because miners are paid to publish updates to Bitcoin’s blockchain, while there is no direct benefit to the Bitcoin ecosystem to incentivize quantum computer development by allowing quantum computer operators to misappropriate funds. |
||
|
||
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 nodes 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, both senders and receivers will require upgraded wallets. Phase C may require a loosening of consensus rules (a hard fork) to allow vulnerable funds recovery via ZK proofs, though if activated in conjunction with Phase B it may be soft forkable. |
Uh oh!
There was an error while loading. Please reload this page.