public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Boris Nagaev <bnagaev@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: [bitcoindev] Re: A Post Quantum Migration Proposal
Date: Sun, 20 Jul 2025 15:54:39 -0700 (PDT)	[thread overview]
Message-ID: <cfb00fb3-1eeb-40c5-acc3-50d1919d7dben@googlegroups.com> (raw)
In-Reply-To: <CADL_X_fpv-aXBxX+eJ_EVTirkAJGyPRUNqOCYdz5um8zu6ma5Q@mail.gmail.com>


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

Hi Jameson, hi all!

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

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

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


[1] https://groups.google.com/g/bitcoindev/c/uUK6py0Yjq0/m/57bQJ3VSCQAJ
In that scheme if the pubkey is leaked, anyone can post a valid commitment 
with a random TXID blocking the coin forever.

Best,
Boris

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

Building upon my earlier essay against allowing quantum recovery of bitcoin 
<https://groups.google.com/g/bitcoindev/c/uUK6py0Yjq0/m/6peEaa90AQAJ> I 
wish to formalize a proposal after several months of discussions.

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

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

This proposal follows the implementation of post-quantum (PQ) output type 
(P2QRH) and introduces a pre-announced sunset of legacy ECDSA/Schnorr 
signatures. It turns quantum security into a private incentive: fail to 
upgrade and you will certainly lose access to your funds, creating a 
certainty where none previously existed. 

   - 
   
   Phase A: Disallows sending of any funds to quantum-vulnerable addresses, 
   hastening the adoption of P2QRH address types.
   - 
   
   Phase B: Renders ECDSA/Schnorr spends invalid, preventing all spending 
   of funds in quantum-vulnerable UTXOs. This is triggered by a 
   well-publicized flag-day roughly five years after activation.
   - 
   
   Phase C (optional): Pending further research and demand, a separate BIP 
   proposing a fork to allow recovery of legacy UTXOs through ZK proof of 
   possession of BIP-39 seed phrase.  
   
Motivation

We seek to secure the value of the UTXO set and minimize incentives for 
quantum attacks. This proposal is radically different from any in Bitcoin’s 
history just as the threat posed by quantum computing is radically 
different from any other threat in Bitcoin’s history.  Never before has 
Bitcoin faced an existential threat to its cryptographic primitives. A 
successful quantum attack on Bitcoin would result in significant economic 
disruption and damage across the entire ecosystem. Beyond its impact on 
price, the ability of miners to provide network security may be 
significantly impacted.  

   - 
   
   Accelerating quantum progress. 
   - 
      
      NIST ratified three production-grade PQ signature schemes in 2024; 
      academic road-maps now estimate a cryptographically-relevant quantum 
      computer as early as 2027-2030. [McKinsey 
      <https://www.mckinsey.com/~/media/mckinsey/business%20functions/mckinsey%20digital/our%20insights/the%20year%20of%20quantum%20from%20concept%20to%20reality%20in%202025/quantum-monitor-2025.pdf?shouldIndex=false>
      ]
      - 
   
   Quantum algorithms are rapidly improving
   - 
      
      The safety envelope is shrinking by dramatic increases in algorithms 
      even if the pace of hardware improvements is slower. Algorithms are improving 
      up to 20X 
      <https://security.googleblog.com/2025/05/tracking-cost-of-quantum-factori.html>, 
      lowering the theoretical hardware requirements for breaking classical 
      encryption.
      - 
   
   Bitcoin’s exposed public keys. 
   - 
      
      Roughly 25% of all bitcoin have revealed a public key on-chain; those 
      UTXOs could be stolen with sufficient quantum power.  
      - 
   
   We may not know the attack is underway. 
   - 
      
      Quantum attackers could compute the private key for known public keys 
      then transfer all funds weeks or months later, in a covert bleed to not 
      alert chain watchers. Q-Day may be only known much later if the attack 
      withholds broadcasting transactions in order to postpone revealing their 
      capabilities.
      - 
   
   Private keys become public. 
   - 
      
      Assuming that quantum computers are able to maintain their current 
      trajectories and overcome existing engineering obstacles, there is a near 
      certain chance that all P2PK (and other outputs with exposed pubkeys) 
      private keys will be found and used to steal the funds.
      - 
   
   Impossible to know motivations. 
   - 
      
      Prior to a quantum attack, it is impossible to know the motivations 
      of the attacker.  An economically motivated attacker will try to remain 
      undetected for as long as possible, while a malicious attacker will attempt 
      to destroy as much value as possible.  
      - 
   
   Upgrade inertia. 
   - 
      
      Coordinating wallets, exchanges, miners and custodians historically 
      takes years.
      - 
      
      The longer we postpone migration, the harder it becomes to coordinate 
      wallets, exchanges, miners, and custodians. A clear, time-boxed pathway is 
      the only credible defense.
      - 
      
      Coordinating distributed groups is more prone to delay, even if 
      everyone has similar motivations. Historically, Bitcoin has been slow to 
      adopt code changes, often taking multiple years to be approved.
      
Benefits at a Glance
   
   - 
   
   Resilience: Bitcoin protocol remains secure for the foreseeable future 
   without waiting for a last-minute emergency.
   - 
   
   Certainty: Bitcoin users and stakeholders gain certainty that a plan is 
   both in place and being implemented to effectively deal with the threat of 
   quantum theft of bitcoin.  
   - 
   
   Clarity: A single, publicized timeline aligns the entire ecosystem 
   (wallets, exchanges, hardware vendors).
   - 
   
   Supply Discipline: Abandoned keys that never migrate become unspendable, 
   reducing supply, as Satoshi described 
   <https://bitcointalk.org/index.php?topic=198.msg1647#msg1647>.  
   
Specification

Phase

What Happens

Who Must Act

Time Horizon

Phase A - Disallow spends to legacy script types

Permitted sends are from legacy scripts to P2QRH scripts

Everyone holding or accepting BTC.

3 years after BIP-360 implementation

Phase B – Disallow spends from quantum vulnerable outputs

At a preset block-height, nodes reject transactions that rely on 
ECDSA/Schnorr keys. 

Everyone holding or accepting BTC.

2 years after Phase A activation.

Phase C – Re-enable spends from quantum vulnerable outputs via ZK Proof

Users with frozen quantum vulnerable funds and a HD wallet seed phrase can 
construct a quantum safe ZK proof to recover funds.

Users who failed to migrate funds before Phase B.

TBD pending research, demand, and consensus.
Rationale
   
   - 
   
   Even if Bitcoin is not a primary initial target of a cryptographically 
   relevant quantum computer, widespread knowledge that such a computer exists 
   and is capable of breaking Bitcoin’s cryptography will damage faith in the 
   network . 
   - 
   
   An attack on Bitcoin may not be economically motivated - an attacker may 
   be politically or maliciously motivated and may attempt to destroy value 
   and trust in Bitcoin rather than extract value.  There is no way to know in 
   advance how, when, or why an attack may occur.  A defensive position must 
   be taken well in advance of any attack.  
   - 
   
   Bitcoin’s current signatures (ECDSA/Schnorr) will be a tantalizing 
   target: any UTXO that has ever exposed its public key on-chain (roughly 25 
   % of all bitcoin) could be stolen by a cryptographically relevant quantum 
   computer.
   - 
   
   Existing Proposals are Insufficient.  
   1. 
      
      Any proposal that allows for the quantum theft of “lost” bitcoin is 
      creating a redistribution dilemma. There are 3 types of proposals:
      1. 
         
         Allow anyone to steal vulnerable coins, benefitting those who 
         reach quantum capability earliest.
         2. 
         
         Allow throttled theft of coins, which leads to RBF battles and 
         ultimately miners subsidizing their revenue from lost coins.
         3. 
         
         Allow no one to steal vulnerable coins.
         - 
   
   Minimizes attack surface
   1. 
      
      By disallowing new spends to quantum vulnerable script types, we 
      minimize the attack surface with each new UTXO.  
      2. 
      
      Upgrades to Bitcoin have historically taken many years; this will 
      hasten and speed up the adoption of new quantum resistant script types. 
      3. 
      
      With a clear deadline, industry stakeholders will more readily 
      upgrade existing infrastructure to ensure continuity of services.  
      - 
   
   Minimizes loss of access to funds 
   1. 
      
      If there is sufficient demand and research proves possible, 
      submitting a ZK proof of knowledge of a BIP-39 seed phrase corresponding to 
      a public key hash or script hash would provide a trustless means for legacy 
      outputs to be spent in a quantum resistant manner, even after the sunset.  
      

Stakeholder

Incentive to Upgrade

Miners

• Larger size PQ signatures along with incentive for users to migrate will 
create more demand for block space and thus higher fees collected by miners.

• Post-Phase B, non-upgraded miners produce invalid blocks.

• A quantum attack on Bitcoin will significantly devalue both their 
hardware and Bitcoin as a whole. 

Institutional Holders

• Fiduciary duty: failing to act to prevent a quantum attack on Bitcoin 
would violate the fiduciary duty to shareholders.  

• Demonstrating Bitcoin’s ability to effectively mitigate emerging threats 
will prove Bitcoin to be an investment grade asset.

Exchanges & Custodians

• Concentrated risk: a quantum hack could bankrupt them overnight.

• Early migration is cheap relative to potential losses, potential lawsuits 
over improper custody and reputational damage.

Everyday Users

• Self-sovereign peace of mind.

• Sunset date creates a clear deadline and incentive to improve their 
security rather than an open-ended “some day” that invites procrastination.

Attackers

• Economic incentive diminishes as sunset nears, stolen coins cannot be 
spent after Q-day.

Key Insight: As mentioned earlier, the proposal turns quantum security into 
a private incentive to upgrade.  

This is not an offensive attack, rather, it is defensive: our thesis is 
that the Bitcoin ecosystem wishes to defend itself and its interests 
against those who would prefer to do nothing and allow a malicious actor to 
destroy both value and trust.  


"Lost coins only make everyone else's coins worth slightly more. Think of 
it as a donation to everyone." - Satoshi Nakamoto


If true, the corollary is:


"Quantum recovered coins only make everyone else's coins worth less. Think 
of it as a theft from everyone."


The timelines that we are proposing are meant to find the best balance 
between giving ample ability for account owners to migrate while 
maintaining the integrity of the overall ecosystem to avoid catastrophic 
attacks.  

Backward Compatibility

As a series of soft forks, older nodes will continue to operate without 
modification. Non-upgraded nodes, however, will consider all post-quantum 
witness programs as anyone-can-spend scripts. They are strongly encouraged 
to upgrade in order to fully validate the new programs.

Non-upgraded wallets can receive and send bitcoin from non-upgraded and 
upgraded wallets until Phase A. After Phase A, they can no longer receive 
from any other wallets and can only send to upgraded wallets.  After Phase 
B, both senders and receivers will require upgraded wallets. Phase C would 
likely require a loosening of consensus rules (a hard fork) to allow 
vulnerable funds recovery via ZK proofs.

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/cfb00fb3-1eeb-40c5-acc3-50d1919d7dben%40googlegroups.com.

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

      parent reply	other threads:[~2025-07-20 22:56 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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-15  2:50       ` Boris Nagaev
2025-07-14 18:52     ` Jameson Lopp
2025-07-19 12:05       ` Peter Todd
2025-07-20 15:56         ` 'conduition' via Bitcoin Development Mailing List
2025-07-20 17:39           ` Marin Ivezic
2025-07-14 13:50   ` Jameson Lopp
2025-07-15  2:32 ` [bitcoindev] " 'conduition' via Bitcoin Development Mailing List
2025-07-15 14:13   ` Boris Nagaev
2025-07-16 16:43     ` 'conduition' via Bitcoin Development Mailing List
2025-07-16 17:34       ` Boris Nagaev
2025-07-20 15:37         ` 'conduition' via Bitcoin Development Mailing List
2025-07-15 17:57 ` Ethan Heilman
2025-07-20 22:54 ` Boris Nagaev [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cfb00fb3-1eeb-40c5-acc3-50d1919d7dben@googlegroups.com \
    --to=bnagaev@gmail.com \
    --cc=bitcoindev@googlegroups.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox