From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 15 Jul 2025 11:04:00 -0700 Received: from mail-yw1-f184.google.com ([209.85.128.184]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1ubk0S-0003vM-F3 for bitcoindev@gnusha.org; Tue, 15 Jul 2025 11:04:00 -0700 Received: by mail-yw1-f184.google.com with SMTP id 00721157ae682-71111a7c31csf95874247b3.3 for ; Tue, 15 Jul 2025 11:03:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1752602627; x=1753207427; 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=+zR9MYo8vQgfchdMRYUShHezRZq8a9L9ccDgvgUQ0Zg=; b=v+0ONfybyJV0qZjJHRyidkESTVyqCD1ElPtrhh7AE+I6ghfLoOJHvV6UIA5BgLE+va tJtf9S4MOO/xAKbE/mwzJIYcNY6YBhgbrrB+essJscaTTzk1zTMSZecn5dyGkj02L6jO ydpyidcFoAfQ6TZdqXGbNq2UaQjNOl1OKKfHl9jXKWkMoE029mgKE4tZjGdQK1jGsCTV u2fxwT4Zsnx7Mm//tMF2zHmMtB3nwVY0R1jmjkMRRjUZ36HJNdI/6dp7VFu0ZH/R6SnG A71/MewUpzcIQ9UJ3o0d1aM39bETEvBTtlsFDoZPbPQ41pIwH/oP8LSu9bm5fuCWuI4x V2Dg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1752602627; x=1753207427; 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=+zR9MYo8vQgfchdMRYUShHezRZq8a9L9ccDgvgUQ0Zg=; b=GMqRdgy0myJIKneSA8UEaMDsw1CVJp0lKRA2vWFK23Z7aYc3DSF8tkAcWQIyYO70wT 2ln5ndZZos2gMffpJHuXTfNIgEbanByh4nS95gec0RNb6l9BWFuoHgnAYTOvEoMGu3Xs 9UFJJCrHMTHW+g+gk06i3z0Sc7gn90MpXaMrAZyCPho86iRd8Hb3SrZiZXkC/GBgj/U2 8/7TYRYua33FbrswUOAvkAeW6BUiggipGUH+Ap2UR+X2+vTWYLJKvKmZK44jr3zqVGgI qSBKtuTfPaoRtN0pYS2H64espaJ/Y5fgGV3fgRlM6smZ0G9u2fy7t66pOJQ69064y2mX X2iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752602627; x=1753207427; 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=+zR9MYo8vQgfchdMRYUShHezRZq8a9L9ccDgvgUQ0Zg=; b=rJ9jqHY03DbAY7BWDd4dTJGxBXS62WtAhz8aeDnH5yQfZ26pI4gpvy6v+y6AuXNYwo NeUZyxRKCMJQTlAMHo0YYSnjvjBZ5VbIM4Iq5ddHEUbdrhPdH1f5qD7GJbyTNXDe0AYW L2veRLJ/zit/uFiaAa/RS0q6/5ZyZOloQ3KSiH8waUR9QNRdPtjbIROnmcnN/3NJbAS0 JDbRISxPZyQ6Rg83kB9Kkqa5THT0N3NHfmQ1BY5VZuqphT3hk8/rUcD3EaKf1tn4+5fe i3oLCeu/L4iILizx8P18PsVDaoSgaY8I7rdTnXEor/ALBSnUZBv0J2evMRqnuOnwg8EW LSQA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCW5KNw5S5peP9uMpY2p1NtF9KYrebpRQvqfrucopWCQUxH7R2I+ae3jFDNQQSTCG/FzH102wfSYoI9a@gnusha.org X-Gm-Message-State: AOJu0YwGMEgloHzAzhKad355dd07/V0WqOe3cR4ZaxO6vg7Ha5FyrWod 8AgksF1QF/R5abOC3F+cJzD/0iklx+gm0If/X6Rhn2dH1RjBq1NbQUP8 X-Google-Smtp-Source: AGHT+IHXdp8t7QnQj5jkeoD5+9G+OgkWDkoq0XQMNNi01nKeo8TUjGfvH31uLK7haCYsisSkyT7IFA== X-Received: by 2002:a05:690c:4913:b0:70e:29af:844a with SMTP id 00721157ae682-718350427c1mr2658627b3.18.1752602626451; Tue, 15 Jul 2025 11:03:46 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZfoFKiLqTRfP543zT4LkSWjlGGVKIXmMdjl5JriTGmkVw== Received: by 2002:a25:dc94:0:b0:e82:21c7:6973 with SMTP id 3f1490d57ef6-e8b7786fa77ls5143856276.0.-pod-prod-04-us; Tue, 15 Jul 2025 11:03:41 -0700 (PDT) X-Received: by 2002:a05:690c:638a:b0:708:cd31:88a9 with SMTP id 00721157ae682-71835192cb1mr2266687b3.37.1752602621555; Tue, 15 Jul 2025 11:03:41 -0700 (PDT) Received: by 2002:a05:690c:2e08:b0:711:63b1:720 with SMTP id 00721157ae682-718014dfe64ms7b3; Tue, 15 Jul 2025 07:13:40 -0700 (PDT) X-Received: by 2002:a05:690c:6901:b0:70f:6ebb:b29a with SMTP id 00721157ae682-717d5e0e8d0mr249543737b3.29.1752588818498; Tue, 15 Jul 2025 07:13:38 -0700 (PDT) Date: Tue, 15 Jul 2025 07:13:38 -0700 (PDT) From: Boris Nagaev To: Bitcoin Development Mailing List Message-Id: <88a7b020-e84f-4052-9716-fb40b23f07ddn@googlegroups.com> In-Reply-To: References: Subject: Re: [bitcoindev] A Post Quantum Migration Proposal MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_103548_1163467746.1752588818047" 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_103548_1163467746.1752588818047 Content-Type: multipart/alternative; boundary="----=_Part_103549_211251283.1752588818047" ------=_Part_103549_211251283.1752588818047 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Conduition, hi Jameson, hi all! What if all vulnerable coins are temporarily locked during phase B, with a= =20 clearly defined future block height X (e.g., in 5-10 years) at which point= =20 these coins become EC-spendable again? This would give us time to develop= =20 recovery mechanisms for phase C. It also wouldn't require a hard fork,=20 since the unlocking height X would already be part of the consensus rules= =20 introduced in phase B. In this way, we avoid a hard fork altogether.=20 Instead of permanent freezing, a forced timelock would be applied to=20 vulnerable outputs. Beyond merely avoiding a hard fork, this approach offers additional=20 benefits. It improves the situation for owners of vulnerable coins who=20 missed the initial deadline, since a timelock is preferable to permanent=20 freezing. To be clear, I am not advocating for locking the coins -- even=20 temporarily. However, if a choice must be made, temporary locking is=20 clearly preferable to permanent freezing. Developers working on recovery=20 mechanisms would have a clear timeline and incentive to deliver phase C as= =20 a subsequent soft fork. At the same time, the community gains valuable time= =20 for data-driven decision-making -- allowing us to adapt based on how events= =20 unfold, including whether legitimate claims are made on locked coins, and= =20 based on future developments in quantum computing. This assumes that phases A and B are deployed before a real quantum threat= =20 materializes. If, in the meantime, fundamental research concludes that=20 quantum computing will not break EC for the next 100 years, we can simply= =20 do nothing -- and the coins will unlock automatically at height X. On the= =20 other hand, if quantum computing advances significantly, we can respond=20 based on the availability and quality of recovery schemes: either deploy a= =20 recovery soft fork at block X, or apply another soft fork to postpone=20 unlocking by another 5-10 years. Best, Boris On Tuesday, July 15, 2025 at 8:36:33=E2=80=AFAM UTC-3 conduition wrote: Hi Jameson, I like your proposal, and economically so should anyone who owns Bitcoin. I= =20 don't see any solid incentive-based motivation to let QCs "free up"=20 vulnerable coins, other than maybe as an early-warning indicator. This is= =20 impossible to prove, but I personally believe almost all dormant bitcoins= =20 that would be locked by phase B are already permanently lost (dead=20 addresses, dead owners, etc). I do think we should delay phase B as long as we can, to give as many=20 people time to upgrade as possible. The time horizons should be flexible=20 and allow us to react to changes, in case practical quantum computers take= =20 much more/less time to arrive than we expect today. Commit/reveal protocols described in other mailing list threads are a=20 tempting way to rescue some quantum-vulnerable funds, without the=20 complexity of zk-STARKs... but these protocols would be difficult to=20 explain to users, and they only work for addresses whose pubkeys haven't=20 been exposed yet. This makes implementation hard. It rules out many=20 existing UTXOs, and all P2TR UTXOs too. At this point I don't feel=20 commit/reveal is worth the engineering effort and research given those=20 limitations. It's reasonable that you left these out of your proposal. It's true that phase C would require a hard fork if we first deploy phase= =20 B, because phase B explicitly closes the door on spending from pre-quantum= =20 addresses. However, I believe zk-STARK proof unlocking could be executed as= =20 a soft fork if you combine phases B and C together into a single upgrade.= =20 This way, there is never a delta in the consensus rules in which EC=20 spending rules need to be relaxed.=20 - *Before*: allow spending P2PKH if given a valid sig/pubkey.=20 - *After*: allow spending P2PKH if given a valid sig/pubkey AND a valid= =20 ZK proof of seed-phrase-based key derivation (e.g. BIP39).=20 =20 With this combined approach, we would never see a period of time in which= =20 average users with mnemonic-seed wallets are locked out of their funds, and= =20 we need no hard forks at all. regards, conduition On Saturday, July 12th, 2025 at 5:46 PM, Jameson Lopp = =20 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 remai= n=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 must= be=20 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= =20 "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an= =20 email to bitcoindev+...@googlegroups.com. To view this discussion visit=20 https://groups.google.com/d/msgid/bitcoindev/CADL_X_fpv-aXBxX%2BeJ_EVTirkAJ= GyPRUNqOCYdz5um8zu6ma5Q%40mail.gmail.com . --=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/= 88a7b020-e84f-4052-9716-fb40b23f07ddn%40googlegroups.com. ------=_Part_103549_211251283.1752588818047 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Conduition, hi=C2=A0Jameson,=C2=A0hi all!

What if all vulnerable coins are temporarily locked during phase B, with = a clearly defined future block height X (e.g., in 5-10 years) at which poin= t these coins become EC-spendable again? This would give us time to develop= recovery mechanisms for phase C. It also wouldn't require a hard fork, sin= ce the unlocking height X would already be part of the consensus rules intr= oduced in phase B. In this way, we avoid a hard fork altogether. Instead of= permanent freezing, a forced timelock would be applied to vulnerable outpu= ts.
Beyond merely avoiding a hard fork, this approach offers add= itional benefits. It improves the situation for owners of vulnerable coins = who missed the initial deadline, since a timelock is preferable to permanen= t freezing. To be clear, I am not advocating for locking the coins -- even= =20 temporarily. However, if a choice must be made, temporary locking is=20 clearly preferable to permanent freezing. Developers working on recovery me= chanisms would have a clear timeline and incentive to deliver phase C as a = subsequent soft fork. At the same time, the community gains valuable time f= or data-driven decision-making -- allowing us to adapt based on how events = unfold, including whether legitimate claims are made on locked coins, and b= ased on future developments in quantum computing.

This assu= mes that phases A and B are deployed before a real quantum threat materiali= zes. If, in the meantime, fundamental research concludes that quantum compu= ting will not break EC for the next 100 years, we can simply do nothing -- = and the coins will unlock automatically at height X. On the other hand, if = quantum computing advances significantly, we can respond based on the avail= ability and quality of recovery schemes: either deploy a recovery soft fork= at block X, or apply another soft fork to postpone unlocking by another 5-= 10 years.

Best,
Boris
=

On Tuesday, July 15, 2025 at 8:36:3= 3=E2=80=AFAM UTC-3 conduition wrote:
Hi= Jameson,

I like your proposal, and economically so should anyone who owns Bitco= in. I don't see any solid incentive-based motivation to let QCs "free up" v= ulnerable coins, other than maybe as an early-warning indicator. This is im= possible to prove, but I personally believe almost all dormant bitcoins tha= t would be locked by phase B are already permanently lost (dead addresses, = dead owners, etc).

I do think we should delay phase B as long as we can, to give= as many people time to upgrade as possible. The time horizons should be fl= exible and allow us to react to changes, in case practical quantum computer= s take much more/less time to arrive than we expect today.

Commit/reveal protoc= ols described in other mailing list threads are a tempting way to rescue so= me quantum-vulnerable funds, without the complexity of zk-STARKs... but the= se protocols would be difficult to explain to users, and they only work for= addresses whose pubkeys haven't been exposed yet. This makes implementatio= n hard. It rules out many existing UTXOs, and all P2TR UTXOs too. At this p= oint I don't feel commit/reveal is worth the engineering effort and researc= h given those limitations. It's reasonable that you left these out of your = proposal.

It's true that phase C would require a hard fork if we first deploy ph= ase B, because phase B explicitly closes the door on spending from pre-quan= tum addresses. However,=C2=A0I believe zk-STARK proof unlocking could= be executed as a soft fork if you combine phases B and C together into a s= ingle upgrade. This way, there is never a delta in the consensus rules in w= hich EC spending rules need to be relaxed.=C2=A0

=
  • Before: allow spending P2PKH if given a va= lid sig/pubkey.=C2=A0
  • After: allow spending P2PKH if given a valid= sig/pubkey AND a valid ZK proof of seed-phrase-based key derivation (e.g. = BIP39).=C2=A0

With this combi= ned approach, we would never see a period of time in which average users wi= th mnemonic-seed wallets are locked out of their funds, and we need no hard= forks at all.

regards,
conduition
=
On Saturday, July 12th, 2025 at 5:46 PM, Jameson Lopp <jameso...@gmail.com> wrote:

Bui= lding 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, bu= t rather is meant to specifically address the issues of incentivizing adopt= ion and migration of funds after consensus is established tha= t it is prudent to do so.

As such, this proposal requi= res 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. <= /span>

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

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

    <= /li>

  • 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 BI= P-39 seed phrase.

Motivation

We seek to secure the value of the UTXO= set and minimize incentives for quantum attacks. This p= roposal is radically different from any in Bitcoin=E2=80=99s history just a= s the threat posed by quantum computing is radically different from any oth= er threat in Bitcoin=E2=80=99s history. Never before has Bitcoin faced an = existential threat to its cryptographic primitives. A successful quantum at= tack on Bitcoin would result in significant economic disruption and damage = across the entire ecosystem. Beyond its impact on price, the ability of min= ers to provide network security may be significantly impacted.

=

  • Acc= elerating 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-20= 30. [McKinsey]

  • Quant= um algorithms are rapidly improving

    • The safety envelope is shrink= ing by dramatic increases in algorithms even if the pace of hardware improv= ements is slower. Algorithms are improving up to 20X, lowering the theoretic= al hardware requirements for breaking classical encryption.

      • =

  • Bitcoin=E2=80=99s exposed public keys.<= span style=3D"font-size: 11pt; background-color: transparent; font-variant-= numeric: normal; font-variant-east-asian: normal; font-variant-alternates: = normal; vertical-align: baseline;">

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

  • We may no= t know the attack is underway.

    • Quantum attackers could compute t= he private key for known public keys then transfer all funds weeks or month= s later, in a covert bleed to not alert chain watchers. Q-Day may be only k= nown 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 tha= t all P2PK (and other outputs with exposed pubkeys) private keys will be fo= und and used to steal the funds.

  • Prior to a qu= antum 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 val= ue as possible.

  • Upgrade inert= ia.

    • Coordinating wallets, exchanges, miner= s and custodians historically takes years.

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

    • Coordi= nating distributed groups is more prone to delay, even if everyone has simi= lar motivations. Historically, Bitcoin has been slow to adopt code changes,= often taking multiple years to be approved.

    • = Benefits at a= Glance

      Res= ilience: Bitcoin protocol remains secure for the foreseeab= le future without waiting for a last-minute emergency.

    • Certaint= y: Bitcoin users and stakeholders gain certainty that a pl= an is both in place and being implemented to effectively deal with the thre= at of quantum theft of bitcoin.

    • Clarity: A s= ingle, publicized timeline aligns the entire ecosystem (wallets, exchanges,= hardware vendors).

    • Supply Discipline: Abando= ned keys that never migrate become unspendable, reducing supply, as Satoshi described= .

    Specification

    Phase

    What Happens

    Who Must Act

    Time Horizon

    <= /span>

    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 vuln= erable outputs

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

    Everyone<= span style=3D"font-size: 10pt; font-family: "Courier New", monosp= ace; color: rgb(0, 0, 0); background-color: transparent; font-variant-numer= ic: normal; font-variant-east-asian: normal; font-variant-alternates: norma= l; vertical-align: baseline;"> holding or accepting BTC.

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

    2 years after Phase A activation.

    Phase C =E2=80=93 Re-enable spen= ds 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 bef= ore Phase B.

    TBD pending resear= ch, demand, and consensus.

    Rationale

    • Even if Bitcoin is not a primary initial target of a cryptographica= lly relevant quantum computer, widespread knowledge that such a computer ex= ists and is capable of breaking Bitcoin=E2=80=99s cryptography will damage = faith in the network .

    • An attack on B= itcoin may not be economically motivated - an attacker may be politically o= r maliciously motivated and may attempt to destroy value and trust in Bitco= in 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 a= dvance of any attack.

    • Bitcoin=E2=80= =99s current signatures (ECDSA/Schnorr) will be a tantalizing target: any U= TXO that has ever exposed its public key on-chain (roughly 25 % of all bitc= oin) could be stolen by a cryptographically relevant quantum computer.

    • Existing Proposals are Insufficient.

      <= ol style=3D"margin-top: 0px; margin-bottom: 0px;">

    • Any proposal that allows for the quantum theft of =E2=80=9Clost=E2=80= =9D bitcoin is creating a redistribution dilemma. There are 3 types of prop= osals:

      1. Allow anyone to steal vulnerable coins, benefitting t= hose 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.

    • Mini= mizes attack surface

      1. = By disallowing new spends to quantum vu= lnerable script types, we minimize the attack surface with each new UTXO. =

      2. Upgrades to Bitcoin have histo= rically 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.

        4. =

    • 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 corre= sponding to a public key hash or script hash would provide a trustless mea= ns for legacy outputs to be spent in a quantum resistant manner, even after= the sunset.


    =

    Stakeholder

    Incentive to Upgrade

    Miners=

    =E2=80=A2 Larger size PQ signatur= es along with incentive for users to migrate will create more demand for bl= ock 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 a= nd Bitcoin as a whole.

    = Institutional Holders

    =

    =E2=80=A2 Fiduciary duty: failing to a= ct to prevent a quantum attack on Bitcoin would violate the fiduciary duty = to shareholders.

    =E2=80=A2= Demonstrating Bitcoin=E2=80=99s ability to effectively mitigate emerging t= hreats 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 i= s cheap relative to potential losses, potential lawsuits over improper cust= ody and reputational damage.

    Everyday Users<= /p>

    =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 op= en-ended =E2=80=9Csome day=E2=80=9D that invites procrastination.

    Attackers

    =E2= =80=A2 Economic incentive diminishes as sunset nears, stolen coins cannot b= e spent after Q-day.

    Key Ins= ight: As mentioned earlier, the propo= sal turns quantum security into a private incentive to upgrade.

    This is not an o= ffensive attack, rather, it is defensive: our thesis is that the Bitcoin ec= osystem wishes to defend itself and its interests against those who would p= refer to do nothing and allow a malicious actor to destroy both value and t= rust.


    "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 t= he best balance between giving ample ability for account owners to migrate = while maintaining the integrity of the overall ecosystem to avoid catastrop= hic attacks.


    Bac= kward Compatibility

    As a = series of soft forks, older nodes will continue to operate without modifica= tion. Non-upgraded nodes, however, will consider all post-quantum witness p= rograms as anyone-can-spend scripts. They are strongly encouraged to upgrad= e 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 c= an no longer receive from any other wallets and can only send to upgraded w= allets. After Phase B, both senders and receivers will require upgraded wa= llets. 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 e= mail to bitcoindev+...@go= oglegroups.com.

    --
    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/88a7b020-e84f-4052-9716-fb40b23f07ddn%40googlegroups.com.
    ------=_Part_103549_211251283.1752588818047-- ------=_Part_103548_1163467746.1752588818047--