[bitcoindev] A Post Quantum Migration Proposal

[bitcoindev] A Post Quantum Migration Proposal

[Jameson Lopp]

[-- Attachment #1: Type: text/plain, Size: 11886 bytes --]

Building upon my earlier essay against allowing quantum recovery of bitcoin
<https://groups.google.com/g/bitcoindev/c/uUK6py0Yjq0/m/6peEaa90AQAJ> 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
      <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>
      ]
      -

   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
      <https://security.googleblog.com/2025/05/tracking-cost-of-quantum-factori.html>,
      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
   <https://bitcointalk.org/index.php?topic=198.msg1647#msg1647>.

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.

-- 
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+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CADL_X_fpv-aXBxX%2BeJ_EVTirkAJGyPRUNqOCYdz5um8zu6ma5Q%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 62457 bytes --]

[bitcoindev] Re: A Post Quantum Migration Proposal

[Tadge Dryja]

[-- Attachment #1.1: Type: text/plain, Size: 14445 bytes --]

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
On Saturday, July 12, 2025 at 8:46:09 PM UTC-4 Jameson Lopp wrote:

> Building upon my earlier essay against allowing quantum recovery of 
> bitcoin 
> <https://groups.google.com/g/bitcoindev/c/uUK6py0Yjq0/m/6peEaa90AQAJ> 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 
>       <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>
>       ]
>       - 
>    
>    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 
>       <https://security.googleblog.com/2025/05/tracking-cost-of-quantum-factori.html>, 
>       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 
>    <https://bitcointalk.org/index.php?topic=198.msg1647#msg1647>.  
>    
> 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.
>

-- 
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+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/37ed2e5d-34cd-4391-84b8-5bcc6d42c617n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 65292 bytes --]

[bitcoindev] Re: A Post Quantum Migration Proposal

[Antoine Riard]

[-- Attachment #1.1: Type: text/plain, Size: 21115 bytes --]

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
Le lundi 14 juillet 2025 à 00:53:34 UTC+1, Tadge Dryja a écrit :

> 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
> On Saturday, July 12, 2025 at 8:46:09 PM UTC-4 Jameson Lopp wrote:
>
>> Building upon my earlier essay against allowing quantum recovery of 
>> bitcoin 
>> <https://groups.google.com/g/bitcoindev/c/uUK6py0Yjq0/m/6peEaa90AQAJ> 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 
>>       <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>
>>       ]
>>       - 
>>    
>>    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 
>>       <https://security.googleblog.com/2025/05/tracking-cost-of-quantum-factori.html>, 
>>       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 
>>    <https://bitcointalk.org/index.php?topic=198.msg1647#msg1647>.  
>>    
>> 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.
>>
>

-- 
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+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/4d9ce13e-466d-478b-ab4d-00404c80d620n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 72107 bytes --]

Re: [bitcoindev] Re: A Post Quantum Migration Proposal

[Jameson Lopp]

[-- Attachment #1: Type: text/plain, Size: 15926 bytes --]

On Sun, Jul 13, 2025 at 7:53 PM Tadge Dryja <rx@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.


> -Tadge
> On Saturday, July 12, 2025 at 8:46:09 PM UTC-4 Jameson Lopp wrote:
>
>> Building upon my earlier essay against allowing quantum recovery of
>> bitcoin
>> <https://groups.google.com/g/bitcoindev/c/uUK6py0Yjq0/m/6peEaa90AQAJ> 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
>>       <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>
>>       ]
>>       -
>>
>>    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
>>       <https://security.googleblog.com/2025/05/tracking-cost-of-quantum-factori.html>,
>>       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
>>    <https://bitcointalk.org/index.php?topic=198.msg1647#msg1647>.
>>
>> 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.
>>
> --
> 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+unsubscribe@googlegroups.com.
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/37ed2e5d-34cd-4391-84b8-5bcc6d42c617n%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/37ed2e5d-34cd-4391-84b8-5bcc6d42c617n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CADL_X_dcdCOX3eHHU7q3EE7vDFRF_696f-k6aNEi-L3e05pB5Q%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 67175 bytes --]

Re: [bitcoindev] Re: A Post Quantum Migration Proposal

[Ethan Heilman]

[-- Attachment #1: Type: text/plain, Size: 24961 bytes --]

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 <antoine.riard@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.
>
> 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
> Le lundi 14 juillet 2025 à 00:53:34 UTC+1, Tadge Dryja a écrit :
>
>> 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
>> On Saturday, July 12, 2025 at 8:46:09 PM UTC-4 Jameson Lopp wrote:
>>
>>> Building upon my earlier essay against allowing quantum recovery of
>>> bitcoin
>>> <https://groups.google.com/g/bitcoindev/c/uUK6py0Yjq0/m/6peEaa90AQAJ> 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
>>>       <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>
>>>       ]
>>>       -
>>>
>>>    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
>>>       <https://security.googleblog.com/2025/05/tracking-cost-of-quantum-factori.html>,
>>>       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
>>>    <https://bitcointalk.org/index.php?topic=198.msg1647#msg1647>.
>>>
>>> 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.
>>>
>> --
> 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+unsubscribe@googlegroups.com.
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/4d9ce13e-466d-478b-ab4d-00404c80d620n%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/4d9ce13e-466d-478b-ab4d-00404c80d620n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAEM%3Dy%2BX6YSFyTtqR%2BCuKzDV4a7_3WA41N%3DunSszOZFw75w5cNA%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 75601 bytes --]

Re: [bitcoindev] Re: A Post Quantum Migration Proposal

[Jameson Lopp]

[-- Attachment #1: Type: text/plain, Size: 24413 bytes --]

On Mon, Jul 14, 2025 at 10:09 AM Antoine Riard <antoine.riard@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?

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
> Le lundi 14 juillet 2025 à 00:53:34 UTC+1, Tadge Dryja a écrit :
>
>> 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
>> On Saturday, July 12, 2025 at 8:46:09 PM UTC-4 Jameson Lopp wrote:
>>
>>> Building upon my earlier essay against allowing quantum recovery of
>>> bitcoin
>>> <https://groups.google.com/g/bitcoindev/c/uUK6py0Yjq0/m/6peEaa90AQAJ> 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
>>>       <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>
>>>       ]
>>>       -
>>>
>>>    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
>>>       <https://security.googleblog.com/2025/05/tracking-cost-of-quantum-factori.html>,
>>>       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
>>>    <https://bitcointalk.org/index.php?topic=198.msg1647#msg1647>.
>>>
>>> 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.
>>>
>> --
> 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+unsubscribe@googlegroups.com.
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/4d9ce13e-466d-478b-ab4d-00404c80d620n%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/4d9ce13e-466d-478b-ab4d-00404c80d620n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CADL_X_f3sDECRUosNaXyez3F_inKjJAWm%3DESm3DSLCKD4JV7yA%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 76232 bytes --]

Re: [bitcoindev] A Post Quantum Migration Proposal

['conduition' via Bitcoin Development Mailing List]

[-- Attachment #1.1.1: Type: text/plain, Size: 15197 bytes --]

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

On Saturday, July 12th, 2025 at 5:46 PM, Jameson Lopp <jameson.lopp@gmail.com> wrote:

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

> --
> 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+unsubscribe@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CADL_X_fpv-aXBxX%2BeJ_EVTirkAJGyPRUNqOCYdz5um8zu6ma5Q%40mail.gmail.com.

-- 
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+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/W2O6Al4bdVzx1EkszgN5dhtSUD0GwRgwYcRSWlQzfsvZE0UN5f6HBGXB2zorkGOpdsbDAS_X6xcsrH6zBIeYbPY8MM_sPfeN9Wblts5Gcog%3D%40proton.me.

[-- Attachment #1.1.2.1: Type: text/html, Size: 68962 bytes --]

[-- Attachment #1.2: publickey - conduition@proton.me - 0x474891AD.asc --]
[-- Type: application/pgp-keys, Size: 649 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 343 bytes --]

Re: [bitcoindev] Re: A Post Quantum Migration Proposal

[Boris Nagaev]

[-- Attachment #1.1: Type: text/plain, Size: 25106 bytes --]

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.
 

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.

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
Le lundi 14 juillet 2025 à 00:53:34 UTC+1, Tadge Dryja a écrit :

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
On Saturday, July 12, 2025 at 8:46:09 PM UTC-4 Jameson Lopp wrote:

Building upon my earlier essay against allowing quantum recovery of bitcoin 
<https://groups.google.com/g/bitcoindev/c/uUK6py0Yjq0/m/6peEaa90AQAJ> 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 
      <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>
      ]
      - 
   
   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 
      <https://security.googleblog.com/2025/05/tracking-cost-of-quantum-factori.html>, 
      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 
   <https://bitcointalk.org/index.php?topic=198.msg1647#msg1647>.  
   
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.

-- 

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 
<https://groups.google.com/d/msgid/bitcoindev/4d9ce13e-466d-478b-ab4d-00404c80d620n%40googlegroups.com?utm_medium=email&utm_source=footer>
.

-- 
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+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/6bb6953c-7784-4bd9-b271-ba5dc88b84b1n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 81467 bytes --]

Re: [bitcoindev] A Post Quantum Migration Proposal

[Boris Nagaev]

[-- Attachment #1.1: Type: text/plain, Size: 16846 bytes --]

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

On Tuesday, July 15, 2025 at 8:36:33 AM UTC-3 conduition wrote:

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
On Saturday, July 12th, 2025 at 5:46 PM, Jameson Lopp <jameso...@gmail.com> 
wrote:

Building upon my earlier essay against allowing quantum recovery of bitcoin 
<https://groups.google.com/g/bitcoindev/c/uUK6py0Yjq0/m/6peEaa90AQAJ> 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 
      <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>
      ]
      - 
   
   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 
      <https://security.googleblog.com/2025/05/tracking-cost-of-quantum-factori.html>, 
      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 
   <https://bitcointalk.org/index.php?topic=198.msg1647#msg1647>. 
   
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.

-- 

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
.


-- 
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+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/88a7b020-e84f-4052-9716-fb40b23f07ddn%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 73683 bytes --]

Re: [bitcoindev] A Post Quantum Migration Proposal

[Ethan Heilman]

[-- Attachment #1: Type: text/plain, Size: 15098 bytes --]

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

On Sat, Jul 12, 2025 at 8:46 PM Jameson Lopp <jameson.lopp@gmail.com> wrote:

> Building upon my earlier essay against allowing quantum recovery of
> bitcoin
> <https://groups.google.com/g/bitcoindev/c/uUK6py0Yjq0/m/6peEaa90AQAJ> 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
>       <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>
>       ]
>       -
>
>    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
>       <https://security.googleblog.com/2025/05/tracking-cost-of-quantum-factori.html>,
>       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
>    <https://bitcointalk.org/index.php?topic=198.msg1647#msg1647>.
>
> 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.
>
> --
> 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+unsubscribe@googlegroups.com.
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/CADL_X_fpv-aXBxX%2BeJ_EVTirkAJGyPRUNqOCYdz5um8zu6ma5Q%40mail.gmail.com
> <https://groups.google.com/d/msgid/bitcoindev/CADL_X_fpv-aXBxX%2BeJ_EVTirkAJGyPRUNqOCYdz5um8zu6ma5Q%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAEM%3Dy%2BWr4g%2BkcZpjSUEVay_NCdZcwGSEHcC6W9PcjpibYwd-sA%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 66115 bytes --]

Re: [bitcoindev] A Post Quantum Migration Proposal

['conduition' via Bitcoin Development Mailing List]

[-- Attachment #1.1.1: Type: text/plain, Size: 4115 bytes --]

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

-- 
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+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/gSvbx255CIbMSivfsn-1cGECh7UpJufvfVP4lwnp5r7gIamZo9t5LdBZBEYyiw4Eb9zNSvLXoi2SW8Sq3i7shSwBkWwxLRjoPkncexfCPRM%3D%40proton.me.

[-- Attachment #1.1.2.1: Type: text/html, Size: 6610 bytes --]

[-- Attachment #1.2: publickey - conduition@proton.me - 0x474891AD.asc --]
[-- Type: application/pgp-keys, Size: 649 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 343 bytes --]

Re: [bitcoindev] A Post Quantum Migration Proposal

[Boris Nagaev]

[-- Attachment #1.1: Type: text/plain, Size: 5861 bytes --]

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.
 

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

-- 
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+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/02f2130c-c024-40ce-8623-c09ceb090619n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 8640 bytes --]

Re: [bitcoindev] Re: A Post Quantum Migration Proposal

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1656 bytes --]

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

-- 
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+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/aHuKIKqvCZl5rcEX%40petertodd.org.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [bitcoindev] A Post Quantum Migration Proposal

['conduition' via Bitcoin Development Mailing List]

[-- Attachment #1.1.1: Type: text/plain, Size: 7056 bytes --]

> 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
On Wednesday, July 16th, 2025 at 5:05 PM, Boris Nagaev <bnagaev@gmail.com> wrote:

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

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

> --
> 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+unsubscribe@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/02f2130c-c024-40ce-8623-c09ceb090619n%40googlegroups.com.

-- 
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+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/a9xGMAv-oogmIdFuXMuXcgn_dkcCrIX9UNjXA-UuTqKrp6Tn8n6Q6usj33q66tr9SVP_jRpzeeq7Bw9wgcwCXsv2H5QTA1WL_JKvPH0eFdU%3D%40proton.me.

[-- Attachment #1.1.2.1: Type: text/html, Size: 10586 bytes --]

[-- Attachment #1.2: publickey - conduition@proton.me - 0x474891AD.asc --]
[-- Type: application/pgp-keys, Size: 649 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 343 bytes --]

Re: [bitcoindev] Re: A Post Quantum Migration Proposal

['conduition' via Bitcoin Development Mailing List]

[-- Attachment #1.1: Type: text/plain, Size: 3166 bytes --]

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



On Saturday, July 19th, 2025 at 8:13 AM, Peter Todd <pete@petertodd.org> wrote:

> 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
>
> --
> 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+unsubscribe@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/aHuKIKqvCZl5rcEX%40petertodd.org.

-- 
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+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAgIQP8YXvI8FjDiv0v29pw0VHdrlY6go6QoGMj1qqMsLKfGxeMBWVdxxQ5ZWhzl3T1wxjqj7XsPiRpTlBevo9hiNL92OtIQmMdGBsZaDqg%3D%40proton.me.

[-- Attachment #1.2: publickey - conduition@proton.me - 0x474891AD.asc --]
[-- Type: application/pgp-keys, Size: 649 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 343 bytes --]

Re: [bitcoindev] Re: A Post Quantum Migration Proposal

[Marin Ivezic]

[-- Attachment #1.1: Type: text/plain, Size: 4825 bytes --]



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
On Sunday, July 20, 2025 at 6:07:01 PM UTC+2 conduition wrote:

> 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
>
>
>
> On Saturday, July 19th, 2025 at 8:13 AM, Peter Todd <pe...@petertodd.org> 
> wrote:
>
> > 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
> >
> > --
> > 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
> .

-- 
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+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/1e39e6bd-8da4-45b1-9dc9-feacd923417dn%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 6460 bytes --]

[bitcoindev] Re: A Post Quantum Migration Proposal

[Boris Nagaev]

[-- Attachment #1.1: Type: text/plain, Size: 14122 bytes --]

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

On Saturday, July 12, 2025 at 9:46:09 PM UTC-3 Jameson Lopp wrote:

Building upon my earlier essay against allowing quantum recovery of bitcoin 
<https://groups.google.com/g/bitcoindev/c/uUK6py0Yjq0/m/6peEaa90AQAJ> 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 
      <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>
      ]
      - 
   
   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 
      <https://security.googleblog.com/2025/05/tracking-cost-of-quantum-factori.html>, 
      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 
   <https://bitcointalk.org/index.php?topic=198.msg1647#msg1647>.  
   
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.

-- 
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+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/cfb00fb3-1eeb-40c5-acc3-50d1919d7dben%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 68783 bytes --]