From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 07 Aug 2025 17:26:16 -0700 Received: from mail-qt1-f191.google.com ([209.85.160.191]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1ukAw1-0001Il-Nj for bitcoindev@gnusha.org; Thu, 07 Aug 2025 17:26:16 -0700 Received: by mail-qt1-f191.google.com with SMTP id d75a77b69052e-4b092c12825sf46093071cf.1 for ; Thu, 07 Aug 2025 17:26:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1754612767; x=1755217567; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=junEkixd74k+QBoJ6eLISGYkRhxiVAclKz3644tF2A8=; b=Ha4GoO65kUOrCMoezk/Az9/i6bz+1QOZdrZOIIBlSsjJlXH2W1SEvtzM4/h8h3gApU lTm8KvbEjpAljlWQtYRx0F+rZEyNUOM3a84x1e6OS7bGLahcmNTTeyDGmWnbYwGV+x1O XNcPnpo8tngUobUMVEkSt+GFhV+PnrM5zSl84i2nIZOAk1zBCp1YQruTCF0GoMXAvvhd VQQnV0hVPhsCXsO0VFTGzsIvzdOU+xVp5zj+A+gfDEhi75dvTq2I4kG5744dlJ+PjtbI iUe64gdslq7ePBIbzxVxEOx0zLUl3QdSbbDkfElXcjCDseRx/woM/RkS+lvSRJAoM2IN 67rg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1754612767; x=1755217567; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=junEkixd74k+QBoJ6eLISGYkRhxiVAclKz3644tF2A8=; b=lr67ZfLz/bIle/GnWyOjbevOuECEsqg3CRm8V8r/6y6ylp557b2CZNZG4AkrPbM0Gt ISRN2yZ23QcY3zcX9l5EGNZVFNwgSPvQy1QgbbmfSXH7VBfp1btRo/MONV3qI38JLNsR RMGcMjnLNYMxVOFGRy8HpdLk3ShW4bbbT9kAP2jQCHGF9HTbPzmMAkFyImsyYsgCxH16 5nyNtkhWQmcUY26XdpAVjC8VooubhD+v7VD62w2mRqxO+HFZ8Ct1Sm2gWuTiTBx05yU5 zCVygGQOxjn+73dEfu6lmzk6zqpbfZu0Vo4+GQDQ9bcUDGsql7wFGmOAgnu/r1sWSoDM 8N1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1754612767; x=1755217567; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=junEkixd74k+QBoJ6eLISGYkRhxiVAclKz3644tF2A8=; b=cxPrYfukwLarckWVxJbejCdAllKCdOCMiImK/5L9HANolkQe8mC3NjwLchqLqn9FTv P66ylnGsDV46QP8McSELDtxtn4yKNletRfJ4GZXKtJAq2PANTOi3KDZqs9vLlPaoVBd1 d8btPyw6L/IWfE9Hn7ihiXEYT+6mZIx8MZCzHjC+nZNkmGx+euwBPowxvNo3HwA24WaZ dxhOUhB98+taIcL2bLMsW5VzP8W5yULF+HEkQ7zBtk4/7bywR1hBI5KtgdIOi11A1d7x v/AGVonPVwy5sO3UOpUmQBU8tr07k65ZZR6iZIeXJEXSR+WXyhR3hz9G8VByFiYXGBiv WmvQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCUIgHdc1W6HvyP4pFFeRJ9GHutfyZNJ6KrVR/N9A+D7RBOUUpjuRUinS+fi014NHX9Mo++dRUlU1jhO@gnusha.org X-Gm-Message-State: AOJu0YzsU9vTjHeT1Fqa+0S90W1ZdO34UMEi6rnje8g5gCKszEgdNiff ER5QgzVMISvNTwhUZPKHVcjImmdbLKY2yjS1FMnsTVoc1gSoJwrrL1SU X-Google-Smtp-Source: AGHT+IGrjVq39hirlRAOTXKmiZQCjyGR//kTVG3U84K+zQNdmIY6sQEG3aWCZASwXA3fL+ReysgeNA== X-Received: by 2002:a05:622a:8c6:b0:4b0:70af:2071 with SMTP id d75a77b69052e-4b0aec787d9mr19335191cf.13.1754612766695; Thu, 07 Aug 2025 17:26:06 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZeKd0Tg7Ijp37S1Yjt7gDkn8KZ13hP/vJVQhuzZjaVlig== Received: by 2002:ac8:5a16:0:b0:4b0:7448:c7ee with SMTP id d75a77b69052e-4b0a06d99e0ls25636721cf.1.-pod-prod-03-us; Thu, 07 Aug 2025 17:26:01 -0700 (PDT) X-Received: by 2002:a05:620a:5616:b0:7e2:814c:1128 with SMTP id af79cd13be357-7e82c68456emr151306385a.18.1754612760981; Thu, 07 Aug 2025 17:26:00 -0700 (PDT) Received: by 2002:a0d:d0c4:0:b0:718:5fd:a4e7 with SMTP id 00721157ae682-719b273ca77ms7b3; Fri, 25 Jul 2025 03:58:39 -0700 (PDT) X-Received: by 2002:a05:690c:3589:b0:70c:a57c:94ba with SMTP id 00721157ae682-719e32c3fddmr19419657b3.17.1753441117705; Fri, 25 Jul 2025 03:58:37 -0700 (PDT) Date: Fri, 25 Jul 2025 03:58:37 -0700 (PDT) From: Marc Johnson To: Bitcoin Development Mailing List Message-Id: <173b3bc4-7052-4e0e-9042-ca15cd5b0587n@googlegroups.com> In-Reply-To: References: Subject: [bitcoindev] Re: A Post Quantum Migration Proposal MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_439180_1061410710.1753441117316" X-Original-Sender: marcjohnson518@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_439180_1061410710.1753441117316 Content-Type: multipart/alternative; boundary="----=_Part_439181_135523467.1753441117316" ------=_Part_439181_135523467.1753441117316 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi All! I'd first like to say thank you to James for the comprehensive proposal.=20 The quantum threat is indeed existential, and I appreciate the detailed=20 thinking that went into this migration plan. However, I=E2=80=99d like to= =20 respectfully raise some concerns about the approach and share an=20 alternative perspective from work we=E2=80=99ve been doing in this space. ## Concerns with the Forced Sunset Approach The proposal=E2=80=99s Phase B - rendering ECDSA/Schnorr spends invalid -= =20 essentially threatens users with permanent fund loss. This creates several= =20 issues: 1. **Violation of Bitcoin=E2=80=99s Social Contract**: Satoshi=E2=80=99s pr= inciple that=20 =E2=80=9Clost coins only make everyone else=E2=80=99s coins worth slightly = more=E2=80=9D becomes=20 =E2=80=9Ccoins you don=E2=80=99t migrate in time are forcibly lost.=E2=80= =9D This fundamentally=20 changes Bitcoin=E2=80=99s value proposition. 2. **The 25% Problem**: With ~5.25 million BTC having exposed public keys,= =20 forcing these to become unspendable could create massive economic=20 disruption. Many of these may be genuinely lost coins, but some could be=20 long-term cold storage, inheritance situations, or users who simply miss=20 the migration window. 3. **Timeline Risk**: The 5+ year timeline (3 years post-BIP-360 + 2 years)= =20 assumes smooth consensus and implementation. Given Bitcoin=E2=80=99s histor= y, this=20 could easily stretch to 7-10 years, most likely pushing implementation past= =20 the 2027-2030 quantum timeline mentioned. ## An Alternative Approach: Learning from Supernova Our team has been working on these exact problems and recently reached=20 production readiness with Supernova - a Bitcoin-inspired blockchain that=20 implements quantum resistance from genesis. Rather than forced migration,= =20 we use a dual-signature scheme that might be instructive for Bitcoin: **Three Modes of Operation:** - **Legacy Mode**: ECDSA signatures only (Bitcoin-compatible) - **Transition Mode**: Both ECDSA and quantum signatures required - **Quantum Mode**: Quantum signatures only This approach: - Never locks users out of their funds - Allows gradual, voluntary migration - Maintains backwards compatibility indefinitely - Provides immediate protection for those who want it ## Key Innovations Worth Considering 1. **Hybrid Signatures**: Instead of a hard cutoff, transactions can=20 require both classical and quantum signatures during transition. This=20 provides quantum security while maintaining compatibility. 2. **Address Format Compatibility**: Our quantum addresses (snq1...)=20 coexist with standard addresses (sn1...), allowing users to choose their=20 security level per transaction rather than per wallet. 3. **No Coordination Required**: Users can independently decide when to=20 migrate without waiting for ecosystem-wide coordination. 4. **Proven Implementation**: We=E2=80=99ve demonstrated this works in prod= uction,=20 including the world=E2=80=99s first quantum-resistant Lightning Network. ## A Cooperative Path Forward Rather than viewing this as competition, I see opportunity for=20 collaboration. Supernova could serve as a real-world testbed for quantum=20 migration strategies. We=E2=80=99ve 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= =20 to honor Bitcoin=E2=80=99s principles of decentralization and sound money. ## Invitation to Explore For those interested in seeing quantum resistance in action today rather=20 than waiting years, I invite you to explore Supernova. We=E2=80=99re launch= ing our=20 public testnet soon and would value feedback from the Bitcoin community.=20 The quantum threat is real, and we need multiple approaches to ensure the= =20 future of decentralized money. Whether through Bitcoin=E2=80=99s eventual u= pgrade=20 or alternatives like Supernova, the important thing is that we act before= =20 it=E2=80=99s too late. The code is open source, and we welcome technical review:=20 [github.com/Carbon-Twelve-C12/supernova](https://github.com/Carbon-Twelve-C= 12/supernova) Would love to hear thoughts on the dual-signature approach and whether=20 something similar could work for Bitcoin without the harsh sunset=20 provisions. --- *Note: While I represent the Supernova project, I=E2=80=99m also a long-tim= e=20 Bitcoin supporter who wants to see the entire ecosystem survive the quantum= =20 transition. These challenges affect us all.* On Sunday, July 20, 2025 at 11:56:48=E2=80=AFPM 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= =20 > fork that constrains or blocks currently used spending scenarios. This=20 > applies to both freezing and commit/reveal schemes; the latter may result= =20 > in lost funds if the public key is leaked. I realized that this also=20 > 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*.= =20 > Instead of freezing or constraining all UTXOs at once, we split the UTXO= =20 > set into 256 groups deterministically (for example, by looking at the fir= st=20 > byte of the TXID) and apply the constraints over 256 days, processing one= =20 > group per day. Procrastinators will learn what is happening through word = of=20 > mouth, act to save their funds, and only a small percentage of coin owner= s=20 > will be harmed. > > Another approach is to *provide a temporary opt-out option*. If someone= =20 > finds themselves blocked, they would still have a limited time to take an= =20 > action, without requiring any extra knowledge, to get unblocked. This wou= ld=20 > help raise awareness. After being temporarily blocked and recovering thei= r=20 > funds through the opt-out mechanism, the person would understand that the= y=20 > need to take further steps with their remaining coins to avoid being=20 > permanently blocked once the opt-out period ends. The action to unblock t= he=20 > funds could be as simple as sending a transaction with OP_RETURN "opt-out= =20 > ", which would enable the old acceptance rules for the transaction= =20 > 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 commitmen= t=20 > with a random TXID blocking the coin forever. > > Best, > Boris > > On Saturday, July 12, 2025 at 9:46:09=E2=80=AFPM UTC-3 Jameson Lopp wrote= : > > Building upon my earlier essay against allowing quantum recovery of=20 > bitcoin=20 > I= =20 > wish to formalize a proposal after several months of discussions. > > This proposal does not delve into the multitude of issues regarding post= =20 > quantum cryptography and trade-offs of different schemes, but rather is= =20 > meant to specifically address the issues of incentivizing adoption and=20 > migration of funds *after* consensus is established that it is prudent to= =20 > do so. > > As such, this proposal requires P2QRH as described in BIP-360 or potentia= l=20 > future proposals. > Abstract > > This proposal follows the implementation of post-quantum (PQ) output type= =20 > (P2QRH) and introduces a pre-announced sunset of legacy ECDSA/Schnorr=20 > signatures. It turns quantum security into a private incentive: fail to= =20 > upgrade and you will certainly lose access to your funds, creating a=20 > certainty where none previously existed.=20 > > -=20 > =20 > Phase A: Disallows sending of any funds to quantum-vulnerable=20 > addresses, hastening the adoption of P2QRH address types. > -=20 > =20 > Phase B: Renders ECDSA/Schnorr spends invalid, preventing all spending= =20 > of funds in quantum-vulnerable UTXOs. This is triggered by a=20 > well-publicized flag-day roughly five years after activation. > -=20 > =20 > Phase C (optional): Pending further research and demand, a separate=20 > BIP proposing a fork to allow recovery of legacy UTXOs through ZK proo= f of=20 > possession of BIP-39 seed phrase. =20 > =20 > Motivation > > We seek to secure the value of the UTXO set and minimize incentives for= =20 > quantum attacks. This proposal is radically different from any in Bitcoin= =E2=80=99s=20 > history just as the threat posed by quantum computing is radically=20 > different from any other threat in Bitcoin=E2=80=99s history. Never befo= re has=20 > Bitcoin faced an existential threat to its cryptographic primitives. A=20 > successful quantum attack on Bitcoin would result in significant economic= =20 > disruption and damage across the entire ecosystem. Beyond its impact on= =20 > price, the ability of miners to provide network security may be=20 > significantly impacted. =20 > > -=20 > =20 > Accelerating quantum progress.=20 > -=20 > =20 > NIST ratified three production-grade PQ signature schemes in 2024;= =20 > academic road-maps now estimate a cryptographically-relevant quantu= m=20 > computer as early as 2027-2030. [McKinsey=20 > > ] > -=20 > =20 > Quantum algorithms are rapidly improving > -=20 > =20 > The safety envelope is shrinking by dramatic increases in=20 > algorithms even if the pace of hardware improvements is slower. Alg= orithms=20 > are improving up to 20X=20 > ,=20 > lowering the theoretical hardware requirements for breaking classic= al=20 > encryption. > -=20 > =20 > Bitcoin=E2=80=99s exposed public keys.=20 > -=20 > =20 > Roughly 25% of all bitcoin have revealed a public key on-chain;=20 > those UTXOs could be stolen with sufficient quantum power. =20 > -=20 > =20 > We may not know the attack is underway.=20 > -=20 > =20 > Quantum attackers could compute the private key for known public=20 > keys then transfer all funds weeks or months later, in a covert ble= ed to=20 > not alert chain watchers. Q-Day may be only known much later if the= attack=20 > withholds broadcasting transactions in order to postpone revealing = their=20 > capabilities. > -=20 > =20 > Private keys become public.=20 > -=20 > =20 > Assuming that quantum computers are able to maintain their current= =20 > trajectories and overcome existing engineering obstacles, there is = a near=20 > certain chance that all P2PK (and other outputs with exposed pubkey= s)=20 > private keys will be found and used to steal the funds. > -=20 > =20 > Impossible to know motivations.=20 > -=20 > =20 > Prior to a quantum attack, it is impossible to know the motivations= =20 > of the attacker. An economically motivated attacker will try to re= main=20 > undetected for as long as possible, while a malicious attacker will= attempt=20 > to destroy as much value as possible. =20 > -=20 > =20 > Upgrade inertia.=20 > -=20 > =20 > Coordinating wallets, exchanges, miners and custodians historically= =20 > takes years. > -=20 > =20 > The longer we postpone migration, the harder it becomes to=20 > coordinate wallets, exchanges, miners, and custodians. A clear, tim= e-boxed=20 > pathway is the only credible defense. > -=20 > =20 > Coordinating distributed groups is more prone to delay, even if=20 > everyone has similar motivations. Historically, Bitcoin has been sl= ow to=20 > adopt code changes, often taking multiple years to be approved. > =20 > Benefits at a Glance > =20 > -=20 > =20 > Resilience: Bitcoin protocol remains secure for the foreseeable future= =20 > without waiting for a last-minute emergency. > -=20 > =20 > Certainty: Bitcoin users and stakeholders gain certainty that a plan= =20 > is both in place and being implemented to effectively deal with the th= reat=20 > of quantum theft of bitcoin. =20 > -=20 > =20 > Clarity: A single, publicized timeline aligns the entire ecosystem=20 > (wallets, exchanges, hardware vendors). > -=20 > =20 > Supply Discipline: Abandoned keys that never migrate become=20 > unspendable, reducing supply, as Satoshi described=20 > . =20 > =20 > 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 =E2=80=93 Disallow spends from quantum vulnerable outputs > > At a preset block-height, nodes reject transactions that rely on=20 > ECDSA/Schnorr keys.=20 > > Everyone holding or accepting BTC. > > 2 years after Phase A activation. > > Phase C =E2=80=93 Re-enable spends from quantum vulnerable outputs via ZK= Proof > > Users with frozen quantum vulnerable funds and a HD wallet seed phrase ca= n=20 > 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 > =20 > -=20 > =20 > Even if Bitcoin is not a primary initial target of a cryptographically= =20 > relevant quantum computer, widespread knowledge that such a computer e= xists=20 > and is capable of breaking Bitcoin=E2=80=99s cryptography will damage = faith in the=20 > network .=20 > -=20 > =20 > An attack on Bitcoin may not be economically motivated - an attacker= =20 > may be politically or maliciously motivated and may attempt to destroy= =20 > value and trust in Bitcoin rather than extract value. There is no way= to=20 > know in advance how, when, or why an attack may occur. A defensive=20 > position must be taken well in advance of any attack. =20 > -=20 > =20 > Bitcoin=E2=80=99s current signatures (ECDSA/Schnorr) will be a tantali= zing=20 > target: any UTXO that has ever exposed its public key on-chain (roughl= y 25=20 > % of all bitcoin) could be stolen by a cryptographically relevant quan= tum=20 > computer. > -=20 > =20 > Existing Proposals are Insufficient. =20 > 1.=20 > =20 > Any proposal that allows for the quantum theft of =E2=80=9Clost=E2= =80=9D bitcoin is=20 > creating a redistribution dilemma. There are 3 types of proposals: > 1.=20 > =20 > Allow anyone to steal vulnerable coins, benefitting those who=20 > reach quantum capability earliest. > 2.=20 > =20 > Allow throttled theft of coins, which leads to RBF battles and= =20 > ultimately miners subsidizing their revenue from lost coins. > 3.=20 > =20 > Allow no one to steal vulnerable coins. > -=20 > =20 > Minimizes attack surface > 1.=20 > =20 > By disallowing new spends to quantum vulnerable script types, we=20 > minimize the attack surface with each new UTXO. =20 > 2.=20 > =20 > Upgrades to Bitcoin have historically taken many years; this will= =20 > hasten and speed up the adoption of new quantum resistant script ty= pes.=20 > 3.=20 > =20 > With a clear deadline, industry stakeholders will more readily=20 > upgrade existing infrastructure to ensure continuity of services. = =20 > -=20 > =20 > Minimizes loss of access to funds=20 > 1.=20 > =20 > If there is sufficient demand and research proves possible,=20 > submitting a ZK proof of knowledge of a BIP-39 seed phrase correspo= nding to=20 > a public key hash or script hash would provide a trustless means fo= r legacy=20 > outputs to be spent in a quantum resistant manner, even after the s= unset. =20 > =20 > > Stakeholder > > Incentive to Upgrade > > Miners > > =E2=80=A2 Larger size PQ signatures along with incentive for users to mig= rate will=20 > create more demand for block space and thus higher fees collected by mine= rs. > > =E2=80=A2 Post-Phase B, non-upgraded miners produce invalid blocks. > > =E2=80=A2 A quantum attack on Bitcoin will significantly devalue both the= ir=20 > hardware and Bitcoin as a whole.=20 > > Institutional Holders > > =E2=80=A2 Fiduciary duty: failing to act to prevent a quantum attack on B= itcoin=20 > would violate the fiduciary duty to shareholders. =20 > > =E2=80=A2 Demonstrating Bitcoin=E2=80=99s ability to effectively mitigate= emerging threats=20 > will prove Bitcoin to be an investment grade asset. > > Exchanges & Custodians > > =E2=80=A2 Concentrated risk: a quantum hack could bankrupt them overnight= . > > =E2=80=A2 Early migration is cheap relative to potential losses, potentia= l=20 > lawsuits over improper custody and reputational damage. > > Everyday Users > > =E2=80=A2 Self-sovereign peace of mind. > > =E2=80=A2 Sunset date creates a clear deadline and incentive to improve t= heir=20 > security rather than an open-ended =E2=80=9Csome day=E2=80=9D that invite= s procrastination. > > Attackers > > =E2=80=A2 Economic incentive diminishes as sunset nears, stolen coins can= not be=20 > spent after Q-day. > > Key Insight: As mentioned earlier, the proposal turns quantum security=20 > into a private incentive to upgrade. =20 > > This is not an offensive attack, rather, it is defensive: our thesis is= =20 > that the Bitcoin ecosystem wishes to defend itself and its interests=20 > against those who would prefer to do nothing and allow a malicious actor = to=20 > destroy both value and trust. =20 > > > "Lost coins only make everyone else's coins worth slightly more. Think of= =20 > it as a donation to everyone." - Satoshi Nakamoto > > > If true, the corollary is: > > > "Quantum recovered coins only make everyone else's coins worth less. Thin= k=20 > of it as a theft from everyone." > > > The timelines that we are proposing are meant to find the best balance=20 > between giving ample ability for account owners to migrate while=20 > maintaining the integrity of the overall ecosystem to avoid catastrophic= =20 > attacks. =20 > > Backward Compatibility > > As a series of soft forks, older nodes will continue to operate without= =20 > modification. Non-upgraded nodes, however, will consider all post-quantum= =20 > witness programs as anyone-can-spend scripts. They are strongly encourage= d=20 > to upgrade in order to fully validate the new programs. > > Non-upgraded wallets can receive and send bitcoin from non-upgraded and= =20 > upgraded wallets until Phase A. After Phase A, they can no longer receive= =20 > from any other wallets and can only send to upgraded wallets. After Phas= e=20 > B, both senders and receivers will require upgraded wallets. Phase C woul= d=20 > likely require a loosening of consensus rules (a hard fork) to allow=20 > vulnerable funds recovery via ZK proofs. > > --=20 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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= 173b3bc4-7052-4e0e-9042-ca15cd5b0587n%40googlegroups.com. ------=_Part_439181_135523467.1753441117316 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi All!

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

## Concerns with the Forced Sunset Approach

The pro= posal=E2=80=99s Phase B - rendering ECDSA/Schnorr spends invalid - essentia= lly threatens users with permanent fund loss. This creates several issues:<= br />
1. **Violation of Bitcoin=E2=80=99s Social Contract**: Satoshi= =E2=80=99s principle that =E2=80=9Clost coins only make everyone else=E2=80= =99s coins worth slightly more=E2=80=9D becomes =E2=80=9Ccoins you don=E2= =80=99t migrate in time are forcibly lost.=E2=80=9D This fundamentally chan= ges Bitcoin=E2=80=99s 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, inheritanc= e situations, or users who simply miss the migration window.

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

## An Alternati= ve Approach: Learning from Supernova

Our team has been working o= n these exact problems and recently reached production readiness with Super= nova - a Bitcoin-inspired blockchain that implements quantum resistance fro= m genesis. Rather than forced migration, we use a dual-signature scheme tha= t might be instructive for Bitcoin:

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

This approach:
- Nev= er locks users out of their funds
- Allows gradual, voluntary migratio= n
- Maintains backwards compatibility indefinitely
- Provides imm= ediate 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 tran= sition. 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 C= oordination Required**: Users can independently decide when to migrate with= out waiting for ecosystem-wide coordination.

4. **Proven Impleme= ntation**: We=E2=80=99ve demonstrated this works in production, including t= he world=E2=80=99s first quantum-resistant Lightning Network.

##= A Cooperative Path Forward

Rather than viewing this as competit= ion, I see opportunity for collaboration. Supernova could serve as a real-w= orld testbed for quantum migration strategies. We=E2=80=99ve already implem= ented:

- NIST-standardized algorithms (Dilithium, SPHINCS+, Falc= on)
- Quantum-resistant atomic swaps with Bitcoin
- Full Lightnin= g Network with quantum HTLCs
- Zero-knowledge proofs for enhanced priv= acy

Bitcoin could learn from our implementation experience, whil= e we continue to honor Bitcoin=E2=80=99s principles of decentralization and= sound money.

## Invitation to Explore

For those inte= rested in seeing quantum resistance in action today rather than waiting yea= rs, I invite you to explore Supernova. We=E2=80=99re launching our public t= estnet 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=E2=80=99s eventual = upgrade or alternatives like Supernova, the important thing is that we act = before it=E2=80=99s too late.

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

Would love to hear thought= s on the dual-signature approach and whether something similar could work f= or Bitcoin without the harsh sunset provisions.

---

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

On Sunday, July 20, 2025 a= t 11:56:48=E2=80=AFPM UTC+1 Boris Nagaev wrote:
Hi Jameson, hi all!

I have a coup= le of ideas on how to preserve more funds during any kind of fork that cons= trains or blocks currently used spending scenarios. This applies to both fr= eezing and commit/reveal schemes; the latter may result in lost funds if th= e public key is leaked. I realized that this also applies to the commit/rev= eal scheme I proposed in another thread [1].

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

Another approach is to provide a temporary opt-o= ut 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 blo= cked and recovering their funds through the opt-out mechanism, the person w= ould understand that they need to take further steps with their remaining c= oins to avoid being permanently blocked once the opt-out period ends.=C2=A0= The action to unblock the funds could be as simple as sending a transaction= with OP_RETURN "opt-out <txid>", which would enable the ol= d acceptance rules for the transaction with that txid for a period of 2016 = blocks.


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=E2=80=AFPM UTC-3 Jameson Lopp wro= te:

Building = upon my earlier essay against allowing quantum re= covery of bitcoin I wish to formalize a pro= posal 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 ad= dress 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 p= otential 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 yo= u will certainly lose access to your funds, creating a certainty where none= previously existed.=C2=A0

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

    • <= li dir=3D"ltr" style=3D"list-style-type:disc;font-size:11pt;font-family:&qu= ot;Courier New",monospace;color:rgb(0,0,0);background-color:transparen= t;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-a= lternates:normal;vertical-align:baseline;white-space:pre">

    Phase B: Renders ECDSA/Schnorr spends invalid, preventing all spending of = funds in quantum-vulnerable UTXOs. This is triggered by a well-publicized f= lag-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.=C2=A0=C2=A0

Motivation

We seek to s= ecure the value of the UTXO set <= span style=3D"font-size:11pt;font-family:"Courier New",monospace;= color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;f= ont-variant-east-asian:normal;font-variant-alternates:normal;vertical-align= :baseline">and minimize incentives for quantum attacks. This proposal is ra= dically different from any in Bitcoin=E2=80=99s history just as the threat = posed by quantum computing is radically different from any other threat in = Bitcoin=E2=80=99s history.=C2=A0 Never before has Bitcoin faced an existent= ial threat to its cryptographic primitives. A successful quantum attack on = Bitcoin would result in significant economic disruption and damage across t= he entire ecosystem. Beyond its impact on price, the ability of miners to p= rovide network security may be significantly impacted.=C2=A0=C2=A0

  • Accelerating quantum progress.=C2=A0

    • NIST ratified three production-grade PQ signatu= re schemes in 2024; academic road-maps now estimate a cryptographically-rel= evant 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 im= proving up to 20X, lowering the theoretical hardware requirements for b= reaking classical encryption.

  • Bitcoin=E2=80=99s exposed public keys.=C2=A0

    • Roughly 25% of all bitcoin have r= evealed a public key on-chain; those UTXOs could be stolen with sufficient = quantum power.=C2=A0=C2=A0

  • We may not know the attack is u= nderway.=C2=A0

      Quantum attackers could com= pute 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.=C2= =A0

    • Assuming that quantum com= puters are able to maintain their current trajectories and overcome existin= g 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.=C2=A0

    • Prior to a quantum attack, it is impossible to know t= he motivations of the attacker.=C2=A0 An economically motivated attacker wi= ll try to remain undetected for as long as possible, while a malicious atta= cker will attempt to destroy as much value as possible.=C2=A0=C2=A0<= /p>

  • Upgrade ine= rtia.=C2=A0

    • Coordinating walle= ts, exchanges, miners and custodians historically takes years.

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

    • Coordin= ating distributed groups is more prone to delay, even if everyone has simil= ar motivations. Historically, Bitcoin has been slow to adopt code changes, = often taking multiple years to be approved.

<= span dir=3D"ltr" style=3D"line-height:1.38;text-align:justify;margin-top:14= pt;margin-bottom:6pt">Benefits at a Glance

  • Resilience: B= itcoin protocol remains secure for the foreseeable future without waiting f= or 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.=C2=A0=C2=A0

  • Clarity: A sing= le, publicized timeline aligns the entire ecosystem (wallets, exchanges, ha= rdware vendors).

  • <= p dir=3D"ltr" style=3D"line-height:1.38;text-align:justify;margin-top:0pt;m= argin-bottom:12pt" role=3D"presentation">Supply Discipline: Ab= andoned keys that never migrate become unspendable, reducing supply, as Satoshi described.=C2=A0=C2=A0

    • =
Specification

Phase

What Happens

Who Must Act

Time Horizon

<= p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><= span style=3D"font-size:11pt;font-family:"Courier New",monospace;= color:rgb(0,0,0);background-color:transparent;font-weight:700;font-variant-= numeric:normal;font-variant-east-asian:normal;font-variant-alternates:norma= l;vertical-align:baseline">Phase A - Disallow spends to = legacy script types

Permitted sends are from legacy scripts to P2QRH s= cripts

=

= Everyone holding or accept= ing BTC.

3 years after BIP-360 implementation

=

Phase B =E2=80=93 Disall= ow spends from quantum vulnerable outputs

At a preset block-height, no= des reject transactions that rely on ECDSA/Schnorr keys.=C2=A0

Everyone holding or accepting BTC.

=

2 yea= rs after Phase A activation.

Phase C =E2=80=93 Re-enable spends from quantu= m 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<= ul style=3D"margin-top:0px;margin-bottom:0px">

  • Even if Bitcoin is not a primary initial target of a c= ryptographically relevant quantum computer, widespread knowledge that such = a computer exists and is capable of breaking Bitcoin=E2=80=99s cryptography= will damage faith in the network .=C2=A0

  • An attack on Bitcoin may not be economically= motivated - an attacker may be politically or maliciously motivated and ma= y attempt to destroy value and trust in Bitcoin rather than extract value.= =C2=A0 There is no way to know in advance how, when, or why an attack may o= ccur.=C2=A0 A defensive position must be taken well in advance of any attac= k.=C2=A0=C2=A0

  • Bitcoin=E2=80=99s current signatures (ECDSA/Schnorr) will be a tantaliz= ing target: any UTXO that has ever exposed its public key on-chain (roughly= 25 % of all bitcoin) could be stolen by a cryptographically relevant quant= um computer.

  • Existing Proposals are Insuf= ficient.=C2=A0=C2=A0

    1. Any proposal t= hat allows for the quantum theft of =E2=80=9Clost=E2=80=9D bitcoin is creat= ing a redistribution dilemma. There are 3 types of proposals:

    2. Allow anyone to steal vulnerable coins, benefittin= g those who reach quantum capability earliest.

    3. Allow throttled theft of coins= , which leads to RBF battles and ultimately miners subsidizing their revenu= e from lost coins.

    4. Allow no one to steal vulnerable coins.

    =

  • Minimizes attack surface

    1. By disa= llowing new spends to quantum vulnerable script types, we minimize the atta= ck surface with each new UTXO.=C2=A0=C2=A0

    2. Upgrades to Bitcoin have historicall= y taken many years; this will hasten and speed up the adoption of new quant= um resistant script types.=C2=A0

    3. With a clear deadline, industry stakeholders w= ill more readily upgrade existing infrastructure to ensure continuity of se= rvices.=C2=A0=C2=A0

  • Minimizes loss of access to funds=C2=A0<= /span>

    1. If there is sufficient demand and re= search 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 manne= r, even after the sunset.=C2=A0=C2=A0


    • Stak= eholder

    Incentive to Upgrade

    Miners

    =E2=80=A2 Larger size PQ sign= atures along with incentive for users to migrate will create more demand fo= r block space and thus higher fees collected by miners.

    =E2=80=A2 Post-Phase B, non-upgraded miners produce invalid blocks.

    =E2=80=A2 A quantum attack on Bitcoin will significantly = devalue both their hardware and Bitcoin as a whole.=C2=A0

    =

    Institutional Holders

    =

    =E2=80= =A2 Fiduciary duty: failing to act to prevent a quantum attack on Bitcoin w= ould violate the fiduciary duty to shareholders.=C2=A0=C2=A0

    =E2=80=A2 Demonstrating Bitcoin=E2=80=99s ability to effectively mi= tigate emerging threats will prove Bitcoin to be an investment grade asset.=

    Exchanges &= ; Custodians

    =E2=80=A2 Concentrated risk: a quantum hack could bankrupt t= hem overnight.

    =E2=80=A2 Early migration is cheap rel= ative to potential losses, potential lawsuits over improper custody and rep= utational damage.

    <= span style=3D"border-width:1pt;border-style:solid;border-color:rgb(0,0,0);v= ertical-align:middle;padding:5pt;overflow:hidden">

    Everyday Users

    =E2=80=A2 Self-sovereign peace of mind.

    =E2=80=A2 Sunset date creates a clear deadline and incentive to impr= ove their security rather than an open-ended =E2=80=9Csome day=E2=80=9D tha= t invites procrastination.

    Attackers

    =E2=80=A2 Economic incentive diminishes as sun= set nears, stolen coins cannot be spent after Q-day.

    Key = Insight: As mentioned earlier, the proposal turns quantu= m security into a private incentive to= upgrade.=C2=A0=C2=A0

    This is not = an offensive attack, rather, it is defensive: our thesis is that the Bitcoi= n ecosystem wishes to defend itself and its interests against those who wou= ld prefer to do nothing and allow a malicious actor to destroy both value a= nd trust.=C2=A0=C2=A0


    "Lost coins o= nly make everyone else's coins worth slightly more. Think of it as a do= nation to everyone." - Satoshi Nakamoto

    If true, the corollary is:


    "Q= uantum recovered coins only make everyone else's coins worth less. Thin= k of it as a theft from everyone."

    The timelines that we are proposing are meant to find the best balance bet= ween giving ample ability for account owners to migrate while maintaining t= he integrity of the overall ecosystem to avoid catastrophic attacks.=C2=A0= =C2=A0


    Backward CompatibilityAs a series of soft forks, older nodes will continue to operate w= ithout modification. Non-upgraded nodes, however, will consider all post-qu= antum witness programs as anyone-can-spend scripts. They are strongly encou= raged to upgrade in order to fully validate the new programs.

    Non-upgraded wallets can receive and send bitcoin from non-upg= raded 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.=C2= =A0 After Phase B, both senders and receivers will require upgraded wallets= .=C2=A0Phase 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 &= quot;Bitcoin Development Mailing List" group.
    To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
    To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/173b3bc4-7052-4e0e-9042-ca15cd5b0587n%40googlegroups.com.
    ------=_Part_439181_135523467.1753441117316-- ------=_Part_439180_1061410710.1753441117316--