From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 13 Jul 2025 16:53:42 -0700 Received: from mail-yb1-f188.google.com ([209.85.219.188]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1ub6Vo-0007lR-J8 for bitcoindev@gnusha.org; Sun, 13 Jul 2025 16:53:42 -0700 Received: by mail-yb1-f188.google.com with SMTP id 3f1490d57ef6-e8b80549b1dsf3640966276.2 for ; Sun, 13 Jul 2025 16:53:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1752450814; x=1753055614; 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=avSCj/14aanooXmmLR88Am+P71Slnj82s983LF35SfE=; b=rLQFNLL+cPaDfmOyEQ4qOeQwJrW5HlJPAOnfdi8Hv05i8tjimQtyzqvyNsIlt/H3QI q/pXVCHsdB9vKgAgyH4oWD3jEQMfoTHuzBo04WzvUyYuxtRVUuIRn3/5You70p2/SXTg eDsY4jHvohMgxn7APWv+E3xYsIoX7h1pFLdBvFjx9nWAHnNF6uyWlY6ndRmrS7h09qWh A79YQe7hO3LdYco2YYR6eGfpWyQzXjP1srd8YGhmogd1H6+tIXz7JvE5qu53N5cx8TVu TJtilmwqlTDbWs9lCNK/nA9AuY9gO7oTIvqVxL7oZZAjoJMHCi9WuAvWQEogr1Q/oKDh JjFg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups-com.20230601.gappssmtp.com; s=20230601; t=1752450814; x=1753055614; 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=avSCj/14aanooXmmLR88Am+P71Slnj82s983LF35SfE=; b=X06EyVzrhd9CmTcUCBPzl7XdnxO+ZjWRqSycljhyL8ufJVsereapno2UXMSRkSGcqb b/5yim0x7qMAHXJJ70zCQ9y+CL0jdYldXojl977ltHhzQeeBcG7wCo/NDgSi+gPPfJIZ u2ZjqUViOMbP21DXppSfQ4Mh8HInBuf/lMKwcrOiRWmyxMPzADTG4uyY2a1b/0J4ElpY PaZQTlJba37m9aCu6DEkShApNy2dIdFTCfp7MCZkkuJgWJFyTviq47QjEGR0RCaQLxen IjtLFvY8ODynAKL5LQak7pAzis0/AWbgDZZSbRI49DUhkzkvqbUs+q7Yx2go6I35d6/7 Y5tA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752450814; x=1753055614; 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=avSCj/14aanooXmmLR88Am+P71Slnj82s983LF35SfE=; b=PP0wK5eJZVbAyysbQ5KlYcthALskVJ53m/Y9Rp8k6gEK9uRybZSEWTx5IXakJH8PSf 6NmLmlfswTkniQ90X4mAQsgyCdzDOgRWJ2gV6av1DWKAZwt3sqyFvQdFAjjYAYh5re1Z QkN0SAJSILq8I/Bzf9mMVqYTHm+A/7TJ2szPeCb2U4Gk7o4BikZ3vbutm7OUFKAqPkyo J2L9X2AEt26jvEy07361zIcuMVmQreizDs+MLu39HysaakBDpr3HYsYeydpiziLzEGMe cFCAPEX9wESPkGmDUGLIfZkVTD0IBdUrmIyGTLBo2c8kIpND9DMkAd4U1ttCHt1SUpSP kI7w== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCVRoeCK5CJ8ozJB14ttydfNKuZeHXyTBR1Dy5tZM1we/Bo8QPN372lB/4OdCVYtNZF0DUxs56e4FaTB@gnusha.org X-Gm-Message-State: AOJu0YwTjguFfPTkAgjKUWCkPxTSWubEfqq9KU1ufQDyo3WJI7JMmWel OBjnxbu3Xf1cYq7+WGmJ9N0/u8XMuorRuqlHSPWZUG8tYzMrlxB+2I2a X-Google-Smtp-Source: AGHT+IFLmJeShVNmQbVImUiqgQEuQhfbBfZMcIO7ulX6E1pMg93/7m2cvJAfXMgVNPxLjcBft5zl4Q== X-Received: by 2002:a05:6902:1503:b0:e7f:67b9:1161 with SMTP id 3f1490d57ef6-e8b85abc64fmr12111276276.1.1752450813909; Sun, 13 Jul 2025 16:53:33 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZcQPHDje3gaMa2SUMNlr0CXA7tHwSh345ztHDRuBDYqaw== Received: by 2002:a25:c1c5:0:b0:e82:307f:5561 with SMTP id 3f1490d57ef6-e8b7795f27bls3816418276.2.-pod-prod-06-us; Sun, 13 Jul 2025 16:53:29 -0700 (PDT) X-Received: by 2002:a05:690c:6f08:b0:70d:f673:141b with SMTP id 00721157ae682-717d5bc4418mr168855827b3.13.1752450809413; Sun, 13 Jul 2025 16:53:29 -0700 (PDT) Received: by 2002:a05:690c:4683:b0:718:5fd:a4e7 with SMTP id 00721157ae682-71805fda71ams7b3; Sun, 13 Jul 2025 16:19:47 -0700 (PDT) X-Received: by 2002:a05:690c:7003:b0:70e:2cfb:1848 with SMTP id 00721157ae682-717d5df8ce7mr176429377b3.31.1752448785769; Sun, 13 Jul 2025 16:19:45 -0700 (PDT) Date: Sun, 13 Jul 2025 16:19:45 -0700 (PDT) From: Tadge Dryja To: Bitcoin Development Mailing List Message-Id: <37ed2e5d-34cd-4391-84b8-5bcc6d42c617n@googlegroups.com> In-Reply-To: References: Subject: [bitcoindev] Re: A Post Quantum Migration Proposal MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_479484_468336420.1752448785416" X-Original-Sender: rx@awsomnet.org 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.7 (/) ------=_Part_479484_468336420.1752448785416 Content-Type: multipart/alternative; boundary="----=_Part_479485_658117032.1752448785417" ------=_Part_479485_658117032.1752448785417 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi =20 While I generally agree that "freeze" beats "steal", and that a lot of lead= =20 time is good, I don't think this plan is viable. To me the biggest problem is that it ties activation of a PQ output type to= =20 *de*activation of EC output types. That would mean that someone who wants= =20 to keep using all the great stuff in libsecp256k1 should try to prevent=20 BIP360 from being activated. Sure, there can be risks from CRQCs. But this proposal would go the other= =20 direction, disabling important functionality and even destroying coins=20 preemptively, in anticipation of something that may never happen. Also, how do you define "quantum-vulnerable UTXO"? Would any P2PKH, or=20 P2WPKH output count? Or only P2PKH / P2WPKH outputs where the public key= =20 is already known? I can understand disabling spends from known-pubkey=20 outputs, but for addresses where the public key has never been revealed,=20 commit/reveal schemes (like the one I posted about & am working on a=20 follow-up post for) should safely let people spend from those outputs=20 indefinitely. With no evidence of a QRQC, I can see how there would be people who'd say= =20 "We might never really know if a CRQC exists, so we need to disable EC=20 spends out of caution" and others who'd say "Don't disable EC spends, since= =20 that's destroying coins", and that could be a persistent disagreement. But= =20 I hope if we did in fact have a proof that a CRQC has broken secp256k1,=20 there would be significant agreement on freezing known-pubkey EC outputs. -Tadge On Saturday, July 12, 2025 at 8:46:09=E2=80=AFPM UTC-4 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/= 37ed2e5d-34cd-4391-84b8-5bcc6d42c617n%40googlegroups.com. ------=_Part_479485_658117032.1752448785417 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi =C2=A0

While I generally agree that "freeze" beats "steal", = and that a lot of lead time is good, I don't think this plan is viable.
To me the biggest problem is that it ties activation of a PQ output type = to *de*activation of EC output types. =C2=A0That would mean that someone wh= o wants to keep using all the great stuff in libsecp256k1 should try to pre= vent BIP360 from being activated.

Sure, there can be risks from = CRQCs. =C2=A0But this proposal would go the other direction, disabling impo= rtant functionality and even destroying coins preemptively, in anticipation= of something that may never happen.

Also, how do you define "qu= antum-vulnerable UTXO"? =C2=A0Would any P2PKH, or P2WPKH output count? =C2= =A0Or only P2PKH / P2WPKH outputs where the public key is already known? = =C2=A0I can understand disabling spends from known-pubkey outputs, but for = addresses where the public key has never been revealed, commit/reveal schem= es (like the one I posted about & am working on a follow-up post for) s= hould safely let people spend from those outputs indefinitely.

W= ith no evidence of a QRQC, I can see how there would be people who'd say "W= e might never really know if a CRQC exists, so we need to disable EC spends= out of caution" and others who'd say "Don't disable EC spends, since that'= s destroying coins", and that could be a persistent disagreement. =C2=A0But= I hope if we did in fact have a proof that a CRQC has broken secp256k1, th= ere would be significant agreement on freezing known-pubkey EC outputs.

-Tadge
On Saturday, July 12, 2025 at 8:46:09=E2=80=AFPM= UTC-4 Jameson Lopp wrote:

Building upon my earlier essay against allowing quantum recovery of bitcoin I wish to formalize a proposal after several months = of discussions.

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

As such, this propos= al requires P2QRH as described in BIP-360 or potential future proposals.

Abstract

This proposal follo= ws the implementation of post-quantum (PQ) output type (P2QRH) and introduc= es a pre-announced sunset of legacy ECDSA/Schnorr signatures. It turns quan= tum security into a private incentive<= /span>: fail to upgrade and you will certainly lose access to y= our funds, creating a certainty where none previously existed.=C2=A0=

Motivation

We seek to secure the value of the UTXO set and minimize incentives for q= uantum attacks. This proposal is radically 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 b= efore has Bitcoin faced an existential threat to its cryptographic primitiv= es. A successful quantum attack on Bitcoin would result in significant econ= omic disruption and damage across the entire ecosystem. Beyond its impact o= n price, the ability of miners to provide network security may be significa= ntly impacted.=C2=A0=C2=A0

  • Accelerating quan= tum progress.=C2=A0

    • =
  • =

    Quantum al= gorithms are rapidly improving

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

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

    • Roughly 25% of all bitcoin have revealed a public key on-chain; thos= e 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 publ= ic 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 c= apabilities.

  • Private keys become public.=C2=A0

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

    • Impossible to know motivatio= ns.=C2=A0

        • <= p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt" r= ole=3D"presentation">Prior to a qua= ntum attack, it is impossible to know the motivations of the attacker.=C2= =A0 An economically motivated attacker will try to remain undetected for as= long as possible, while a malicious attacker will attempt to destroy as mu= ch value as possible.=C2=A0=C2=A0

    • Upgrade inertia.=C2= =A0

      • Coordinating wallets, exchanges, miners and custo= dians historically takes years.

      • <= span style=3D"font-size:11pt;background-color:transparent;font-variant-nume= ric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;ve= rtical-align:baseline">The longer we postpone migration, the harder it beco= mes to coordinate wallets, exchanges, miners, and custodians. A clear, time= -boxed pathway is the only credible defense.

      • Coordinating distributed groups is mor= e prone to delay, even if everyone has similar motivations. Historically, B= itcoin has been slow to adopt code changes, often taking multiple years to = be approved.

    Bene= fits at a Glance

      =

    • Resilience: Bitcoin protocol remains secure for the f= oreseeable future without waiting for a last-minute emergency.

    • Certainty: Bitcoin users and stakeholders gain cert= ainty that a plan is both in place and being implemented to effectively dea= l with the threat of quantum theft of bitcoin.=C2=A0=C2=A0

      • <= li dir=3D"ltr" style=3D"list-style-type:disc;font-size:11pt;font-family:Ari= al,sans-serif;color:rgb(0,0,0);background-color:transparent;font-variant-nu= meric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;= vertical-align:baseline;white-space:pre">

      Clarity: A single, publicized timeline aligns the entir= e ecosystem (wallets, exchanges, hardware vendors).

    • Supply Discipline: Abandoned keys that never migrate become = unspendable, reducing supply, as Satoshi describe= d.=C2=A0=C2=A0

    Specification

    <= col width=3D"224"><= tr style=3D"height:0pt">

    Phase

    What Happens

    Who Must Act

    Time Horizon

    Phase A - Disallow spends to legacy script types=

    Permi= tted sends are from legacy scripts to P2QRH scripts

    Ever= yone holding or accepting BTC.

    3 years after BIP-360 i= mplementation

    Phase B =E2=80=93= Disallow spends from quantum vulnerable outputs<= /p>

    At a p= reset block-height, nodes reject transactions that rely on ECDSA/Schnorr ke= ys.=C2=A0

    		<= p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><= span style=3D"font-size:10pt;font-family:"Courier New",monospace;= color:rgb(0,0,0);background-color:transparent;font-style:italic;font-varian= t-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:nor= mal;vertical-align:baseline">Everyone holding or accepti= ng BTC.

    2 years after Phase A activation.

    Phase C =E2=80=93 Re-enable spends from quan= tum vulnerable outputs via ZK Proof

    Users with frozen quantum vulnerable f= unds and a HD wallet seed phrase can construct a quantum safe ZK proof to r= ecover funds.

    Users who failed to migrate funds before Phase B.

    =

    TBD pend= ing research, demand, and consensus.

    Rationale

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

    • An attack on Bitcoin may not be economically motivated - an a= ttacker may be politically or maliciously motivated and may attempt to dest= roy 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 defe= nsive position must be taken well in advance of any attack.=C2=A0=C2=A0

    • 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.= =C2= =A0=C2=A0

        • Any proposal that allo= ws for the quantum theft of =E2=80=9Clost=E2=80=9D bitcoin is creating a re= distribution dilemma. There are 3 types of proposals:

        1. Allow anyone to steal vulnerable coins, benefitting t= hose who reach quantum capability earliest.

        2. Allow throttled theft of coins, w= hich leads to RBF battles and ultimately miners subsidizing their revenue f= rom lost coins.

        3. Allow no one to steal vulnerable coins.

      1. Minimiz= es attack surface

        1. By disallowing= new spends to quantum vulnerable script types, we minimize the attack surf= ace with each new UTXO.=C2=A0=C2=A0

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

        3. With a clear deadline, industry stakeholders will mor= e readily upgrade existing infrastructure to ensure continuity of services.= =C2=A0=C2=A0

      2. <= span style=3D"font-size:11pt;background-color:transparent;font-variant-nume= ric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;ve= rtical-align:baseline">Minimizes loss of access to funds=C2=A0

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


    Stakeholder

    Incent= ive to Upgrade

    Miners<= /span>

    = =E2=80=A2 Larger size PQ signatures along with incentive for users to migra= te will create more demand for block space and thus higher fees collected b= y miners.

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

    =E2=80=A2 A quantum attack o= n Bitcoin will significantly devalue both their hardware and Bitcoin as a w= hole.=C2=A0

    Institutional H= olders

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

    =E2=80=A2 Demonstrating Bitcoin=E2=80=99s ability to ef= fectively mitigate emerging threats will prove Bitcoin to be an investment = grade asset.

    Exchanges &= ; Custodians

    		<= 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-variant-numeric:normal;f= ont-variant-east-asian:normal;font-variant-alternates:normal;vertical-align= :baseline">=E2=80=A2 Concentrated risk: a quantum hack could bankrupt them = overnight.

    =E2=80=A2 Early migration is cheap relativ= e to potential losses, potential lawsuits over improper custody and reputat= ional damage.

    Everyday User= s

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

    =E2=80=A2 Su= nset 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 procrasti= nation.

    Attackers

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

    Key Insight: As mentio= ned earlier, the proposal turns quantum 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 Bitcoin ecosystem wishes to defend itsel= f and its interests against those who would prefer to do nothing and allow = a malicious actor to destroy both value and trust.=C2=A0=C2=A0


    =

    "Lost coins only make eve= ryone else's coins worth slightly more. Think of it as a donation to ev= eryone." - Satoshi Nakamoto

    If true= , the corollary is:


    The timelines that we are proposing are meant to find the best bal= ance between giving ample ability for account owners to migrate while maint= aining the integrity of the overall ecosystem to avoid catastrophic attacks= .=C2=A0=C2=A0


    Backward Compatibility

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

    =

    Non-upgraded wallets can receive and send bitcoin from non-= upgraded and upgraded wallets until Phase A. After Phase A, they can no lon= ger receive from any other wallets and can only send to upgraded wallets.= =C2=A0 After Phase B, both senders and receivers will require upgraded wall= ets.=C2=A0Phase C would likely require a loosening of consensus rules (a ha= rd 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/37ed2e5d-34cd-4391-84b8-5bcc6d42c617n%40googlegroups.com.
------=_Part_479485_658117032.1752448785417-- ------=_Part_479484_468336420.1752448785416--