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

From: "'conduition' via Bitcoin Development Mailing List" <[email-masked]>
Date: Fri, 22 Aug 2025 19:59:53 +0000

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

> ...

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

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

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

regards,
conduition
On Tuesday, August 19th, 2025 at 3:11 PM, Saint Wenhao <[email-masked]> wrote:

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

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

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

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

> pon., 18 sie 2025 o 19:12 Jameson Lopp <[email-masked]> napisał(a):
> 

> > On Thu, Aug 7, 2025 at 7:26 PM Marc Johnson <[email-masked]> wrote:
> > 

> > > Hi All!

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

> > > ## Concerns with the Forced Sunset Approach
> > > 

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

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

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

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

> > > ## An Alternative Approach: Learning from Supernova
> > > 

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

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

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

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

> > > ## Key Innovations Worth Considering
> > > 

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

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

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

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

> > > ## A Cooperative Path Forward
> > > 

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

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

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

> > > ## Invitation to Explore

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

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

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

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

> > > ---

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

> > > On Sunday, July 20, 2025 at 11:56:48 PM UTC+1 Boris Nagaev wrote:
> > > 

> > > > 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 I wish to formalize a proposal after several months of discussions.
> > > > > 

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

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

> > > > > Abstract

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

> > > > > -   Phase A: Disallows sending of any funds to quantum-vulnerable addresses, hastening the adoption of P2QRH address types.
> > > > >     

> > > > > -   Phase B: Renders ECDSA/Schnorr spends invalid, preventing all spending of funds in quantum-vulnerable UTXOs. This is triggered by a well-publicized flag-day roughly five years after activation.
> > > > >     

> > > > > -   Phase C (optional): Pending further research and demand, a separate BIP proposing a fork to allow recovery of legacy UTXOs through ZK proof of possession of BIP-39 seed phrase.
> > > > >     

> > > > > Motivation

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

> > > > > -   Accelerating quantum progress.
> > > > >     

> > > > >     -   NIST ratified three production-grade PQ signature schemes in 2024; academic road-maps now estimate a cryptographically-relevant quantum computer as early as 2027-2030. [McKinsey]
> > > > >         

> > > > > -   Quantum algorithms are rapidly improving
> > > > >     

> > > > >     -   The safety envelope is shrinking by dramatic increases in algorithms even if the pace of hardware improvements is slower. Algorithms are improving up to 20X, lowering the theoretical hardware requirements for breaking classical encryption.
> > > > >         

> > > > > -   Bitcoin’s exposed public keys.
> > > > >     

> > > > >     -   Roughly 25% of all bitcoin have revealed a public key on-chain; those UTXOs could be stolen with sufficient quantum power.
> > > > >         

> > > > > -   We may not know the attack is underway.
> > > > >     

> > > > >     -   Quantum attackers could compute the private key for known public keys then transfer all funds weeks or months later, in a covert bleed to not alert chain watchers. Q-Day may be only known much later if the attack withholds broadcasting transactions in order to postpone revealing their capabilities.
> > > > >         

> > > > > -   Private keys become public.
> > > > >     

> > > > >     -   Assuming that quantum computers are able to maintain their current trajectories and overcome existing engineering obstacles, there is a near certain chance that all P2PK (and other outputs with exposed pubkeys) private keys will be found and used to steal the funds.
> > > > >         

> > > > > -   Impossible to know motivations.
> > > > >     

> > > > >     -   Prior to a quantum attack, it is impossible to know the motivations of the attacker. An economically motivated attacker will try to remain undetected for as long as possible, while a malicious attacker will attempt to destroy as much value as possible.
> > > > >         

> > > > > -   Upgrade inertia.

> > > > >     -   Coordinating wallets, exchanges, miners and custodians historically takes years.
> > > > >         

> > > > >     -   The longer we postpone migration, the harder it becomes to coordinate wallets, exchanges, miners, and custodians. A clear, time-boxed pathway is the only credible defense.
> > > > >         

> > > > >     -   Coordinating distributed groups is more prone to delay, even if everyone has similar motivations. Historically, Bitcoin has been slow to adopt code changes, often taking multiple years to be approved.
> > > > >         

> > > > > Benefits at a Glance

> > > > > -   Resilience: Bitcoin protocol remains secure for the foreseeable future without waiting for a last-minute emergency.
> > > > >     

> > > > > -   Certainty: Bitcoin users and stakeholders gain certainty that a plan is both in place and being implemented to effectively deal with the threat of quantum theft of bitcoin.
> > > > >     

> > > > > -   Clarity: A single, publicized timeline aligns the entire ecosystem (wallets, exchanges, hardware vendors).
> > > > >     

> > > > > -   Supply Discipline: Abandoned keys that never migrate become unspendable, reducing supply, as Satoshi described.
> > > > >     

> > > > > Specification

> > > > > Phase

> > > > > What Happens

> > > > > Who Must Act

> > > > > Time Horizon

> > > > > Phase A - Disallow spends to legacy script types
> > > > > 

> > > > > Permitted sends are from legacy scripts to P2QRH scripts
> > > > > 

> > > > > Everyone holding or accepting BTC.
> > > > > 

> > > > > 3 years after BIP-360 implementation
> > > > > 

> > > > > Phase B – Disallow spends from quantum vulnerable outputs
> > > > > 

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

> > > > > Everyone holding or accepting BTC.
> > > > > 

> > > > > 2 years after Phase A activation.
> > > > > 

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

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

> > > > > Users who failed to migrate funds before Phase B.
> > > > > 

> > > > > TBD pending research, demand, and consensus.
> > > > > 

> > > > > Rationale

> > > > > -   Even if Bitcoin is not a primary initial target of a cryptographically relevant quantum computer, widespread knowledge that such a computer exists and is capable of breaking Bitcoin’s cryptography will damage faith in the network .
> > > > >     

> > > > > -   An attack on Bitcoin may not be economically motivated - an attacker may be politically or maliciously motivated and may attempt to destroy value and trust in Bitcoin rather than extract value. There is no way to know in advance how, when, or why an attack may occur. A defensive position must be taken well in advance of any attack.
> > > > >     

> > > > > -   Bitcoin’s current signatures (ECDSA/Schnorr) will be a tantalizing target: any UTXO that has ever exposed its public key on-chain (roughly 25 % of all bitcoin) could be stolen by a cryptographically relevant quantum computer.
> > > > >     

> > > > > -   Existing Proposals are Insufficient.
> > > > >     

> > > > >     1.  Any proposal that allows for the quantum theft of “lost” bitcoin is creating a redistribution dilemma. There are 3 types of proposals:
> > > > >         

> > > > >         1.  Allow anyone to steal vulnerable coins, benefitting those who reach quantum capability earliest.
> > > > >             

> > > > >         2.  Allow throttled theft of coins, which leads to RBF battles and ultimately miners subsidizing their revenue from lost coins.
> > > > >             

> > > > >         3.  Allow no one to steal vulnerable coins.
> > > > >             

> > > > > -   Minimizes attack surface
> > > > >     

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

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

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

> > > > > -   Minimizes loss of access to funds
> > > > >     

> > > > >     1.  If there is sufficient demand and research proves possible, submitting a ZK proof of knowledge of a BIP-39 seed phrase corresponding to a public key hash or script hash would provide a trustless means for legacy outputs to be spent in a quantum resistant manner, even after the sunset.
> > > > >         

> > > > > Stakeholder

> > > > > Incentive to Upgrade

> > > > > Miners

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

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

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

> > > > > Institutional Holders

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

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

> > > > > Exchanges & Custodians

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

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

> > > > > Everyday Users

> > > > > • Self-sovereign peace of mind.
> > > > > 

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

> > > > > Attackers

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

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

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

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

> > > > > If true, the corollary is:
> > > > > 

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

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

> > > > > Backward Compatibility

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

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

> > > --
> > > You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
> > > To unsubscribe from this group and stop receiving emails from it, send an email to [email-masked].
> > > To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/173b3bc4-7052-4e0e-9042-ca15cd5b0587n%40googlegroups.com.
> > 

> > --
> > You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
> > To unsubscribe from this group and stop receiving emails from it, send an email to [email-masked].
> > To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CADL_X_cgqHUOU6V9%2BGsEKz--ekxmgyYJwOg4BeLajAr_cTVN_g%40mail.gmail.com.
> 

> --
> You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to [email-masked].
> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CACgYNO%2B1tFwsd-V67fyCWv%3DWtAXp4V6RQhsTw8XpzYULF7u_UA%40mail.gmail.com.

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email-masked].
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/rCO-ee8FiX-prHxWh07O38oxSkVxhkV7vBbk7I0IS7RxqkJydKN9b_ubg_BWwdCzw0lkskcD0zdyoJx6cr67cc-BQWS64snWYhex_2W7g6o%3D%40proton.me.