A Post Quantum Migration Proposal

[Jameson Lopp]

Building upon my earlier essay against allowing quantum recovery of bitcoin I wish to formalize a proposal after several months of discussions.

This proposal does not delve into the multitude of issues regarding post quantum cryptography and trade-offs of different schemes, but rather is meant to specifically address the issues of incentivizing adoption and migration of funds after consensus is established that it is prudent to do so.

As such, this proposal requires P2QRH as described in BIP-360 or potential future proposals.

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 fork to allow recovery of legacy UTXOs through ZK proof of possession of BIP-39 seed phrase.  

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. [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 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 at a Glance

• 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 become unspendable, reducing supply, as Satoshi described.  

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.	2 years after Phase A activation.
Phase C – Re-enable spends from quantum vulnerable outputs via ZK Proof	Users with frozen quantum vulnerable funds and a HD wallet seed phrase can construct a quantum safe ZK 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 . 

• 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.  

1. 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 lost coins.

3. Allow no one to steal vulnerable coins.

• Minimizes attack surface

1. By disallowing new spends to quantum vulnerable script types, we minimize the attack surface with each new UTXO.  

2. Upgrades to Bitcoin have historically taken many years; this will hasten and speed up the adoption of new quantum resistant script types. 

3. With a clear deadline, industry stakeholders will more readily upgrade existing infrastructure to ensure continuity of services.  

• Minimizes loss of access to funds 

1. 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.  

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. • Post-Phase B, non-upgraded miners produce invalid blocks. • 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.   • 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. • Early migration is cheap relative to potential losses, potential lawsuits over improper custody and reputational damage.
Everyday Users	• Self-sovereign peace of mind. • 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."

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 would likely require a loosening of consensus rules (a hard fork) to allow vulnerable funds recovery via ZK proofs.

[Tadge Dryja]

Hi  

While I generally agree that "freeze" beats "steal", and that a lot of lead time is good, I don't think this plan is viable.
To me the biggest problem is that it ties activation of a PQ output type to *de*activation of EC output types.  That would mean that someone who wants to keep using all the great stuff in libsecp256k1 should try to prevent BIP360 from being activated.

Sure, there can be risks from CRQCs.  But this proposal would go the other direction, disabling important functionality and even destroying coins preemptively, in anticipation of something that may never happen.

Also, how do you define "quantum-vulnerable UTXO"?  Would any P2PKH, or P2WPKH output count?  Or only P2PKH / P2WPKH outputs where the public key is already known?  I can understand disabling spends from known-pubkey outputs, but for addresses where the public key has never been revealed, commit/reveal schemes (like the one I posted about & am working on a follow-up post for) should safely let people spend from those outputs indefinitely.

With no evidence of a QRQC, I can see how there would be people who'd say "We might never really know if a CRQC exists, so we need to disable EC spends out of caution" and others who'd say "Don't disable EC spends, since that's destroying coins", and that could be a persistent disagreement.  But I hope if we did in fact have a proof that a CRQC has broken secp256k1, there would be significant agreement on freezing known-pubkey EC outputs.

-Tadge

[Antoine Riard]

Hi Jameson,

Thanks for your thoughts on this complex subject.

First and foremost, I think your following statement: "Never before has Bitcoin faced
an existential threat to its cryptographic primitives" is very myopic, given that
cryptanalysts and number theorists are making progress every year in their works, and
each bitcoin cryptographic primitive has been and is constantly analyzed to uncover
potential weaknesses.

So in my view the quantum threat is a bit less specific that the image you're painting
of it. Even if go all to upgrade to lattices-based schemes, we have no certainty that
novels flaws won't be found, one can just go to see the modifications of the NIST-approved
schemes in between their rounds of selection that we'll never reach something like
"self-sovereign peace of mind"...Unless we start to forbid people of practicing the
art of mathematics, practice which has been ongoing since Euclide and Pythagore...

I do concede that quantum is a bit different, as after all new physics paradigm
do not happen often (Heisenberg published in the 20s iirc), though that's in my
view the flaw of your reasoning as you're assuming some "post-quantum" upgraded
state where bitcoin, as a community and a network, would be definitely safe from
advances in applied science. At minima, in my understanding, you're arguing this
time is different to justify extra-ordinary technical measures never seen before,
namely the freezing of "vulnerable" coins.

I'm worried this is opening a Pandora box, where we would introduce a precedent
that it is legitimate as a community to technicaly confiscate some coins of users,
without their _consents_, for extra-ordinary reasons. That's opening a worms of
shenanigans in the future...There is no guarantee that this precedent won't
be leveraged in the future by any group of entities to justify future upgrades
eroding one of the "fundamental property" you're yourself deeming as valuable.

This is especially worrying as if I'm understanding you correctly you're justifying
this position as that somehow we should protect the price of the currency as an end
in itself (i.e "Beyond its impact on price, ..."). It's unclear the price of bitcoin
versus what fiat or hard asset (e.g oil) you have in mind. And in anyway, as far
as I know, none of the bitcoin devs is seating on the board of the FED, the ECB
or the BoJ...

To put it simply, even if a quantum attacker can tomorrow starts to steal
vulnerable coins, 1 BTC will be always equal to 1 BTC. Full stop. In my humble
opinion, let's not introduce the idea that, we, as a community of stakeholders
and developers we have a positive "fiduciary" duty to act to maintain the price
of bitcoin in some "monetary snake" with another class of assets...

That's also the problem with game theory, all the matrices of analysis are
based on some scale of utilitarism. See Von Neuman's Theory of Games, the
section on "The Notion of Utility". My subjective appreciation of the value
of my coins might not be your subjective appreication of the value of your
coins.

Now I do understand the perspective of the institutional holders, the exchanges,
the custodians or any other industry providers, who might be in the full uncertainty
about their business responsibilities in case of a quantum threat affecting their
custodied coins. But, first legally speaking there is something call "force majeure"
and in view of the quantum threat, which is a risk discussed far beyond the bitcoin
industry, they should be able to shield themselves behind that. Secondly, if there
is any futute upgrade "opt-in" only path a la BIP360, you can move your funds or
the ones under custody  under a PQC scheme like Dilthium or Falcon and be good
without caring about what the others users are doing. Thirdly, if you're an actor
in the industry like Coinbase and you're deeply concerned about how extended maelstrom
on the price might affect the viability of your operations, it is unclear to me why
you don't call MunichRe or any other company like that tomorrow to craft and be
covered by specific insurance on quantum threats...

To be frank, all those considerations on how "I cannot see how the currency can
maintain any value at all in such a setting", is a strong red flag of low time
preferences. It's not like we're used to strong volatility in bitcoin with the
almost 2 decades of operations of the network. In my view, it's more a hint of
very high-exposition by some to a single class of asset, i.e bitcoin, rather than wise
diversification... And a push to sacrify a "fundamental property" i.e "conservatism"
in view of short-term concerns (i.e the stability of the currency price along
a period of few years).

Do not get me wrong, I'm certainly not of the school "let's reward quantum
attackers". Leveraging techical superiority and employing CRQRC to steal
vulnerable coins would be clearly a theft. But ethically, the best we can do is
to have an opt-in upgrade path and be pro-active, by education and outreach,
to have the maximum of coin owners upgrading to non-vulnerable addresses types.
Then show the level of "fortitude" or "endurance" as a community in face of price
fluctuations for a while, while seeing regularly old P2PK coins hacked. Marcus
Aurelius can be bought for few bucks in most of decent libraries...

I'm definitely on the "no old coins confiscation" position you're underlighting:

"I don't see why old coins should be confiscated. The better option is to let
those with quantum computers free up old coins. While this might have an
inflationary impact on bitcoin's price, to use a turn of phrase, the inflation
is transitory. Those with low time preference should support returning lost
coins to circulation".

Notwhitstanding that I disagree with your position, one can only appreciate
the breadth and depth with which you're gathering and articulating all the
elements on this complex problem.

Best,
Antoine
OTS hash: c064b43047bf3036faf098b5ac8e74930df63d25629f590a4195222979402826

[Jameson Lopp]

On Sun, Jul 13, 2025 at 7:53 PM Tadge Dryja <r...@awsomnet.org> wrote:

Hi  

While I generally agree that "freeze" beats "steal", and that a lot of lead time is good, I don't think this plan is viable.
To me the biggest problem is that it ties activation of a PQ output type to *de*activation of EC output types.  That would mean that someone who wants to keep using all the great stuff in libsecp256k1 should try to prevent BIP360 from being activated.

Right. I don't see much point enabling PQ cryptography that has significant performance trade-offs to ECC if it's not actually necessary. And if it is actually necessary, then ECC usage becomes an existential risk. Note that this BIP makes no plans about enabling PQC; it's written under the assumption that PQC has been deemed necessary.

Sure, there can be risks from CRQCs.  But this proposal would go the other direction, disabling important functionality and even destroying coins preemptively, in anticipation of something that may never happen.

I don't expect PQC to be activated until there is widespread consensus that CRQCs are more than mythological FUD. We can only hope that if and when that happens it still provides enough time for the ecosystem to react and protect itself.

Also, how do you define "quantum-vulnerable UTXO"?  Would any P2PKH, or P2WPKH output count?  Or only P2PKH / P2WPKH outputs where the public key is already known?  I can understand disabling spends from known-pubkey outputs, but for addresses where the public key has never been revealed, commit/reveal schemes (like the one I posted about & am working on a follow-up post for) should safely let people spend from those outputs indefinitely.

A quantum vulnerable UTXO is any that is susceptible to both long and short range attacks. Or in other words, any UTXO that isn't using whatever PWC scheme is settled upon.

 

With no evidence of a QRQC, I can see how there would be people who'd say "We might never really know if a CRQC exists, so we need to disable EC spends out of caution" and others who'd say "Don't disable EC spends, since that's destroying coins", and that could be a persistent disagreement.  But I hope if we did in fact have a proof that a CRQC has broken secp256k1, there would be significant agreement on freezing known-pubkey EC outputs.

Quite true; and this BIP is not for today, but for a potential future day in which the threat landscape has evolved.

 

--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/37ed2e5d-34cd-4391-84b8-5bcc6d42c617n%40googlegroups.com.

[Jameson Lopp]

On Mon, Jul 14, 2025 at 10:09 AM Antoine Riard <antoin...@gmail.com> wrote:

Hi Jameson,

Thanks for your thoughts on this complex subject.

First and foremost, I think your following statement: "Never before has Bitcoin faced
an existential threat to its cryptographic primitives" is very myopic, given that
cryptanalysts and number theorists are making progress every year in their works, and
each bitcoin cryptographic primitive has been and is constantly analyzed to uncover
potential weaknesses.

So in my view the quantum threat is a bit less specific that the image you're painting
of it. Even if go all to upgrade to lattices-based schemes, we have no certainty that
novels flaws won't be found, one can just go to see the modifications of the NIST-approved
schemes in between their rounds of selection that we'll never reach something like
"self-sovereign peace of mind"...Unless we start to forbid people of practicing the
art of mathematics, practice which has been ongoing since Euclide and Pythagore...

I do concede that quantum is a bit different, as after all new physics paradigm
do not happen often (Heisenberg published in the 20s iirc), though that's in my
view the flaw of your reasoning as you're assuming some "post-quantum" upgraded
state where bitcoin, as a community and a network, would be definitely safe from
advances in applied science. At minima, in my understanding, you're arguing this
time is different to justify extra-ordinary technical measures never seen before,
namely the freezing of "vulnerable" coins.

Correct, this time is different in that we're not talking about vague unknown weaknesses. Rather, we're talking about a known algorithm that makes breaking cryptographic primitives orders of magnitude cheaper.

The unknown becomes the rate at which advancements in quantum computing will be achieved, which is concerning given the funding going into pushing said advancements forward.

 

I'm worried this is opening a Pandora box, where we would introduce a precedent
that it is legitimate as a community to technicaly confiscate some coins of users,
without their _consents_, for extra-ordinary reasons. That's opening a worms of
shenanigans in the future...There is no guarantee that this precedent won't
be leveraged in the future by any group of entities to justify future upgrades
eroding one of the "fundamental property" you're yourself deeming as valuable.

This is a fair fear, though the counterpoint is that it is legitimate for the community to protect itself against security threats. It just so happens that both viewpoints can be valid.

This is especially worrying as if I'm understanding you correctly you're justifying
this position as that somehow we should protect the price of the currency as an end
in itself (i.e "Beyond its impact on price, ..."). It's unclear the price of bitcoin
versus what fiat or hard asset (e.g oil) you have in mind. And in anyway, as far
as I know, none of the bitcoin devs is seating on the board of the FED, the ECB
or the BoJ...

To put it simply, even if a quantum attacker can tomorrow starts to steal
vulnerable coins, 1 BTC will be always equal to 1 BTC. Full stop. In my humble
opinion, let's not introduce the idea that, we, as a community of stakeholders
and developers we have a positive "fiduciary" duty to act to maintain the price
of bitcoin in some "monetary snake" with another class of assets...

Protocol developers have no fiduciary duty to bitcoin holders. I wouldn't argue they have any duty whatsoever to users.

Bitcoin is not (yet) a unit of account. The ecosystem does not run on 1 BTC = 1 BTC. The purchasing power of satoshis is very much relevant to the health and sustainability of the ecosystem at its current level.

I would not claim that "devs must do something" - rather, I believe that the incentives of other groups I outlined will roughly align them with my thinking.

That's also the problem with game theory, all the matrices of analysis are
based on some scale of utilitarism. See Von Neuman's Theory of Games, the
section on "The Notion of Utility". My subjective appreciation of the value
of my coins might not be your subjective appreication of the value of your
coins.

Now I do understand the perspective of the institutional holders, the exchanges,
the custodians or any other industry providers, who might be in the full uncertainty
about their business responsibilities in case of a quantum threat affecting their
custodied coins. But, first legally speaking there is something call "force majeure"
and in view of the quantum threat, which is a risk discussed far beyond the bitcoin
industry, they should be able to shield themselves behind that. Secondly, if there
is any futute upgrade "opt-in" only path a la BIP360, you can move your funds or
the ones under custody  under a PQC scheme like Dilthium or Falcon and be good
without caring about what the others users are doing. Thirdly, if you're an actor
in the industry like Coinbase and you're deeply concerned about how extended maelstrom
on the price might affect the viability of your operations, it is unclear to me why
you don't call MunichRe or any other company like that tomorrow to craft and be
covered by specific insurance on quantum threats...

Agreed that companies may be legally protected from lawsuits. Not sure about the insurance angle, though I'd see that as a one time payout that could very well come at the expense of said business ceasing operations. I suspect few businesses would be happy with that.

Unfortunately I don't think opt-in security suffices in this situation. Human nature is to procrastinate and if the incentives are insufficient to motivate mass migration to quantum secure schemes, Q-Day will be quite unpleasant.

 

To be frank, all those considerations on how "I cannot see how the currency can
maintain any value at all in such a setting", is a strong red flag of low time
preferences. It's not like we're used to strong volatility in bitcoin with the
almost 2 decades of operations of the network. In my view, it's more a hint of
very high-exposition by some to a single class of asset, i.e bitcoin, rather than wise
diversification... And a push to sacrify a "fundamental property" i.e "conservatism"
in view of short-term concerns (i.e the stability of the currency price along
a period of few years).

Bitcoin has many inviolable properties and some of them are actually in conflict with each other. Conservatism and property rights are clearly on the table in this matter.

But shouldn't one of Bitcoin's fundamental properties be the fact that it can be upgraded? That it can respond to new challenges and threats?

Beyond just the quantum computing issue, I expect the above to create continued conflict between ossifiers and developers over the long term.

Do not get me wrong, I'm certainly not of the school "let's reward quantum
attackers". Leveraging techical superiority and employing CRQRC to steal
vulnerable coins would be clearly a theft. But ethically, the best we can do is
to have an opt-in upgrade path and be pro-active, by education and outreach,
to have the maximum of coin owners upgrading to non-vulnerable addresses types.
Then show the level of "fortitude" or "endurance" as a community in face of price
fluctuations for a while, while seeing regularly old P2PK coins hacked. Marcus
Aurelius can be bought for few bucks in most of decent libraries...

Beware the blurry line between stoicism and apathy.

How well will it play out if we can say "well, we could have stopped a massive threat but chose not to, because we were confident the system would survive."

The alternative path is "we saw a threat coming and the community collaborated to neutralize it before massive harm occurred."

Both scenarios show resilience. Which evokes greater confidence?

--

You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/4d9ce13e-466d-478b-ab4d-00404c80d620n%40googlegroups.com.

[Ethan Heilman]

I want to clarify two points:

> Even if go all to upgrade to lattices-based schemes, we have no certainty that novels flaws won't be found, one can just go to see the modifications of the NIST-approved schemes in between their rounds of selection that we'll never reach something like "self-sovereign peace of mind"...

The informational proposal for post-quantum signatures in BIP-360 has one lattice-based scheme and one hash-based scheme (SLH-DSA SPHINCS+). The intention of including a hash-based scheme is to ensure that there will always be at least one signature scheme in Bitcoin that is secure. Cryptographic hashes are considered one of the safest assumptions possible and are used throughout Bitcoin (merkle tree, PoW, TXID, etc...).

Using P2QRH + SLH_DSA, you can have:
- a tapleaf for SLH-DSA
- and a tapleaf for a more efficient signature scheme (ML-DSA, Schnorr, whatever)

Then no matter what happens to any of the other signature schemes, you can use that SLH-DSA tapleaf to spend safely. This strategy isn't just about quantum resistance but protecting against unexpected cryptanalytic breakthroughs. If I wanted to store Bitcoins in cold storage for 100 years, this is how I would do it.

>  This is especially worrying as if I'm understanding you correctly you're justifying this position as that somehow we should protect the price of the currency as an end in itself (i.e "Beyond its impact on price, ..."). It's unclear the price of bitcoin versus what fiat or hard asset (e.g oil) you have in mind. [...] To put it simply, even if a quantum attacker can tomorrow starts to steal vulnerable coins, 1 BTC will be always equal to 1 BTC. Full stop.

I can't speak for Jameson, but let me put forward my own concern. If miners can buy much less electricity for 1-BTC this is a major problem for Bitcoin. If the price of electricity denominated in Bitcoin goes way up, miners will have to mine at a massive loss. Many will stop mining, then the block rate will go down and Bitcoin will appear to be less valuable (high fees, slow confirmation, panic), which makes mining even more of a loss, and so on. This also invites miners who have nothing left to lose to engage in mining attacks.

One reason I believe a soft fork to freeze quantum vulnerable coins is likely, is that miners will be incentivized to mine on such a soft fork. The non-frozen chain will simply not be affordable to mine on and will be abandoned. In the moment of crisis, all someone has to do is create a client that does a soft fork freeze of quantum vulnerable coins and the miner will have no choice but to adopt it or stop mining. The worst time to do a soft fork like this would be in a moment of crisis.

Note that such a death spiral and the incentives for a soft fork are possible prior to quantum attacks on Bitcoin. Merely the threat of quantum attacks and the widespread belief that Bitcoin will not freeze unspendable coins and thereby inflate the supply of spendable bitcoin.

On Mon, Jul 14, 2025 at 10:09 AM Antoine Riard <antoin...@gmail.com> wrote:

--

[conduition]

Hi Jameson,

I like your proposal, and economically so should anyone who owns Bitcoin. I don't see any solid incentive-based motivation to let QCs "free up" vulnerable coins, other than maybe as an early-warning indicator. This is impossible to prove, but I personally believe almost all dormant bitcoins that would be locked by phase B are already permanently lost (dead addresses, dead owners, etc).

I do think we should delay phase B as long as we can, to give as many people time to upgrade as possible. The time horizons should be flexible and allow us to react to changes, in case practical quantum computers take much more/less time to arrive than we expect today.

Commit/reveal protocols described in other mailing list threads are a tempting way to rescue some quantum-vulnerable funds, without the complexity of zk-STARKs... but these protocols would be difficult to explain to users, and they only work for addresses whose pubkeys haven't been exposed yet. This makes implementation hard. It rules out many existing UTXOs, and all P2TR UTXOs too. At this point I don't feel commit/reveal is worth the engineering effort and research given those limitations. It's reasonable that you left these out of your proposal.

It's true that phase C would require a hard fork if we first deploy phase B, because phase B explicitly closes the door on spending from pre-quantum addresses. However, I believe zk-STARK proof unlocking could be executed as a soft fork if you combine phases B and C together into a single upgrade. This way, there is never a delta in the consensus rules in which EC spending rules need to be relaxed. 

• Before: allow spending P2PKH if given a valid sig/pubkey. 
• After: allow spending P2PKH if given a valid sig/pubkey AND a valid ZK proof of seed-phrase-based key derivation (e.g. BIP39). 
  

With this combined approach, we would never see a period of time in which average users with mnemonic-seed wallets are locked out of their funds, and we need no hard forks at all.

regards,

conduition

--

You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CADL_X_fpv-aXBxX%2BeJ_EVTirkAJGyPRUNqOCYdz5um8zu6ma5Q%40mail.gmail.com.

[Boris Nagaev]

On Monday, July 14, 2025 at 4:06:17 PM UTC-3 Ethan Heilman wrote:

I want to clarify two points:

> Even if go all to upgrade to lattices-based schemes, we have no certainty that novels flaws won't be found, one can just go to see the modifications of the NIST-approved schemes in between their rounds of selection that we'll never reach something like "self-sovereign peace of mind"...

The informational proposal for post-quantum signatures in BIP-360 has one lattice-based scheme and one hash-based scheme (SLH-DSA SPHINCS+). The intention of including a hash-based scheme is to ensure that there will always be at least one signature scheme in Bitcoin that is secure. Cryptographic hashes are considered one of the safest assumptions possible and are used throughout Bitcoin (merkle tree, PoW, TXID, etc...).

Using P2QRH + SLH_DSA, you can have:
- a tapleaf for SLH-DSA
- and a tapleaf for a more efficient signature scheme (ML-DSA, Schnorr, whatever)

Then no matter what happens to any of the other signature schemes, you can use that SLH-DSA tapleaf to spend safely. This strategy isn't just about quantum resistance but protecting against unexpected cryptanalytic breakthroughs. If I wanted to store Bitcoins in cold storage for 100 years, this is how I would do it.

>  This is especially worrying as if I'm understanding you correctly you're justifying this position as that somehow we should protect the price of the currency as an end in itself (i.e "Beyond its impact on price, ..."). It's unclear the price of bitcoin versus what fiat or hard asset (e.g oil) you have in mind. [...] To put it simply, even if a quantum attacker can tomorrow starts to steal vulnerable coins, 1 BTC will be always equal to 1 BTC. Full stop.

I can't speak for Jameson, but let me put forward my own concern. If miners can buy much less electricity for 1-BTC this is a major problem for Bitcoin. If the price of electricity denominated in Bitcoin goes way up, miners will have to mine at a massive loss. Many will stop mining, then the block rate will go down and Bitcoin will appear to be less valuable (high fees, slow confirmation, panic), which makes mining even more of a loss, and so on. This also invites miners who have nothing left to lose to engage in mining attacks.

One reason I believe a soft fork to freeze quantum vulnerable coins is likely, is that miners will be incentivized to mine on such a soft fork. The non-frozen chain will simply not be affordable to mine on and will be abandoned. In the moment of crisis, all someone has to do is create a client that does a soft fork freeze of quantum vulnerable coins and the miner will have no choice but to adopt it or stop mining. The worst time to do a soft fork like this would be in a moment of crisis.

The original chain, where P2PK coins are not frozen, could actually generate significant fees for miners -- especially if multiple parties with quantum computers are competing to claim the same outputs. While the price of 1 BTC on that chain might be lower, miners' profits (measured in dollars or in electricity) could still be higher. As a result, miners may be incentivized to switch to that chain in order to collect a cut of P2PK coins.

However, the more important factor is where holders choose to go. There will be a market to trade coins between the original chain and the fork that implements freezing. Everyone who held satoshis prior to the fork will have an equal number of satoshis on both chains, and each individual will decide which to keep and which to convert on the market. The market will ultimately answer the question: what matters more -- preventing private theft via quantum computers, or preventing organized confiscation through consensus rules?

 

Note that such a death spiral and the incentives for a soft fork are possible prior to quantum attacks on Bitcoin. Merely the threat of quantum attacks and the widespread belief that Bitcoin will not freeze unspendable coins and thereby inflate the supply of spendable bitcoin.

Eventually, facts, not fears, are what matter. If quantum attacks do not materialize, someone could buy discounted bitcoins and profit later when, after several years, the attacks still haven't occurred.

[Ethan Heilman]

>  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. Reading through this, an idea occurred to me. Failure to freeze the coins might incentivize attackers to claim they are performing a quantum attack or incentivize victims of hacks to blame a quantum attack. We may see fake quantum attacks before we see real ones and we may not be able to tell the difference.

Consider an attacker who manages to acquire the spending keys to quantum vulnerable outputs considered to be lost because they haven't been spent in a long period of time. They could announce they will be performing a quantum attack and then spend those outputs as evidence. They could then short Bitcoin to profit. If this caused a panic, it is likely that other outputs, assumed to be lost, would be spent as holders attempt to secure their funds. This would look a lot like a quantum attack.

Imagine if a massive exchange hack happened a few years in the future as CRQC is looking more and more real. The hacked exchange could deflect responsibility by saying it was a quantum attack since everything was stored in a cold wallet and a quantum attack is the only possible way it could have happened. An executive at such an exchange may even convince themselves that this is the best way to make their customers whole again. They cause a panic then use the lower price to buy Bitcoin cheaper and then announce they "discovered" the real cause of the hack and it wasn't a quantum computer.

Well reasoned technical arguments about why something isn't a quantum attack will lose to headlines unless it is beyond a reasonable doubt that a quantum attack could not have taken place due to the vulnerable coins being frozen.

--

You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CADL_X_fpv-aXBxX%2BeJ_EVTirkAJGyPRUNqOCYdz5um8zu6ma5Q%40mail.gmail.com.

[Boris Nagaev]

Hi Conduition, hi Jameson, hi all!

What if all vulnerable coins are temporarily locked during phase B, with a clearly defined future block height X (e.g., in 5-10 years) at which point these coins become EC-spendable again? This would give us time to develop recovery mechanisms for phase C. It also wouldn't require a hard fork, since the unlocking height X would already be part of the consensus rules introduced in phase B. In this way, we avoid a hard fork altogether. Instead of permanent freezing, a forced timelock would be applied to vulnerable outputs.

Beyond merely avoiding a hard fork, this approach offers additional benefits. It improves the situation for owners of vulnerable coins who missed the initial deadline, since a timelock is preferable to permanent freezing. To be clear, I am not advocating for locking the coins -- even temporarily. However, if a choice must be made, temporary locking is clearly preferable to permanent freezing. Developers working on recovery mechanisms would have a clear timeline and incentive to deliver phase C as a subsequent soft fork. At the same time, the community gains valuable time for data-driven decision-making -- allowing us to adapt based on how events unfold, including whether legitimate claims are made on locked coins, and based on future developments in quantum computing.

This assumes that phases A and B are deployed before a real quantum threat materializes. If, in the meantime, fundamental research concludes that quantum computing will not break EC for the next 100 years, we can simply do nothing -- and the coins will unlock automatically at height X. On the other hand, if quantum computing advances significantly, we can respond based on the availability and quality of recovery schemes: either deploy a recovery soft fork at block X, or apply another soft fork to postpone unlocking by another 5-10 years.

Best,

Boris

[conduition]

Hey Boris and list,

What if all vulnerable coins are temporarily locked during phase B, with a clearly defined future block height X (e.g., in 5-10 years) at which point these coins become EC-spendable again?

Great idea. It gives us more time to get the zk-STARK proof system for phase C tightened up, but we still have the option of deploying phase B independently to protect procrastinators against a fast-arriving quantum adversary, even if the STARK system isn't ready yet. If quantum progress is slower (or phase C development is faster) than anticipated, we also have the option to merge the phases B and C together into a single deployment.

If we do that, should we apply the same logic to phase A though, and eventually permit sending to pre-quantum addresses at height X? Because as described, once phase A is locked in, we can never again permit sending to pre-quantum addresses (without a hard fork).

Maybe we should also talk about BIP360 P2QRH addresses and how they'd be treated by these phases. As Ethan pointed out, P2QRH addresses can contain EC signature spending conditions (OP_CHECKSIG). Would phase B's stricter rules also block EC spends from P2QRH UTXOs?

If yes, and phase B restricts EC spending from P2QRH, users may accidentally send money to P2QRH addresses whose leafs all require at least one EC signature opcode. This locks the money up until phase C, even though the purpose of phase A was to avoid exactly this from happening. Restricting P2QRH EC spending also makes hybrid spending conditions, which require both EC signatures and PQ signatures for extra safety, harder to implement explicitly in P2QRH script - We'd need dedicated EC/PQ hybrid checksig opcodes (which is an option if we want it).

If no, and phase B doesn't restrict EC spending from P2QRH, then P2QRH UTXOs with exposed EC spending leafs will be even more vulnerable to a quantum attacker than those who have exposed pubkeys in pre-quantum UTXOs: Pre-quantum UTXOs would have better protection, since they are temporarily locked by phase B but P2QRH UTXOs aren't.

Personally i think phase B should restrict ALL EC spending across all script types, because at least then users can eventually reclaim their BTC when phase C rolls out. We can ameliorate the situation by properly standardizing P2QRH address derivation, providing libraries to generate addresses with ML-DSA and SLH-DSA leafs. We should recommend strongly against creating P2QRH addresses without at least one post-quantum spending path.

To better support hybrid spending conditions in P2QRH, we should modify phase B as follows: Fail any EC checksig opcode unless at least one PQ checksig opcode was executed earlier in the script. This implicitly blocks spending of pre-quantum UTXOs (until the predefined height X as Boris suggested). P2QRH addresses can explicitly define flexible hybrid signature schemes in the P2QRH tree using a two-leaf construction: one leaf with just OP_CHECKSIG​, and one leaf with both OP_CHECKSIG​ and a PQ checksig opcode (such as OP_MLDSACHECKSIG​).

To nodes who have upgraded to phase A (or earlier), funds sent to this address could be unlocked with the OP_CHECKSIG​ branch using a relatively small witness stack. On the other hand, nodes upgraded to phase B would reject the OP_CHECKSIG​-only branch, because there is no PQ-checksig opcode in the same script. Phase B nodes require the OP_MLDSACHECKSIG + OP_CHECKSIG​ branch to validate the spend. This branch needs a much larger witness stack, but would still permit a hybrid spend, covered by the combined security of Schnorr + Dilithium.

regards,

conduition

[Boris Nagaev]

Hey Conduition and all!

On Wednesday, July 16, 2025 at 1:48:27 PM UTC-3 conduition wrote:

Hey Boris and list,

What if all vulnerable coins are temporarily locked during phase B, with a clearly defined future block height X (e.g., in 5-10 years) at which point these coins become EC-spendable again?

Great idea. It gives us more time to get the zk-STARK proof system for phase C tightened up, but we still have the option of deploying phase B independently to protect procrastinators against a fast-arriving quantum adversary, even if the STARK system isn't ready yet. If quantum progress is slower (or phase C development is faster) than anticipated, we also have the option to merge the phases B and C together into a single deployment.

If we do that, should we apply the same logic to phase A though, and eventually permit sending to pre-quantum addresses at height X? Because as described, once phase A is locked in, we can never again permit sending to pre-quantum addresses (without a hard fork).

If the proposal gets traction, it is better to replace permanent blocking with temporary restrictions in case of both sending to and spending from vulnerable addresses. That way, we leave the door open for future recovery schemes without needing a hard fork.

Note that permanently blocking sends to vulnerable addresses can also be confiscatory. For example, someone might have a presigned transaction, like a Lightning force-close, where the destination address is a vulnerable address. If that path is blocked, the funds could be lost. If sending is temporary, the funds can be recovered later.

If nothing is permanently blocked, and temporary blocking is intended to allow legitimate owners to recover their funds, this could be seen as a win-win. It is no longer one group trying to capture the purchasing power of another. However, I still have doubts about whether this is an ethical solution.

I'm trying to place myself in the position of someone who can't move their funds before the deadline -- for example, a young heir with a timelocked inheritance. It's genuinely difficult to say what's better: risking loss to a quantum adversary, or facing a temporary block with the prospect of future recovery. It really comes down to individual risk appetite and time preference. And the challenge is, we can't ask them now -- that's the nature of the problem.

 

Maybe we should also talk about BIP360 P2QRH addresses and how they'd be treated by these phases. As Ethan pointed out, P2QRH addresses can contain EC signature spending conditions (OP_CHECKSIG). Would phase B's stricter rules also block EC spends from P2QRH UTXOs?

If yes, and phase B restricts EC spending from P2QRH, users may accidentally send money to P2QRH addresses whose leafs all require at least one EC signature opcode. This locks the money up until phase C, even though the purpose of phase A was to avoid exactly this from happening. Restricting P2QRH EC spending also makes hybrid spending conditions, which require both EC signatures and PQ signatures for extra safety, harder to implement explicitly in P2QRH script - We'd need dedicated EC/PQ hybrid checksig opcodes (which is an option if we want it).

If no, and phase B doesn't restrict EC spending from P2QRH, then P2QRH UTXOs with exposed EC spending leafs will be even more vulnerable to a quantum attacker than those who have exposed pubkeys in pre-quantum UTXOs: Pre-quantum UTXOs would have better protection, since they are temporarily locked by phase B but P2QRH UTXOs aren't.

Will phase C also unblock such EC-dependent P2QRH addresses? If so, they are equally protected as classic P2PKH -- both must wait until phase C to avoid exposing a public key by spending too early.

[Peter Todd]

On Mon, Jul 14, 2025 at 02:52:17PM -0400, Jameson Lopp wrote:
> Correct, this time is different in that we're not talking about vague
> unknown weaknesses. Rather, we're talking about a known algorithm that
> makes breaking cryptographic primitives orders of magnitude cheaper.

We already have known algorithms that would break cryptographic primitives if
sufficiently good analog computers actually existed. Or for that matter, "split
the universe" brute forcing. No-one is worried about them because "sufficiently
good" analog computers and multiverses are widely belived to not be physically
realizable.

For all the claims of progress on quantum computing hardware, the fact still
remains that no-one is even close to demonstrating cryptographic-relevant
quantum computing capabilities and the actual cryptographic-relevant
capabilities of real hardware are laughable. It's still an unknown whether or
not they are physically possible, and outside of the part of the physics
community that would like to sell you a quantum computer - or research
developing one - they're widely belived to be not physical.

Hence, these are still vague unknown weaknesses. Until progress is less vague,
actively freezing peoples' coins is not going to happen.

--
https://petertodd.org 'peter'[:-1]@petertodd.org

[conduition]

> Will phase C also unblock such EC-dependent P2QRH addresses? If so, they are equally protected as classic P2PKH -- both must wait until phase C to avoid exposing a public key by spending too early.

@Boris Yes, this should definitely be the case. Restrictions should be based on cryptographic operations needed to spend, not by output script type broadly. Though in the case of P2QRH, the best case should be that everyone using P2QRH includes a leaf script that supports post-quantum opcodes, even if they're not fully defined yet. Then spending with PQ crypto is as easy as a software update.

regards,

conduition

--

You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/02f2130c-c024-40ce-8623-c09ceb090619n%40googlegroups.com.

[conduition]

Hi Peter,

I think everyone here is well-aware of the possibility
that CRQCs may not ever appear, but that doesn't change
the fact we must have a plan ready to handle them. Lopp's
proposal does exactly that, and in a way that can be
rolled out incrementally as the risk increases. And even
if CRQCs never break discrete log, we would do well to
invest the time in designing this migration path anyway.
We'd then have a playbook to handle other sources of
cryptanalytic breakthroughs in the future.

I think you're worried the community may jump the gun and
deploy a freezing upgrade like phases A or B too early. I
share your concern but if anything I suspect the opposite
will happen. Nobody is going to be willing to freeze
anything unless imminent danger is readily apparent, and
fear-based reactions kick in.

Once it does, things will happen fast, and we need a plan
ready for that day (if it comes).

regards,
conduition

> --
> You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/aHuKIKqvCZl5rcEX%40petertodd.org.

[Marin Ivezic]

Even a year ago it was totally fair to question the feasibility of CRQCs. After all the recent scientific and engineering wins, that is not in question anymore. Eventual arrival of CRQC is pretty much a consensus now in quantum and cyber communities.

But that question is almost irrelevant now. The world is acting like CRQCs are coming, so we should act like it too. Regulators and governments are issuing quantum readiness roadmaps, banks have started their programs, insurers are carving out quantum risks, shareholders and analysts are questioning quantum readiness on earnings calls… and the media is eating it all up. The general public awareness is rapidly growing.

Rightly or wrongly, users will soon expect to see some assurances or plans on how bitcoin will resist the quantum threat. And if our response is that a few on the list think CRQC are laughable, the confidence will take a big hit.

The proposed BIP makes lots of sense. With that and BIP-360, a plan is shaping. And then we need three almost independent discussions:
1. We could technically solve Phase C (Post-Quantum Legacy Recovery) for any impacted BIP-39 wallets. This is the (relatively) easy one.
2. How do we make it all a bit more “crypto-agile”?
3. And finally the philosophical discussion on how to treat legacy non-HD wallets - burn them or allow them to be “stolen” / “liberated”.

Best, 
Marin

[Boris Nagaev]

Hi Jameson, hi all!

I have a couple of ideas on how to preserve more funds during any kind of fork that constrains or blocks currently used spending scenarios. This applies to both freezing and commit/reveal schemes; the latter may result in lost funds if the public key is leaked. I realized that this also applies to the commit/reveal scheme I proposed in another thread [1].

The idea is to roll out such forks incrementally across the UTXO set. Instead of freezing or constraining all UTXOs at once, we split the UTXO set into 256 groups deterministically (for example, by looking at the first byte of the TXID) and apply the constraints over 256 days, processing one group per day. Procrastinators will learn what is happening through word of mouth, act to save their funds, and only a small percentage of coin owners will be harmed.

Another approach is to provide a temporary opt-out option. If someone finds themselves blocked, they would still have a limited time to take an action, without requiring any extra knowledge, to get unblocked. This would help raise awareness. After being temporarily blocked and recovering their funds through the opt-out mechanism, the person would understand that they need to take further steps with their remaining coins to avoid being permanently blocked once the opt-out period ends. The action to unblock the funds could be as simple as sending a transaction with OP_RETURN "opt-out <txid>", which would enable the old acceptance rules for the transaction with that txid for a period of 2016 blocks.

[1] https://groups.google.com/g/bitcoindev/c/uUK6py0Yjq0/m/57bQJ3VSCQAJ

In that scheme if the pubkey is leaked, anyone can post a valid commitment with a random TXID blocking the coin forever.

Best,

Boris

[Antoine Riard]

> Beware the blurry line between stoicism and apathy.
>
> How well will it play out if we can say "well, we could have stopped a massive threat but chose not to, because we were confident the system would survive."
>
> The alternative path is "we saw a threat coming and the community collaborated to neutralize it before massive harm occurred."
>
> Both scenarios show resilience. Which evokes greater confidence?

Beware "ce qu'on ne voit pas" and the perverse incentives introduced by a Q-Day.

Expect massively PQ "claimed-to-be" secure wallet rushed under a false sense of emergency, very insecure against classic attacks.

If I was running a big custodian, def old schoold insurance on quantum risk is a thing. They already do for pure custody risks.

Otherwise, it's a typical "trolly problem" applied to bitcoin protocol dev. Indeed multiple viewpoints can be valid.

> I can't speak for Jameson, but let me put forward my own concern. If miners can buy much less electricity for 1-BTC this is a major problem for Bitcoin. If the price of electricity denominated in Bitcoin goes way up, miners will have to mine at a massive loss. Many will stop mining, then the block rate will go down and Bitcoin will appear to be less valuable (high fees, slow confirmation, panic), which makes mining even more of a loss, and so on. This also invites miners who have nothing left to lose to engage in mining attacks.

It's a real problem, but not specific to quantum. The same risk could happen when the inflation schedule is dried up after few halvings, or other exogeneous reason.

About the price crash and hypothetical impact on miners, a lot of open dimensions:
- unclear if the quantum adversary is economically rational and HODL its stack
- unclear if the quantum adversary would be able to liquidate its BTC stack bc on-ramp flagging them as stolen BTCs
- fragmentation of the on-ramp BTC markets over the world and if price down would reflect uniformly
- unclear if selling strategy of quantum adversary can be anticipated by miners
- poor elasticity of demand for miners electricity providers (e.g hydro or flare)
- unclear if the price crash can be quickly corrected by strong hands anticipating the "once-in-a-lifetime" cheap sell
- what else ?

I do agree it's a serious concern to have. On the other hand, we don't have a real quantitative model to reason on miners reaction.

In my view, this conv would be far more constructive, fact-based if someone can come up with a model on miners impact with what if ~20% of coins are quantum nuked.

Best,
Antoine
OTS hash: 74b5c0cdee22c391c2c50b052b652368ce1d01edc660077847b8ed662f0d172c

[Marc Johnson]

Hi All!

I'd first like to say thank you to James for the comprehensive proposal. The quantum threat is indeed existential, and I appreciate the detailed thinking that went into this migration plan. However, I’d like to respectfully raise some concerns about the approach and share an alternative perspective from work we’ve been doing in this space.

## Concerns with the Forced Sunset Approach

The proposal’s Phase B - rendering ECDSA/Schnorr spends invalid - essentially threatens users with permanent fund loss. This creates several issues:

1. **Violation of Bitcoin’s Social Contract**: Satoshi’s principle that “lost coins only make everyone else’s coins worth slightly more” becomes “coins you don’t migrate in time are forcibly lost.” This fundamentally changes Bitcoin’s value proposition.

2. **The 25% Problem**: With ~5.25 million BTC having exposed public keys, forcing these to become unspendable could create massive economic disruption. Many of these may be genuinely lost coins, but some could be long-term cold storage, inheritance situations, or users who simply miss the migration window.

3. **Timeline Risk**: The 5+ year timeline (3 years post-BIP-360 + 2 years) assumes smooth consensus and implementation. Given Bitcoin’s history, this could easily stretch to 7-10 years, most likely pushing implementation past the 2027-2030 quantum timeline mentioned.

## An Alternative Approach: Learning from Supernova

Our team has been working on these exact problems and recently reached production readiness with Supernova - a Bitcoin-inspired blockchain that implements quantum resistance from genesis. Rather than forced migration, we use a dual-signature scheme that might be instructive for Bitcoin:

**Three Modes of Operation:**
- **Legacy Mode**: ECDSA signatures only (Bitcoin-compatible)
- **Transition Mode**: Both ECDSA and quantum signatures required
- **Quantum Mode**: Quantum signatures only

This approach:
- Never locks users out of their funds
- Allows gradual, voluntary migration
- Maintains backwards compatibility indefinitely
- Provides immediate protection for those who want it

## Key Innovations Worth Considering

1. **Hybrid Signatures**: Instead of a hard cutoff, transactions can require both classical and quantum signatures during transition. This provides quantum security while maintaining compatibility.

2. **Address Format Compatibility**: Our quantum addresses (snq1...) coexist with standard addresses (sn1...), allowing users to choose their security level per transaction rather than per wallet.

3. **No Coordination Required**: Users can independently decide when to migrate without waiting for ecosystem-wide coordination.

4. **Proven Implementation**: We’ve demonstrated this works in production, including the world’s first quantum-resistant Lightning Network.

## A Cooperative Path Forward

Rather than viewing this as competition, I see opportunity for collaboration. Supernova could serve as a real-world testbed for quantum migration strategies. We’ve already implemented:

- NIST-standardized algorithms (Dilithium, SPHINCS+, Falcon)
- Quantum-resistant atomic swaps with Bitcoin
- Full Lightning Network with quantum HTLCs
- Zero-knowledge proofs for enhanced privacy

Bitcoin could learn from our implementation experience, while we continue to honor Bitcoin’s principles of decentralization and sound money.

## Invitation to Explore

For those interested in seeing quantum resistance in action today rather than waiting years, I invite you to explore Supernova. We’re launching our public testnet soon and would value feedback from the Bitcoin community.

The quantum threat is real, and we need multiple approaches to ensure the future of decentralized money. Whether through Bitcoin’s eventual upgrade or alternatives like Supernova, the important thing is that we act before it’s too late.

The code is open source, and we welcome technical review: [github.com/Carbon-Twelve-C12/supernova](https://github.com/Carbon-Twelve-C12/supernova)

Would love to hear thoughts on the dual-signature approach and whether something similar could work for Bitcoin without the harsh sunset provisions.

---

*Note: While I represent the Supernova project, I’m also a long-time Bitcoin supporter who wants to see the entire ecosystem survive the quantum transition. These challenges affect us all.*

[Marc Johnson]

Hi Jameson,

You're absolutely right that the dual-signature approach I suggested doesn't eliminate Bitcoin's migration problem - but it does transform it into a more manageable one. Let me attempt to clarify:

At it's core, what I'm suggesting is an approach to how we handle the transition period, not whether migration is needed.

What Dual Signatures Actually Solve:

The dual-signature approach addresses three specific issues with the forced sunset:

1. No Permanent Loss Deadline: Users who miss initial migration windows aren't permanently locked out. During the transition period, they can still move funds by providing both signatures.
   
   
2. Gradual Security Upgrade: Rather than a binary "migrate or lose everything," users can operate with increasing security levels:
• Continue using ECDSA (accepting quantum risk)
• Use both signatures (quantum-resistant but backwards compatible)
• Eventually transition to quantum-only
  
  
3. Market-Driven vs Forced Migration: Instead of protocol-enforced deadlines, market forces (exchange requirements, user preference) drive adoption.

How This Could Work for Bitcoin:

A potential implementation path:

• Phase 1: Enable quantum-resistant output types (like BIP-360)
• Phase 2: Implement dual-signature validation for new transactions
• Phase 3: Allow "transition transactions" where exposed-pubkey UTXOs can be spent with additional quantum proofs
• Phase 4: Gradually increase economic incentives for quantum migration (fee discounts, priority processing)

The critical difference: No Phase B cutoff where funds become permanently unspendable.

The Key Question:

Perhaps the core question isn't "how do we eliminate the migration problem?" but rather "how do we make migration as safe and flexible as possible?" Your sunset approach prioritizes network security through forced migration. The dual-signature approach prioritizes user sovereignty through optional migration.

Both have trade-offs. But given BTC's history with soft forks and the principle that "not your keys, not your coins" shouldn't become "not migrated in time, not your coins," perhaps we should explore approaches that preserve user optionality even if they increase implementation complexity.

What do you think about a hybrid approach - sunset for clearly abandoned coins (no movement in 10+ years) but dual-signature support for active-but-unmigrated funds?

Best,
Marc

On Tue, Aug 12, 2025 at 3:57 PM Jameson Lopp <jameso...@gmail.com> wrote:

On Thu, Aug 7, 2025 at 7:26 PM Marc Johnson <marcjoh...@gmail.com> wrote:

Hi All!

I'd first like to say thank you to James for the comprehensive proposal. The quantum threat is indeed existential, and I appreciate the detailed thinking that went into this migration plan. However, I’d like to respectfully raise some concerns about the approach and share an alternative perspective from work we’ve been doing in this space.

## Concerns with the Forced Sunset Approach

The proposal’s Phase B - rendering ECDSA/Schnorr spends invalid - essentially threatens users with permanent fund loss. This creates several issues:

1. **Violation of Bitcoin’s Social Contract**: Satoshi’s principle that “lost coins only make everyone else’s coins worth slightly more” becomes “coins you don’t migrate in time are forcibly lost.” This fundamentally changes Bitcoin’s value proposition.

2. **The 25% Problem**: With ~5.25 million BTC having exposed public keys, forcing these to become unspendable could create massive economic disruption. Many of these may be genuinely lost coins, but some could be long-term cold storage, inheritance situations, or users who simply miss the migration window.

3. **Timeline Risk**: The 5+ year timeline (3 years post-BIP-360 + 2 years) assumes smooth consensus and implementation. Given Bitcoin’s history, this could easily stretch to 7-10 years, most likely pushing implementation past the 2027-2030 quantum timeline mentioned.

## An Alternative Approach: Learning from Supernova

Our team has been working on these exact problems and recently reached production readiness with Supernova - a Bitcoin-inspired blockchain that implements quantum resistance from genesis. Rather than forced migration, we use a dual-signature scheme that might be instructive for Bitcoin:

I don't see how this solves Bitcoin's migration problem; how would currently locked funds be able to spend via a quantum safe signature scheme if they have not committed to a dual signature scheme? In order to take advantage of this setup on Bitcoin, you just end up recreating the migration problem.

--

You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/173b3bc4-7052-4e0e-9042-ca15cd5b0587n%40googlegroups.com.

--

M: +1-646-541-2108

W: marcjohnson.xyz

[Jameson Lopp]

On Thu, Aug 7, 2025 at 7:26 PM Marc Johnson <marcjoh...@gmail.com> wrote:

Hi All!

I'd first like to say thank you to James for the comprehensive proposal. The quantum threat is indeed existential, and I appreciate the detailed thinking that went into this migration plan. However, I’d like to respectfully raise some concerns about the approach and share an alternative perspective from work we’ve been doing in this space.

## Concerns with the Forced Sunset Approach

The proposal’s Phase B - rendering ECDSA/Schnorr spends invalid - essentially threatens users with permanent fund loss. This creates several issues:

1. **Violation of Bitcoin’s Social Contract**: Satoshi’s principle that “lost coins only make everyone else’s coins worth slightly more” becomes “coins you don’t migrate in time are forcibly lost.” This fundamentally changes Bitcoin’s value proposition.

2. **The 25% Problem**: With ~5.25 million BTC having exposed public keys, forcing these to become unspendable could create massive economic disruption. Many of these may be genuinely lost coins, but some could be long-term cold storage, inheritance situations, or users who simply miss the migration window.

3. **Timeline Risk**: The 5+ year timeline (3 years post-BIP-360 + 2 years) assumes smooth consensus and implementation. Given Bitcoin’s history, this could easily stretch to 7-10 years, most likely pushing implementation past the 2027-2030 quantum timeline mentioned.

## An Alternative Approach: Learning from Supernova

Our team has been working on these exact problems and recently reached production readiness with Supernova - a Bitcoin-inspired blockchain that implements quantum resistance from genesis. Rather than forced migration, we use a dual-signature scheme that might be instructive for Bitcoin:

I don't see how this solves Bitcoin's migration problem; how would currently locked funds be able to spend via a quantum safe signature scheme if they have not committed to a dual signature scheme? In order to take advantage of this setup on Bitcoin, you just end up recreating the migration problem.

--

[Saint Wenhao]

> how would currently locked funds be able to spend via a quantum safe signature scheme if they have not committed to a dual signature scheme?

In ECDSA, we have two secp256k1 points in use: one is public key, another is R-value in the signature. If someone has some coins, then the public key cannot be changed, if it is present in the output Script. However, R-value can be freely picked by the signer, and can be set to anything. Which means, that users can commit to any quantum data, by hashing it, and forming a valid commitment in R-value.

Which also means, that old nodes can see only ECDSA signatures, and public keys, while new, quantum-resistant nodes, can require R-value to commit to something. Then, in the first phase, when quantum commitments will be optional, users will use only ECDSA on-chain, but new, quantum nodes, will be able to see, what is committed to R-values behind signatures, and can store and process it.

And later, when quantum signatures will be obligatory, then for each and every OP_CHECKSIG call, R-value of the old ECDSA signature will be forced to commit to a valid quantum signature. Which also means, that the new quantum data won't be restricted by the current block size limit, but rather by a combination of sigops limit, and a quantum commitment size limit (which can be set to different values, for different quantum proposals, depending on a particular signature scheme).

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CADL_X_cgqHUOU6V9%2BGsEKz--ekxmgyYJwOg4BeLajAr_cTVN_g%40mail.gmail.com.

[conduition]

If someone has some coins, then the public key cannot be changed, if it is present in the output Script. However, R-value can be freely picked by the signer, and can be set to anything.

...

And later, when quantum signatures will be obligatory, then for each and every OP_CHECKSIG call, R-value of the old ECDSA signature will be forced to commit to a valid quantum signature.

The ECDSA R value is chosen by the signer, so the quantum attacker could pick any arbitrary PQ signature data and commit it at spending time too.

Lopp's point is that unless the output script has committed to a PQ public key in some way prior to a CRQC arriving, then 3rd party nodes can't know whether a spend that occurs after a CRQC has appeared is genuine. Any such commitments require positive action by UTXO holders, i.e. a migration.

regards,

conduition

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CACgYNO%2B1tFwsd-V67fyCWv%3DWtAXp4V6RQhsTw8XpzYULF7u_UA%40mail.gmail.com.

[Saint Wenhao]

> The ECDSA R value is chosen by the signer, so the quantum attacker could pick any arbitrary PQ signature data and commit it at spending time too.

In the current consensus? Yes. But it is possible to require a particular value in the future. Or: a particular format, for example by requiring DER signatures to take less than N bytes (also, relative timelocks are possible, so that the smaller signature will be used, the lower timelock requirements it would have).

> Any such commitments require positive action by UTXO holders, i.e. a migration.

No, because some public keys are exposed, and some of them are not. If they are hidden behind some kind of hashed output, like P2PKH, then it is possible to require committing to some kind of proof, because the public key can be unknown by the rest of the network.

Also, we can always use time travel. If there is no consensus, then just timelock every OP_CHECKSIG call to a few years, and think about it later. If after few years, there is still no consensus, how to migrate funds, then timelock it again. Then, sooner or later, some consensus will be reached. And if not, then people can still use OP_SIZE, to require a given amount of Proof of Work, and if nothing is deployed, then pure hashrate can still decide, who owns what, until people will agree on something better.