[bitcoindev] A Post Quantum Migration Proposal

public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed

* [bitcoindev] A Post Quantum Migration Proposal
@ 2025-07-12 21:36 Jameson Lopp
  2025-07-13 23:19 ` [bitcoindev] " Tadge Dryja
  0 siblings, 1 reply; 6+ messages in thread
From: Jameson Lopp @ 2025-07-12 21:36 UTC (permalink / raw)
  To: Bitcoin Development Mailing List

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [bitcoindev] Re: A Post Quantum Migration Proposal
  2025-07-12 21:36 [bitcoindev] A Post Quantum Migration Proposal Jameson Lopp
@ 2025-07-13 23:19 ` Tadge Dryja
  2025-07-14  2:07   ` Antoine Riard
  2025-07-14 13:50   ` Jameson Lopp
  0 siblings, 2 replies; 6+ messages in thread
From: Tadge Dryja @ 2025-07-13 23:19 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [bitcoindev] Re: A Post Quantum Migration Proposal
  2025-07-13 23:19 ` [bitcoindev] " Tadge Dryja
@ 2025-07-14  2:07   ` Antoine Riard
  2025-07-14 16:08     ` Ethan Heilman
  2025-07-14 18:52     ` Jameson Lopp
  2025-07-14 13:50   ` Jameson Lopp
  1 sibling, 2 replies; 6+ messages in thread
From: Antoine Riard @ 2025-07-14  2:07 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [bitcoindev] Re: A Post Quantum Migration Proposal
  2025-07-14  2:07   ` Antoine Riard
@ 2025-07-14 16:08     ` Ethan Heilman
  2025-07-14 18:52     ` Jameson Lopp
  1 sibling, 0 replies; 6+ messages in thread
From: Ethan Heilman @ 2025-07-14 16:08 UTC (permalink / raw)
  To: Antoine Riard; +Cc: Bitcoin Development Mailing List

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [bitcoindev] Re: A Post Quantum Migration Proposal
  2025-07-14  2:07   ` Antoine Riard
  2025-07-14 16:08     ` Ethan Heilman
@ 2025-07-14 18:52     ` Jameson Lopp
  1 sibling, 0 replies; 6+ messages in thread
From: Jameson Lopp @ 2025-07-14 18:52 UTC (permalink / raw)
  To: Antoine Riard; +Cc: Bitcoin Development Mailing List

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [bitcoindev] Re: A Post Quantum Migration Proposal
  2025-07-13 23:19 ` [bitcoindev] " Tadge Dryja
  2025-07-14  2:07   ` Antoine Riard
@ 2025-07-14 13:50   ` Jameson Lopp
  1 sibling, 0 replies; 6+ messages in thread
From: Jameson Lopp @ 2025-07-14 13:50 UTC (permalink / raw)
  To: Tadge Dryja; +Cc: Bitcoin Development Mailing List

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2025-07-14 19:06 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-07-12 21:36 [bitcoindev] A Post Quantum Migration Proposal Jameson Lopp
2025-07-13 23:19 ` [bitcoindev] " Tadge Dryja
2025-07-14  2:07   ` Antoine Riard
2025-07-14 16:08     ` Ethan Heilman
2025-07-14 18:52     ` Jameson Lopp
2025-07-14 13:50   ` Jameson Lopp

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox