From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 20 Jul 2025 15:56:55 -0700 Received: from mail-oa1-f58.google.com ([209.85.160.58]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1udcxi-0001W2-2v for bitcoindev@gnusha.org; Sun, 20 Jul 2025 15:56:55 -0700 Received: by mail-oa1-f58.google.com with SMTP id 586e51a60fabf-2ff9a569aebsf4486843fac.0 for ; Sun, 20 Jul 2025 15:56:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1753052208; x=1753657008; 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=y0QBDRSSotBQ6zE1cCFrAFdsd6QxJjgg9W9/ncyP3l0=; b=YDLGq8VkLXR45/go7DpFEtE41W2f3GBcnI4PM308qQVaPYoaqjK6iWB6NmFgX5PLsp cgO0RfC8sL4d5Uf64BfLhS4cKU0u2hdAiz4UueAUd2hjX/G0VGxTrSLNsvwrlNKzfdJR L2XbqtVkvd0hoA58xb3h+kMnU3WSdpylyq7Ps6L/gebHZ7sPTLMWoKiIxIqn7L/3zh5U T3XCGxglKPKKEgJaREQobCoBHHCA2rS+UynbToeuIZm7YCH7WfdNp6gFl0qvDTLgYQs2 0Mhhxu8dyNxzUTM/w0VVZfMuKwcOWrUdmH5Nu/iHyGjq8vBGfc2DZmpPKRUaHXTSvLQy 2igw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1753052208; x=1753657008; 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=y0QBDRSSotBQ6zE1cCFrAFdsd6QxJjgg9W9/ncyP3l0=; b=EDXKgiZ08rZaqVgkaVaBrfSik9UWllYYSflzJmF+MWsNbWSOECJ2GesrTLrdcSQm13 +QnmnTlQge5FzdDoOJXbEAH9dmv9RTQ+Jhyh+3ftfnLqwrllAPzOWYh4DxlrLr8Wi/vA b/wgRyudtURISI0J611BrJuZ1sBM6d7rDwSljG/apCkB/wYcuLclwjGNSla2sg6Mf4kc dsoVixcxNxYR1y9Tu25HSHwiHR1i6A0n1/r3AWDv2ppB8W0ecflhoiCh31QAVBBkZ5MV Lb4fnWg0KTrHEnubEqQ7HNVeGLVQ/oY4yIu9Dw557W2xUNtxNBk3cbM3K96XnvdSG89s 0rNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1753052208; x=1753657008; 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=y0QBDRSSotBQ6zE1cCFrAFdsd6QxJjgg9W9/ncyP3l0=; b=SDM6j/EqmCLZqEQTJeS4JewORcyAxTGD8IfgnGs8l/pjMkDeukKNg25mZTu/8qw1WX A1WUQ4K3o1ys2bmLC+AYUeSqbf3/jA9oQU7+XqFOhSaipRCpmwYna2+8rG5vgKP6EfdJ Q0wyn9Zk48GxflE3sKNP6WdlX8bbesJi7Lau85jdYMTbvLelWrLNADLU2rRecxq6mHAU uq4vwvq6wChaQJKhCcka3AUgHkmy9BTJzpDxgxbxFmXEV9qCwKRXjdXuYoqto4ACvOhJ W41u+tUs5foM7nDBtnX4sH5h4e6vWlNxX2ErMUJhqf5aht1Ub546FLPVtWviZ2tFhqeS +BfQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCVpQjrWegbo+LRhZ0Te0TUojO2VM4I8Ygsar3pLBoxJChTU9Ql9STzmlZ/n67jpOSKQvG5YkibgcCT9@gnusha.org X-Gm-Message-State: AOJu0Yxc/AHPyXyd78MjGk74baLUe+NFafYinD9s4gI9EasyQWnJrwqt u4Fw1n0cRjUEVUupYQYyJy6EiRgmYYR9lZzCdDuCYM8MnuHl+QIqsumA X-Google-Smtp-Source: AGHT+IH4q9XC1kWgDwMz1hu3NE/FVBGRmh0KUQIwJQ1tDldqFQt0i7e/yiLgNstYoOsO2hqQUPo4jw== X-Received: by 2002:a05:6870:d390:b0:2da:b440:5b1 with SMTP id 586e51a60fabf-2ffcc17730emr10304613fac.5.1753052207900; Sun, 20 Jul 2025 15:56:47 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZcVhFttopjCm7RsrY5No8ZaCrZXPfWswYnC6w6ZzYRmBw== Received: by 2002:a05:6870:6c02:b0:2ff:8cb6:b720 with SMTP id 586e51a60fabf-2ffca3d2a0als2760999fac.0.-pod-prod-05-us; Sun, 20 Jul 2025 15:56:44 -0700 (PDT) X-Received: by 2002:a05:6808:6c88:b0:40c:fe59:8405 with SMTP id 5614622812f47-41d056571d1mr13980455b6e.31.1753052204068; Sun, 20 Jul 2025 15:56:44 -0700 (PDT) Received: by 2002:a05:690c:9989:b0:711:63b1:720 with SMTP id 00721157ae682-7194e2f0e64ms7b3; Sun, 20 Jul 2025 15:54:40 -0700 (PDT) X-Received: by 2002:a05:690c:f8b:b0:719:671d:255 with SMTP id 00721157ae682-719671d039cmr83766007b3.3.1753052079837; Sun, 20 Jul 2025 15:54:39 -0700 (PDT) Date: Sun, 20 Jul 2025 15:54:39 -0700 (PDT) From: Boris Nagaev To: Bitcoin Development Mailing List Message-Id: In-Reply-To: References: Subject: [bitcoindev] Re: A Post Quantum Migration Proposal MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_267154_1311451799.1753052079455" X-Original-Sender: bnagaev@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_267154_1311451799.1753052079455 Content-Type: multipart/alternative; boundary="----=_Part_267155_1449090592.1753052079455" ------=_Part_267155_1449090592.1753052079455 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 first= =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 owners= =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 would= =20 help raise awareness. After being temporarily blocked and recovering their= =20 funds through the opt-out mechanism, the person would understand that they= =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 the= =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 commitment= =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 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 potential= =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 addresses,= =20 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 BIP= =20 proposing a fork to allow recovery of legacy UTXOs through ZK proof 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 before= 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 quantum= =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 algorithms= =20 even if the pace of hardware improvements is slower. Algorithms are i= mproving=20 up to 20X=20 ,=20 lowering the theoretical hardware requirements for breaking classical= =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; those= =20 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 keys= =20 then transfer all funds weeks or months later, in a covert bleed to n= ot=20 alert chain watchers. Q-Day may be only known much later if the attac= k=20 withholds broadcasting transactions in order to postpone revealing th= eir=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 pubkeys)= =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 rema= in=20 undetected for as long as possible, while a malicious attacker will a= ttempt=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 coordinate= =20 wallets, exchanges, miners, and custodians. A clear, time-boxed pathw= ay is=20 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 slow= 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 is= =20 both in place and being implemented to effectively deal with the threat = of=20 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 unspendable,= =20 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 P= roof Users with frozen quantum vulnerable funds and a HD wallet seed phrase can= =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 exi= sts=20 and is capable of breaking Bitcoin=E2=80=99s cryptography will damage fa= ith in the=20 network .=20 -=20 =20 An attack on Bitcoin may not be economically motivated - an attacker may= =20 be politically or maliciously motivated and may attempt to destroy value= =20 and trust in Bitcoin rather than extract value. There is no way to know= in=20 advance how, when, or why an attack may occur. A defensive position mus= t=20 be taken well in advance of any attack. =20 -=20 =20 Bitcoin=E2=80=99s current signatures (ECDSA/Schnorr) will be a tantalizi= ng=20 target: any UTXO that has ever exposed its public key on-chain (roughly = 25=20 % of all bitcoin) could be stolen by a cryptographically relevant quantu= m=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 type= s.=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 correspond= ing to=20 a public key hash or script hash would provide a trustless means for = legacy=20 outputs to be spent in a quantum resistant manner, even after the sun= set. =20 =20 Stakeholder Incentive to Upgrade Miners =E2=80=A2 Larger size PQ signatures along with incentive for users to migra= te will=20 create more demand for 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= =20 hardware and Bitcoin as a whole.=20 Institutional Holders =E2=80=A2 Fiduciary duty: failing to act to prevent a quantum attack on Bit= coin=20 would violate the fiduciary duty to shareholders. =20 =E2=80=A2 Demonstrating Bitcoin=E2=80=99s ability to effectively mitigate e= merging 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, potential = lawsuits=20 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 the= ir=20 security rather than an open-ended =E2=80=9Csome day=E2=80=9D that invites = procrastination. Attackers =E2=80=A2 Economic incentive diminishes as sunset nears, stolen coins canno= t be=20 spent after Q-day. Key Insight: As mentioned earlier, the proposal turns quantum security into= =20 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. Think= =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 encouraged= =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 Phase= =20 B, both senders and receivers will require upgraded wallets. Phase C would= =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/= cfb00fb3-1eeb-40c5-acc3-50d1919d7dben%40googlegroups.com. ------=_Part_267155_1449090592.1753052079455 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 scheme= s; the latter may result in lost funds if the public key is leaked. I reali= zed that this also applies to the commit/reveal scheme I proposed in anothe= r thread [1].

The idea is to roll out such forks increme= ntally across the UTXO set. Instead of freezing or constraining all UTX= Os at once, we split the UTXO set into 256 groups deterministically (for ex= ample, by looking at the first byte of the TXID) and apply the constraints = over 256 days, processing one group per day. Procrastinators will learn wha= t is happening through word of mouth, act to save their funds, and only a s= mall percentage of coin owners will be harmed.

A= nother 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 perma= nently blocked once the opt-out period ends.=C2=A0The 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 transact= ion with that txid for a period of 2016 blocks.

=
[1]=C2=A0https://groups.google.com/g/bitcoindev/c/uUK6py0Y= jq0/m/57bQJ3VSCQAJ
In that scheme if the pubkey is leaked, anyone= can post a valid commitment with a random TXID blocking the coin forever.<= /div>

Best,
Boris

On Saturday, July 12, 2025 at 9:46:09=E2=80=AFPM UTC-3 Jameso= n Lopp wrote:

Building upon my earlier essa= y against allowing q= uantum recovery of bitcoin I wish to formalize a proposal after several months of discussions.<= /span>

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.

Abst= ract

This proposal foll= ows the implementation of post-quantum (PQ) output type (P2QRH) and introdu= ces a pre-announced sunset of legacy ECDSA/Schnorr signatures. It turns qua= ntum security into a private incentive: fail to upgrad= e and you will certainly lose access to your funds, creating a certainty wh= ere none previously existed.=C2=A0

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

  • Renders ECDSA/Schnorr= spends invalid, preventing all spending of funds in quantum-vulnerable UTX= Os. This is triggered by a well-publicized flag-day roughly five years afte= r activation.

  • Phase C (optional): Pending further research and demand, a separ= ate 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<= /span>

We seek t= o secure the value of the UTXO set and minimize incentiv= es for quantum attacks. This proposal is radically different from any in Bi= tcoin=E2=80=99s history just as the threat posed by quantum computing is ra= dically different from any other threat in Bitcoin=E2=80=99s history.=C2=A0= Never before has Bitcoin faced an existential threat to its cryptographic = primitives. A successful quantum attack on Bitcoin would result in signific= ant economic disruption and damage across the entire ecosystem. Beyond its = impact on price, the ability of miners to provide network security may be s= ignificantly impacted.=C2=A0=C2=A0

  • Accelerating quantum progress.=C2=A0

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

  • <= p dir=3D"ltr" style=3D"line-height: 1.38; text-align: justify; margin-top: = 0pt; margin-bottom: 0pt;" role=3D"presentation">Quantum algorithms are rapidly improving

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

    • <= li dir=3D"ltr" style=3D"list-style-type: disc; font-size: 11pt; font-family= : "Courier New", monospace; color: rgb(0, 0, 0); background-color= : transparent; font-variant-numeric: normal; font-variant-east-asian: norma= l; font-variant-alternates: normal; vertical-align: baseline; white-space: = pre;">

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

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

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

    • 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 l= ater if the attack withholds broadcasting transactions in order to postpone= revealing their capabilities.

  • Priva= te keys become public.=C2=A0

    • Assuming that quantum comp= uters are able to maintain their current trajectories and overcome existing= engineering obstacles, there is a near certain chance that all P2PK (and o= ther outputs with exposed pubkeys) private keys will be found and used to s= teal the funds.

  • Impossible to know m= otivations.=C2=A0

    • Prior to a quantum attack, it is impo= ssible to know the motivations of the attacker.=C2=A0 An economically motiv= ated attacker will try to remain undetected for as long as possible, while = a malicious attacker will attempt to destroy as much value as possible.=C2= =A0=C2=A0

  • Upgrade inertia.=C2=A0

    • Coordinating wallets, exchanges, miners and custod= ians historically takes years.

    • The longer= we postpone migration, the harder it becomes to coordinate wallets, exchan= ges, miners, and custodians. A clear, time-boxed pathway is the only credib= le defense.

    • Coordinating distributed gro= ups is more prone to delay, even if everyone has similar motivations. Histo= rically, Bitcoin has been slow to adopt code changes, often taking multiple= years to be approved.

Benefits at a Glance<= ul style=3D"margin-top: 0px; margin-bottom: 0px;">

  • Resilience: Bit= coin 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 impl= emented to effectively deal with the threat of quantum theft of bitcoin.=C2= =A0=C2=A0

  • Clarity: A single, publicized timeline al= igns the entire ecosystem (wallets, exchanges, hardware vendors).

  • S= upply Discipline: Abandoned keys that never migrate become= unspendable, reducing supply, as Satoshi= described.=C2=A0=C2=A0

    • Specification<= /span>=

    Phase

    <= span style=3D"font-size: 11pt; font-family: "Courier New", monosp= ace; color: rgb(0, 0, 0); background-color: transparent; font-weight: 700; = font-variant-numeric: normal; font-variant-east-asian: normal; font-variant= -alternates: normal; vertical-align: baseline;">What Happens

    Who Must A= ct

    Time Horizon

    Phase A - Disallow spends to legacy script types

    Permitted sends are from legacy scripts to P2QRH scrip= ts

    Everyone= holding or accepting BTC.

    =

    3 years after BIP-360 implementation

    Phase B =E2=80=93 Dis= allow spends from quantum vulnerable outputs

    At a preset block-height, nodes reject transactions that r= ely on ECDSA/Schnorr keys.=C2=A0

    Everyone holdin= g or accepting BTC.

    2 years aft= er Phase A activation.

    Phase C =E2=80=93 Re-enable spends from quantum vulnerable outputs vi= a ZK Proof

    Users with frozen qu= antum 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 i= nitial target of a cryptographically 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 may 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 occur.=C2=A0 A= defensive position must be taken well in advance of any attack.=C2=A0=C2= =A0

    • = Bitcoin=E2=80=99s current signatures (E= CDSA/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.=C2=A0=C2=A0

      1. Any proposal that all= ows for the quantum theft of =E2=80=9Clost=E2=80=9D bitcoin is creating a r= edistribution dilemma. There are 3 types of proposals:

        1. Allow any= one to steal vulnerable coins, benefitting those who reach quantum capabili= ty earliest.

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

        3. Allow no= one to steal vulnerable coins.

    • Minimizes attack surface

      1. By disallo= wing new spends to quantum vulnerable script types, we minimize the attack = surface with each new UTXO.=C2=A0=C2=A0

      2. Upgrades to Bitcoin have historically taken many years; this will haste= n and speed up the adoption of new quantum resistant script types.=C2=A0

      3. With a clear deadline, industry stakeh= olders will more readily upgrade existing infrastructure to ensure continui= ty of services.=C2=A0=C2=A0

    • Minimizes loss of access to funds=C2=A0

      1. If there= is sufficient demand and research proves possible, submitting a ZK proof o= f 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.=C2=A0=C2=A0


    Stak= eholder

    Incentiv= e to Upgrade

    Miners

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

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

    =E2=80=A2 A quantum attack on Bitco= in 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 q= uantum attack on Bitcoin would violate the fiduciary duty to shareholders.= =C2=A0=C2=A0

    =E2=80=A2 Demon= strating Bitcoin=E2=80=99s ability to effectively mitigate emerging threats= will prove Bitcoin to be an investment grade asset.

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

    =E2=80=A2 Early migration is ch= eap relative to potential losses, potential lawsuits over improper custody = and reputational damage.

    = Everyday Users

    <= /span>

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

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

    Attackers

    =E2=80= =A2 Economic incentive diminishes as sunset nears, stolen coins cannot be s= pent after Q-day.

    Key Insigh= t: As mentioned earlier, the proposal= turns quantum security into a private incentive to upgrade.=C2=A0=C2=A0

    This is n= ot an offensive attack, rather, it is defensive: our thesis is that the Bit= coin ecosystem wishes to defend itself and its interests against those who = would prefer to do nothing and allow a malicious actor to destroy both valu= e and trust.=C2=A0=C2=A0


    "Lost coins only make everyone else's coins wort= h 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 w= orth less. Think of it as a theft from everyone."

    =

    The timelines that we are proposing ar= e meant to find the best balance between giving ample ability for account o= wners to migrate while maintaining the integrity of the overall ecosystem t= o avoid catastrophic attacks.=C2=A0=C2=A0


    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 st= rongly encouraged to upgrade in order to fully validate the new programs.


    Non-upgraded wallets ca= n receive and send bitcoin from non-upgraded and upgraded wallets until Pha= se 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 re= ceivers will require upgraded wallets.=C2=A0Phase C would likely require a = loosening of consensus rules (a hard fork) to allow vulnerable funds recove= ry 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/cfb00fb3-1eeb-40c5-acc3-50d1919d7dben%40googlegroups.com.
    ------=_Part_267155_1449090592.1753052079455-- ------=_Part_267154_1311451799.1753052079455--