Skip to content
Merged
Show file tree
Hide file tree
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 7 additions & 0 deletions README.mediawiki
Original file line number Diff line number Diff line change
Expand Up @@ -1247,6 +1247,13 @@ users (see also: [https://en.bitcoin.it/wiki/Economic_majority economic majority
| Hunter Beast, Ethan Heilman, Isabel Foxen Duke
| Specification
| Draft
|-
| [[bip-0361.mediawiki|361]]
| Consensus (soft fork)
| Post Quantum Migration and Legacy Signature Sunset
| Jameson Lopp, Christian Papathanasiou, Ian Smith, Joe Ross, Steve Vaile, Pierre-Luc Dallaire-Demers
| Informational
| Draft
|- style="background-color: #cfffcf"
| [[bip-0370.mediawiki|370]]
| Applications
Expand Down
210 changes: 210 additions & 0 deletions bip-0361.mediawiki
Original file line number Diff line number Diff line change
@@ -0,0 +1,210 @@
<pre>
BIP: 361
Layer: Consensus (soft fork)
Title: Post Quantum Migration and Legacy Signature Sunset
Authors: Jameson Lopp <jameson@lopp.net>
Christian Papathanasiou <cp@gcx.io>
Ian Smith <ianquantum2027@gmail.com>
Joe Ross <joeross7878@gmail.com>
Steve Vaile <steve@qsecdef.com>
Pierre-Luc Dallaire-Demers <pierre-luc@pauli.group>
Status: Draft
Type: Informational
Assigned: 2026-02-11
License: BSD-3-Clause
Requires: TBD Post Quantum Signature BIP
</pre>

== Introduction ==

=== Abstract ===

This proposal follows the implementation of a post-quantum (PQ) output type 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.
Comment thread
jlopp marked this conversation as resolved.
Outdated

'''Phase A''': Disallows sending of any funds to quantum-vulnerable addresses, hastening the adoption of PQ 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.
Comment thread
jlopp marked this conversation as resolved.
Outdated

'''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.
Comment thread
jlopp marked this conversation as resolved.
Outdated

=== 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.
Comment thread
jlopp marked this conversation as resolved.
Outdated

'''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].
Comment thread
jlopp marked this conversation as resolved.

== Specification ==

{| class="wikitable"
|- style="text-align:center;"
! Phase
! What Happens
! Who Must Act
! Time Horizon
|-
| A
| Permitted sends are from legacy scripts to PQ scripts.
| Everyone holding or accepting BTC.
| 160,000 blocks (~3 years) after BIP-361 activation.
Comment on lines +90 to +92
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By enforcing a rule like this in consensus, we would permanently disable sending to anything but P2MR. In the contingency that CRQCs never materialize, it'd be nice to be able to return to P2TR, and this rule would prevent that. We'd have to create an entirely new address format to duplicate P2TR.

I think there's an argument to be made that sending to legacy addresses should eventually become non-standard in mempool policy, but to enforce it in consensus seems too heavy-handed and inflexible to me. It accommodates only the most severe perspective: that CRQCs are inevitable and imminent. Personally, I agree with that perspective, but not everyone does.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Last I checked, P2MR still uses ECDSA and doesn't support any PQ signature schemes.

I don't see much point in a standardness rule given how easy it is to pay miners out of band to prioritize nonstandard transactions these days.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Last I checked, P2MR still uses ECDSA and doesn't support any PQ signature schemes.

P2MR is a hash-based PQ-safe address format, it does not specify how coins are locked/unlocked in script. When/if it is activated, it will be alongside another BIP (currently being drafted) which will enable verifying sigs for at least one PQ cryptosystem in consensus.

I don't see much point in a standardness rule given how easy it is to pay miners out of band to prioritize nonstandard transactions these days.

I believe you wrote the motivation yourself in this BIP:

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.

There is no reason why this rule would need to be enforced by consensus, since it is not immediately security-critical if bypassed. Anyone who willfully bypasses it is doing so only at minor risk to herself. There's no need for the network to coddle people willing to pay mining pools to risk losing money.

This is the same reasoning why sending to non-standard segwit versions, or using OP_SUCCESS codes, etc, is considered non-standard in policy. There's no good reason to do it, and even if you do you'd only be losing your own money. But we don't want to disable it in consensus because we might need those tools someday.

|-
| B
| At a predetermined block height, nodes reject transactions that rely on ECDSA/Schnorr keys.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does "rely on" mean? What about hybrid addresses which blend PQC and ECC?

Also, if this rule goes into consensus unqualified with no rescue protocol to back it up, this would amount to mass confiscation and rescuing those coins would require a hard-fork. I don't think you'll ever get consensus on this.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought about this for a while over the past year and don't think it makes much sense to go too far down the rabbit hole of complex script evaluation. Seems cleaner to just halt verification if an ECC opcode is seen.

Thanks to MAST, wallet devs should be able to construct a variety of spend paths and not have to have a single spend path that requires multiple signature schemes.

Copy link
Copy Markdown
Contributor

@conduition conduition Apr 17, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems cleaner to just halt verification if an ECC opcode is seen.

That would rule out rescue protocols, confiscates hybrid ECC+PQC scripts, and doesn't cover taproot key-spending.

My personal expectation for how this would work is this: When the verifier encounters a BIP340 or ECDSA signature that they must verify, they do so, but then they also enter a follow-up verification step which checks whatever extra rescue protocol condition, e.g. validating the opening of a commit/reveal protocol, or the proof of a ZK-STARK, pulling the necessary metadata from a new transaction or block field. Fail if the associated rescue proof is not found, or is invalid.

| 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.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the single most critical piece of any confiscatory Q-day-freezing proposal. This BIP is incomplete without it IMO.

Rather than writing out a deprecation timeline that depends on TBD cryptography, maybe it'd be better to research that TBD cryptography first and then write a proposal based on what you can confirm to be feasible? I'd be happy to help with this.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed, this is where R&D is needed and it greatly increases likelihood of more people finding the proposal to be acceptable. Draft BIPs aren't set in stone, so I expect 361 to continue to evolve much like 360 did.

| Users who failed to migrate funds before Phase B.
| TBD pending research, demand, and consensus.
|}

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The spec section is really short. Everything else is justification. More details are needed.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, it's far from a spec, just an initial draft of the direction we're headed.

=== 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. '''
Comment thread
jlopp marked this conversation as resolved.
Outdated

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.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You forgot the 4th option: Restrict legacy spending conditions to rule out quantum theft but still permit authentic spending.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn't that fall under number 3? Prevent theft by only permitting authentic spends.


'''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."
Comment thread
murchandamus marked this conversation as resolved.

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.

== Deployment ==

For Bitcoin mainnet, testnet4, and signet, this BIP is deployed by "version bits" with the name "postquantum" and bit 5, using [[bip-0009.mediawiki|BIP9]] modified to use a lower threshold, with an additional ''min_activation_height'' parameter and replacing the state transition logic for the DEFINED, STARTED and LOCKED_IN states as follows:
Comment thread
jlopp marked this conversation as resolved.
Outdated

case DEFINED:
if (GetMedianTimePast(block.parent) >= starttime) {
return STARTED;
}
return DEFINED;

case STARTED:
int count = 0;
walk = block;
for (i = 0; i < 2016; i++) {
walk = walk.parent;
if ((walk.nVersion & 0xE0000000) == 0x20000000 && ((walk.nVersion >> bit) & 1) == 1) {
count++;
}
}
if (count >= threshold) {
return LOCKED_IN;
}
return STARTED;

case LOCKED_IN:
if (block.nHeight < min_activation_height) {
return LOCKED_IN;
}
return ACTIVE;

For Bitcoin mainnet, the starttime is epoch timestamp 1798761600 (midnight 1 January 2027 UTC), the threshold is 1815 blocks (90%) instead of 1916 blocks (95%), and the min_activation_height is block 709632.
Comment thread
jlopp marked this conversation as resolved.
Outdated

For Bitcoin testnet4, the starttime is epoch timestamp 1798761600 (midnight 1 January 2027 UTC), the threshold is 1512 blocks (75%), and the min_activation_height is block 0.

For Bitcoin signet, the starttime is epoch timestamp 1798761600 (midnight 1 January 2027 UTC), the threshold is 1512 blocks (75%), and the min_activation_height is block 0.

=== 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, if activated in conjunction with Phase B, may be soft forkable, otherwise it would likely require a loosening of consensus rules (a hard fork) to allow vulnerable funds to be recovered.

Phase C is also compatible with an "Hourglass" style BIP for spending P2PK encumbered funds, provided such a BIP has activated by the time Phase C activates. BIP-361 authors support Hourglass for P2PK because it's not possible to construct a proof of HD wallet ownership for UTXOs created before BIP-32 existed.