From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 15 Jul 2025 04:36:41 -0700 Received: from mail-yw1-f190.google.com ([209.85.128.190]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1ubdxf-0002hI-Kq for bitcoindev@gnusha.org; Tue, 15 Jul 2025 04:36:41 -0700 Received: by mail-yw1-f190.google.com with SMTP id 00721157ae682-713ff70871dsf56916667b3.1 for ; Tue, 15 Jul 2025 04:36:39 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1752579393; cv=pass; d=google.com; s=arc-20240605; b=Lf89F+q+Qx7gNAG193ATmcXSgy614gckVDkj1FQczlTlTap1yYRtrO2C9/1+T2MtP1 H94QDyHpTfTVwNIHWP3QkcE9WJE8sXj1OQtg0ayvfCxHjnlXhBobY+GKl+Re3RHB/RQx tnFBvtavos8ygU6F48WhIICMDXIsTFOydK5V2l/vqS5NCwyprE/y9tSoWL83DOFXqkCD KtWxwFer/CzJBrDMzW4NuKIMMTZ+DqQZTDJ06HRri1Netch58G7uPF/1ualp0oL40Qnv 46hLExE60So4ATp5zUYHo9Osy6ey1X9akbgmKsTuz78NxKcYzsgM7Gv+bKK1NMpm7oP9 O6Jw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:mime-version:feedback-id :references:in-reply-to:message-id:subject:cc:from:to:date :dkim-signature; bh=bKK9jZ/ETVD2ELS3Ua+WdYRhZ6xh9ybWXIdmcBGCYQg=; fh=8A90iIMRTbHO1SGoujANbLgf0eWyfFuQQgX+avXfyx4=; b=XkJTms3qD3+RilGCsqyEvpT9wszi/gPek1Q9vP0OjjcsQYT0I9h9YG7O7XIE1LgGWd hvZ1MC6/26VRMo26BFF6SZ29lzhTz02atvsOw6kDwOjshwRdGmSIPlyn1wh630KmH5Yl Hm3MwfgZ3qXHo0nC/uqxrjNjP38faSwCXVM0qWJqqHz2sJUPfLlOQ4x8B/YMgq1gFpiA IXMJhWmfxgwjB93Opm7KEeuSos8y1kNLj7KjTXiMTorXlwMdbWA6UycSlthQD1i5pwAT e4dCMrQ+GpQgub9jtzdoShujoFQlF3BtpSce1Q6/rTpDUniVzD40qMWvVN+mlDabJeMv Ffpw==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b="he/3txRx"; spf=pass (google.com: domain of conduition@proton.me designates 109.224.244.18 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1752579393; x=1753184193; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:from:to:cc:subject:date:message-id:reply-to; bh=bKK9jZ/ETVD2ELS3Ua+WdYRhZ6xh9ybWXIdmcBGCYQg=; b=lsniDffx177tlskifRKGVmBlqqdQeLmDSNa3jRt7jv+S9rEuM6ft2SbrRF8XmBw0wT A93cEbhL1sUpR1VPrCG+1OXiOmY/HuX0F5W2ZpGuqQNbU1i1PQAMduGCrdvEov26QFlQ OIgTZZOr9Elk53yIwnLn/aV+MY+NvZW31kVVhuj95sCfqsbcMs4unpjLdtc4tP0jMS6H 3OEmAtev78x/vdS0prZTsjshgdvRF5mjI5ouwnt84ev48q/RntUZ84gRbBr3jK4o/NtT Qykca8gFbiS3NZ4Hn6TdHurwvfTLXbwlglR3oNe4iyMX2eK5LdKTrO74BECv+lgbfTfu cbpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752579393; x=1753184193; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:x-beenthere:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=bKK9jZ/ETVD2ELS3Ua+WdYRhZ6xh9ybWXIdmcBGCYQg=; b=xFX56fcz5Q2SBbNv5fK/MFw2lK89zJqqbF496BW2wYzIQalLV3Q0rDtVt5wckjlqS1 s/yHrBfDTXNtC/xRgD6hFyONpsQTO8dFFhbkAecE5KOpTzM6B7EFSYwNgs85fZgIhIBk a0i9A93TB4Z3QttHRfsfQncl9aU5opO8bUqJHw7kc4piZbAzruTZi4/csBrFCLDOo3RK iP9s6iwer42eyXWYL626R06y2c/5BIpUtx2CFMCY6Y46S4xAwpYH+jWJONUODBwF8/ng KM6+AxJDqv28S4qy3pQ2nBEG1DtpV4brdXHjW4BhO3fCt2sT57RW3P2Hq+0vDxv5CBqJ Vdjg== X-Forwarded-Encrypted: i=2; AJvYcCW98wLG8C+IxltqKMZ+fiVaIrJSOhOwYU4Kb54kyJSu8x/pmesU3HdXwWT2q2QE+1E1WXF21JWiIejU@gnusha.org X-Gm-Message-State: AOJu0Yz9Mw7mrh+GJTvYl8L2cRE+VIDkXqZsNoSFYqlDopOkPnIjJqUj P6y71A06UIxp8tZTZcRPcgU7dYAuaGN7C0ddXXW9AbnDOxbupPTI63cM X-Google-Smtp-Source: AGHT+IFOM1x7GveUK9ivxmBvihNji5n7tRhZwE89z3zXyAMZEn72lpdg5I3vgA1IJWvQOFpqDIAAQQ== X-Received: by 2002:a05:6902:500d:b0:e89:8c82:b7f8 with SMTP id 3f1490d57ef6-e8b85b9de66mr14368426276.28.1752579393247; Tue, 15 Jul 2025 04:36:33 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZf2Ldup/bXeAFdNRVLp1zZ6x9n3kUI+eup+NwC4O3/Ujg== Received: by 2002:a25:c41:0:b0:e7d:82d4:2546 with SMTP id 3f1490d57ef6-e8b84488503ls4140736276.1.-pod-prod-06-us; Tue, 15 Jul 2025 04:36:29 -0700 (PDT) X-Received: by 2002:a05:690c:670e:b0:708:21e9:a20d with SMTP id 00721157ae682-717d5bf2517mr257589507b3.16.1752579388988; Tue, 15 Jul 2025 04:36:28 -0700 (PDT) Received: by 2002:a05:6808:88d9:b0:40d:498:c1f6 with SMTP id 5614622812f47-4185257c0aemsb6e; Mon, 14 Jul 2025 19:32:24 -0700 (PDT) X-Received: by 2002:a05:6a00:4fc3:b0:740:9c57:3907 with SMTP id d2e1a72fcca58-74ee2e57b4fmr23789464b3a.19.1752546742951; Mon, 14 Jul 2025 19:32:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1752546742; cv=none; d=google.com; s=arc-20240605; b=evuoWrigjfWaQb+XyLdxSrYPLHimF4BBqSxt/dhrigVPdfF1cpt9boow5k8tkTfV9I wrPTxH5vYCWmTI6q86DY7nI4c2P/nt5B2C+J7aTQ/jDics16obTBtfWjMCd9vib+7a7U 74oy6OHV2ROM/2PN+cuXgLVsT1zQJWhWR5EyLZ290/vHmFlLeHCQrsp/YvL509kjlA6p eNYuWI+Iab65g1uoXqDmWj6OftdCIwouW7I1ck2bVoTm1Ti7BA486ktDt88g31JKulg1 +NbIPr9Z+Ib0xEbCV8+f/2WcYicc2XYtLu0VFxQL8Htv96OI2aZ5y8YmRjHiAzp++lHG Z4vA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:dkim-signature; bh=SugwJgNhRjnVGDHD+svA+77/kHD+bEMSy/OutvW89SI=; fh=dEDbYMbbYyDNRr1LOwMlw2+lJDEDNk0XskwzeS3uI5o=; b=A1zHx5Ux7SoVNwNRHLblATuFHM6J/ilAdMwXl0lwRzF7LedhoKPVJa+xn9D/ApDODC tNt2QwmS4BFCW9McF1Uw/u1JL/Vdbjil4IIVaZOqDGYgw7RcTCgVPA8oGGqNJ7WqI575 Tw0Gna1wVn0XI+NVCLk+fp85Yqyi6Yf+XWp3bMa80pPjgk4T1bSgEdBhmGec0q74JJx5 bBYQg7+rSoidTUQtCzwijgjnxsfG+2raLl4JNOR0m1iTiUZjzy2Sy1/Xo77lchVZaTHt bEvmFq0zdZRIn52vJKI/+vsROTIag0ysuWwABM7pNL+tsNuyrludsLpEW0phklUGNJzl utZg==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b="he/3txRx"; spf=pass (google.com: domain of conduition@proton.me designates 109.224.244.18 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me Received: from mail-24418.protonmail.ch (mail-24418.protonmail.ch. [109.224.244.18]) by gmr-mx.google.com with ESMTPS id d2e1a72fcca58-74eb9f4d941si510392b3a.4.2025.07.14.19.32.22 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 14 Jul 2025 19:32:22 -0700 (PDT) Received-SPF: pass (google.com: domain of conduition@proton.me designates 109.224.244.18 as permitted sender) client-ip=109.224.244.18; Date: Tue, 15 Jul 2025 02:32:16 +0000 To: Jameson Lopp From: "'conduition' via Bitcoin Development Mailing List" Cc: Bitcoin Development Mailing List Subject: Re: [bitcoindev] A Post Quantum Migration Proposal Message-ID: In-Reply-To: References: Feedback-ID: 72003692:user:proton X-Pm-Message-ID: 55263f32a53057f553eb1c0fd779caf21a76fafb MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------d4ee08e2c468a0112a73c05870ee9f24dce825395dccfe3438814dc66135cc29"; charset=utf-8 X-Original-Sender: conduition@proton.me X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b="he/3txRx"; spf=pass (google.com: domain of conduition@proton.me designates 109.224.244.18 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me X-Original-From: conduition Reply-To: conduition 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: -1.0 (-) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------d4ee08e2c468a0112a73c05870ee9f24dce825395dccfe3438814dc66135cc29 Content-Type: multipart/mixed;boundary=---------------------db104c1b374ca74386808959e2d7a421 -----------------------db104c1b374ca74386808959e2d7a421 Content-Type: multipart/alternative;boundary=---------------------b9650bce764c22afa1b66fe3468a0590 -----------------------b9650bce764c22afa1b66fe3468a0590 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Hi Jameson, I like your proposal, and economically so should anyone who owns Bitcoin. I= don't see any solid incentive-based motivation to let QCs "free up" vulner= able coins, other than maybe as an early-warning indicator. This is impossi= ble to prove, but I personally believe almost all dormant bitcoins that wou= ld 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 peopl= e time to upgrade as possible. The time horizons should be flexible and all= ow us to react to changes, in case practical quantum computers take much mo= re/less time to arrive than we expect today. Commit/reveal protocols described in other mailing list threads are a tempt= ing way to rescue some quantum-vulnerable funds, without the complexity of = zk-STARKs... but these protocols would be difficult to explain to users, an= d they only work for addresses whose pubkeys haven't been exposed yet. This= makes implementation hard. It rules out many existing UTXOs, and all P2TR = UTXOs too. At this point I don't feel commit/reveal is worth the engineerin= g effort and research given those limitations. It's reasonable that you lef= t these out of your proposal. It's true that phase C would require a hard fork if we first deploy phase B= , because phase B explicitly closes the door on spending from pre-quantum a= ddresses. However,=C2=A0I believe zk-STARK proof unlocking could be execute= d as a soft fork if you combine phases B and C together into a single upgra= de. This way, there is never a delta in the consensus rules in which EC spe= nding rules need to be relaxed.=C2=A0 - Before: allow spending P2PKH if given a valid 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 combined approach, we would never see a period of time in which a= verage users with 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 wrote: > Building upon my earlier essay against allowing quantum recovery of bitco= in I wish to formalize a proposal after several months of discussions. >=20 > This proposal does not delve into the multitude of issues regarding post = quantum cryptography and trade-offs of different schemes, but rather is mea= nt to specifically address the issues of incentivizing adoption and migrati= on of funds after consensus is established that it is prudent to do so. >=20 > As such, this proposal requires P2QRH as described in BIP-360 or potentia= l future proposals. >=20 > Abstract > -------- >=20 > This proposal follows the implementation of post-quantum (PQ) output type= (P2QRH) and introduces a pre-announced sunset of legacy ECDSA/Schnorr sign= atures. It turns quantum security into a private incentive: fail to upgrade= and you will certainly lose access to your funds, creating a certainty whe= re none previously existed. >=20 > - Phase A: Disallows sending of any funds to quantum-vulnerable address= es, hastening the adoption of P2QRH address types. > =20 > - Phase B: Renders ECDSA/Schnorr spends invalid, preventing all spendin= g of funds in quantum-vulnerable UTXOs. This is triggered by a well-publici= zed flag-day roughly five years after activation. > =20 > - Phase C (optional): Pending further research and demand, a separate B= IP proposing a fork to allow recovery of legacy UTXOs through ZK proof of p= ossession of BIP-39 seed phrase. > =20 >=20 > Motivation > ---------- >=20 > 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. Never before = has Bitcoin faced an existential threat to its cryptographic primitives. A = successful quantum attack on Bitcoin would result in significant economic d= isruption and damage across the entire ecosystem. Beyond its impact on pric= e, the ability of miners to provide network security may be significantly i= mpacted. >=20 > - Accelerating quantum progress. > =20 >=20 > - NIST ratified three production-grade PQ signature schemes in 2024; ac= ademic road-maps now estimate a cryptographically-relevant quantum computer= as early as 2027-2030. [McKinsey] > =20 >=20 > - Quantum algorithms are rapidly improving > =20 >=20 > - The safety envelope is shrinking by dramatic increases in algorithms = even if the pace of hardware improvements is slower. Algorithms are improvi= ng up to 20X, lowering the theoretical hardware requirements for breaking c= lassical encryption. > =20 >=20 > - Bitcoin=E2=80=99s exposed public keys. > =20 >=20 > - Roughly 25% of all bitcoin have revealed a public key on-chain; those= UTXOs could be stolen with sufficient quantum power. > =20 >=20 > - We may not know the attack is underway. > =20 >=20 > - 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 al= ert chain watchers. Q-Day may be only known much later if the attack withho= lds broadcasting transactions in order to postpone revealing their capabili= ties. > =20 >=20 > - Private keys become public. > =20 >=20 > - Assuming that quantum computers are able to maintain their current tr= ajectories and overcome existing engineering obstacles, there is a near cer= tain chance that all P2PK (and other outputs with exposed pubkeys) private = keys will be found and used to steal the funds. > =20 >=20 > - Impossible to know motivations. > =20 >=20 > - Prior to a quantum attack, it is impossible to know the motivations o= f the attacker. An economically motivated attacker will try to remain undet= ected for as long as possible, while a malicious attacker will attempt to d= estroy as much value as possible. > =20 >=20 > - Upgrade inertia. > =20 >=20 > - Coordinating wallets, exchanges, miners and custodians historically t= akes years. > =20 > - The longer we postpone migration, the harder it becomes to coordinate= wallets, exchanges, miners, and custodians. A clear, time-boxed pathway is= the only credible defense. > =20 > - Coordinating distributed groups is more prone to delay, even if every= one has similar motivations. Historically, Bitcoin has been slow to adopt c= ode changes, often taking multiple years to be approved. > =20 >=20 > Benefits at a Glance > -------------------- >=20 > - Resilience: Bitcoin protocol remains secure for the foreseeable futur= e without waiting for a last-minute emergency. > =20 > - Certainty: Bitcoin users and stakeholders gain certainty that a plan = is both in place and being implemented to effectively deal with the threat = of quantum theft of bitcoin. > =20 > - Clarity: A single, publicized timeline aligns the entire ecosystem (w= allets, exchanges, hardware vendors). > =20 > - Supply Discipline: Abandoned keys that never migrate become unspendab= le, reducing supply, as Satoshi described. > =20 >=20 > Specification > ------------- >=20 > Phase >=20 > What Happens >=20 > Who Must Act >=20 > Time Horizon >=20 > Phase A - Disallow spends to legacy script types >=20 > Permitted sends are from legacy scripts to P2QRH scripts >=20 > Everyone holding or accepting BTC. >=20 > 3 years after BIP-360 implementation >=20 > Phase B =E2=80=93 Disallow spends from quantum vulnerable outputs >=20 > At a preset block-height, nodes reject transactions that rely on ECDSA/Sc= hnorr keys. >=20 > Everyone holding or accepting BTC. >=20 > 2 years after Phase A activation. >=20 > Phase C =E2=80=93 Re-enable spends from quantum vulnerable outputs via ZK= Proof >=20 > Users with frozen quantum vulnerable funds and a HD wallet seed phrase ca= n construct a quantum safe ZK proof to recover funds. >=20 > Users who failed to migrate funds before Phase B. >=20 > TBD pending research, demand, and consensus. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > -------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= -------- >=20 > Rationale > --------- >=20 > - Even if Bitcoin is not a primary initial target of a cryptographicall= y relevant quantum computer, widespread knowledge that such a computer exis= ts and is capable of breaking Bitcoin=E2=80=99s cryptography will damage fa= ith in the network . > =20 > - An attack on Bitcoin may not be economically motivated - an attacker = may be politically or maliciously motivated and may attempt to destroy valu= e and trust in Bitcoin rather than extract value. There is no way to know i= n advance how, when, or why an attack may occur. A defensive position must = be taken well in advance of any attack. > =20 > - Bitcoin=E2=80=99s current signatures (ECDSA/Schnorr) will be a tantal= izing target: any UTXO that has ever exposed its public key on-chain (rough= ly 25 % of all bitcoin) could be stolen by a cryptographically relevant qua= ntum computer. > =20 > - Existing Proposals are Insufficient. > =20 >=20 > 1. 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: > =20 >=20 > 1. Allow anyone to steal vulnerable coins, benefitting those who reach q= uantum capability earliest. > =20 > 2. Allow throttled theft of coins, which leads to RBF battles and ultima= tely miners subsidizing their revenue from lost coins. > =20 > 3. Allow no one to steal vulnerable coins. > =20 >=20 > - Minimizes attack surface > =20 >=20 > 1. By disallowing new spends to quantum vulnerable script types, we mini= mize the attack surface with each new UTXO. > =20 > 2. Upgrades to Bitcoin have historically taken many years; this will has= ten and speed up the adoption of new quantum resistant script types. > =20 > 3. With a clear deadline, industry stakeholders will more readily upgrad= e existing infrastructure to ensure continuity of services. > =20 >=20 > - Minimizes loss of access to funds > =20 >=20 > 1. If there is sufficient demand and research proves possible, submittin= g a ZK proof of knowledge of a BIP-39 seed phrase corresponding to a public= key hash or script hash would provide a trustless means for legacy outputs= to be spent in a quantum resistant manner, even after the sunset. > =20 >=20 >=20 >=20 > Stakeholder >=20 > Incentive to Upgrade >=20 > Miners >=20 > =E2=80=A2 Larger size PQ signatures along with incentive for users to mig= rate will create more demand for block space and thus higher fees collected= by miners. >=20 > =E2=80=A2 Post-Phase B, non-upgraded miners produce invalid blocks. >=20 > =E2=80=A2 A quantum attack on Bitcoin will significantly devalue both the= ir hardware and Bitcoin as a whole. >=20 > Institutional Holders >=20 > =E2=80=A2 Fiduciary duty: failing to act to prevent a quantum attack on B= itcoin would violate the fiduciary duty to shareholders. >=20 > =E2=80=A2 Demonstrating Bitcoin=E2=80=99s ability to effectively mitigate= emerging threats will prove Bitcoin to be an investment grade asset. >=20 > Exchanges & Custodians >=20 > =E2=80=A2 Concentrated risk: a quantum hack could bankrupt them overnight= . >=20 > =E2=80=A2 Early migration is cheap relative to potential losses, potentia= l lawsuits over improper custody and reputational damage. >=20 > Everyday Users >=20 > =E2=80=A2 Self-sovereign peace of mind. >=20 > =E2=80=A2 Sunset date creates a clear deadline and incentive to improve t= heir security rather than an open-ended =E2=80=9Csome day=E2=80=9D that inv= ites procrastination. >=20 > Attackers >=20 > =E2=80=A2 Economic incentive diminishes as sunset nears, stolen coins can= not be spent after Q-day. >=20 > Key Insight: As mentioned earlier, the proposal turns quantum security in= to a private incentive to upgrade. >=20 > This is not an offensive attack, rather, it is defensive: our thesis is t= hat the Bitcoin ecosystem wishes to defend itself and its interests against= those who would prefer to do nothing and allow a malicious actor to destro= y both value and trust. >=20 >=20 >=20 > > "Lost coins only make everyone else's coins worth slightly more. Think = of it as a donation to everyone." - Satoshi Nakamoto >=20 >=20 >=20 > If true, the corollary is: >=20 >=20 >=20 > > "Quantum recovered coins only make everyone else's coins worth less. Th= ink of it as a theft from everyone." >=20 >=20 >=20 > The timelines that we are proposing are meant to find the best balance be= tween giving ample ability for account owners to migrate while maintaining = the integrity of the overall ecosystem to avoid catastrophic attacks. >=20 >=20 >=20 > Backward Compatibility > ---------------------- >=20 > As a series of soft forks, older nodes will continue to operate without m= odification. Non-upgraded nodes, however, will consider all post-quantum wi= tness programs as anyone-can-spend scripts. They are strongly encouraged to= upgrade in order to fully validate the new programs. >=20 >=20 >=20 > Non-upgraded wallets can receive and send bitcoin from non-upgraded and u= pgraded wallets until Phase A. After Phase A, they can no longer receive fr= om any other wallets and can only send to upgraded wallets. After Phase B, = both senders and receivers will require upgraded wallets. Phase C would lik= ely require a loosening of consensus rules (a hard fork) to allow vulnerabl= e 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= email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit https://groups.google.com/d/msgid/bitcoinde= v/CADL_X_fpv-aXBxX%2BeJ_EVTirkAJGyPRUNqOCYdz5um8zu6ma5Q%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/= W2O6Al4bdVzx1EkszgN5dhtSUD0GwRgwYcRSWlQzfsvZE0UN5f6HBGXB2zorkGOpdsbDAS_X6xc= srH6zBIeYbPY8MM_sPfeN9Wblts5Gcog%3D%40proton.me. -----------------------b9650bce764c22afa1b66fe3468a0590 Content-Type: multipart/related;boundary=---------------------321ea01a350efca4ca93a06beffb06b7 -----------------------321ea01a350efca4ca93a06beffb06b7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jameson,=

<= /div>
I like= your proposal, and economically so should anyone who owns Bitcoin. I don't= see any solid incentive-based motivation to let QCs "free up" vulnerable c= oins, other than maybe as an early-warning indicator. This is impossible to= prove, but I personally believe almost all dormant bitcoins that 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 peop= le time to upgrade as possible. The time horizons should be flexible and al= low us to react to changes, in case practical quantum computers take much m= ore/less time to arrive than we expect today.

Commit/reveal protocols described in= other mailing list threads are a tempting way to rescue some quantum-vulne= rable funds, without the complexity of zk-STARKs... but these protocols wou= ld be difficult to explain to users, and they only work for addresses whose= pubkeys haven't been exposed yet. This makes implementation hard. It rules= out many existing UTXOs, and all P2TR UTXOs too. At this point I don't fee= l commit/reveal is worth the engineering effort and research given those li= mitations. It's reasonable that you left these out of your proposal.
<= div style=3D"font-family: Arial, sans-serif; font-size: 14px;">
It's true tha= t phase C would require a hard fork if we first deploy phase B, because pha= se B explicitly closes the door on spending from pre-quantum addresses. How= ever, I believe zk-STARK proof unlocking could be executed as a soft fork = if you combine phases B and C together into a single upgrade. This way, the= re is never a delta in the consensus rules in which EC spending rules need = to be relaxed. 

  • Before= : allow spending P2PKH if given a valid sig/pubkey. 
  • After: allow spend= ing P2PKH if given a valid sig/pubkey AND a valid ZK proof of seed-phrase-b= ased key derivation (e.g. BIP39). 

With this com= bined approach, we would never see a period of time in which average users = with mnemonic-seed wallets are locked out of their funds, and we need no ha= rd forks at all.

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

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

This proposal does not delve int= o the multitude of issues regarding post quantum cryptography and trade-off= s of different schemes, but rather is meant to specifically address the iss= ues of incentivizing adoption and migration of funds after= consensus is established that it is prudent to= do so.

As s= uch, this proposal requires P2QRH as described in BIP-360 or potential futu= re proposals.

Abstract

Thi= s proposal follows the implementation of post-quantum (PQ) output type (P2Q= RH) and introduces a pre-announced sunset of legacy ECDSA/Schnorr signature= s. It turns quantum security into a pr= ivate incentive: fail to upgrade and you will certainly = lose access to your funds, creating a certainty where none previously exist= ed.

  • <= p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt" r= ole=3D"presentation">Phase A: Disallows sending of any funds to quantum-vulnera= ble addresses, hastening the adoption of P2QRH address types.

  • Phase B: Renders ECDSA/Schnorr spends inval= id, preventing all spending of funds in quantum-vulnerable UTXOs. This is t= riggered by a well-publicized flag-day roughly five years after activation.=

  • Phase C (optional): Pending f= urther research and demand, a separate BIP proposing a fork to allow recove= ry of legacy UTXOs through ZK proof of possession of BIP-39 seed phrase. <= /span>

Motivation

=

We seek to secure the value of the UTXO se= t and minimize incent= ives for quantum 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. Ne= ver before has Bitcoin faced an existential threat to its cryptographic pri= mitives. A successful quantum attack on Bitcoin would result in significant= economic disruption and damage across the entire ecosystem. Beyond its imp= act on price, the ability of miners to provide network security may be sign= ificantly impacted.

  • Accelerating quantum progress.

    • NIST ratified three production-gr= ade PQ signature schemes in 2024; academic road-maps now estimate a cryptog= raphically-relevant quantum computer as early as 2027-2030. [McKinsey]

  • Q= uantum algorithms are rapidly improving

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

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

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

  • We may not know the attack is= underway.

      • <= li dir=3D"ltr" style=3D"list-style-type: circle; font-size: 11pt; font-fami= ly: "Courier New", monospace; color: rgb(0, 0, 0); background-col= or: transparent; font-variant-numeric: normal; font-variant-east-asian: nor= mal; font-variant-alternates: normal; vertical-align: baseline; white-space= : pre-wrap;">

      Quantum attackers could compute the private key for known public keys th= en 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 capabilitie= s.

  • Private keys become public.

    • <= p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt" r= ole=3D"presentation">Assuming that = quantum computers are able to maintain their current trajectories and overc= ome existing engineering obstacles, there is a near certain chance that all= P2PK (and other outputs with exposed pubkeys) private keys will be found a= nd used to steal the funds.

  • Impossible to know motivat= ions.

    • Prior to a quantum attack, it is impossible to know the motiva= tions of the attacker. An economically motivated attacker will try to rema= in undetected for as long as possible, while a malicious attacker will atte= mpt to destroy as much value as possible.

  • Upgrade iner= tia.

    • Coordinating wallets, exchanges, miners and custodians historicall= y takes years.

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

    • Coordinating distributed groups is more prone to delay, even if everyone h= as similar motivations. Historically, Bitcoin has been slow to adopt code c= hanges, often taking multiple years to be approved.

    Benefits at a Glance

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

    • Certainty: Bitcoin users and st= akeholders gain certainty that a plan is both in place and being implemente= d to effectively deal with the threat of quantum theft of bitcoin. =

    • Clarity: A single= , publicized timeline aligns the entire ecosystem (wallets, exchanges, hard= ware vendors).

    • Supply Discipline: Abandoned keys that never migrate become unspendabl= e, reducing supply, a= s Satoshi described.

    Specification

    = =

    Phase

    What Happens

    Who Must Act

    Time Horizon

    Disallow spends to legacy script types

    Perm= itted sends are from legacy scripts to P2QRH scripts

    Eve= ryone 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.

    Everyone holding or accepting BT= C.

    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 fund= s and a HD wallet seed phrase can construct a quantum safe ZK proof to reco= ver funds.

    		=

    = Users who failed to migrate funds before Phase B.

    TBD pending = research, demand, and consensus.

    =

    Rationale

    • Even if Bitcoin is not a primary initial target= of a cryptographically relevant quantum computer, widespread knowledge tha= t such a computer exists and is capable of breaking Bitcoin=E2=80=99s crypt= ography 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 signatu= res (ECDSA/Schnorr) will be a tantalizing target: any UTXO that has ever ex= posed its public key on-chain (roughly 25 % of all bitcoin) could be stolen= by a cryptographically relevant quantum computer.

    • Existing Proposals are Insufficient= .

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

        1. A= llow anyone to steal vulnerable coins, benefitting those who reach quantum = capability earliest.

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

        3. Allow no one to steal vulnerab= le coins.

    • Minimizes attack sur= face

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

      2. Upgrades = to Bitcoin have historically taken many years; this will hasten and speed u= p 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 suffic= ient demand and research proves possible, submitting a ZK proof of knowledg= e of a BIP-39 seed phrase corresponding to a public key hash or script has= h would provide a trustless means for legacy outputs to be spent in a quant= um resistant manner, even after the sunset.


    =

    Stakeholder

    Incentive to Upgrade

    Miners

    =E2=80=A2 Larger size PQ signatures along with incentive for u= sers to migrate will create more demand for block space and thus higher fee= s collected by miners.

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

    =E2=80=A2 A qua= ntum attack on Bitcoin will significantly devalue both their hardware and B= itcoin as a whole.

    Institu= tional Holders

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

    =E2=80=A2 Demonstrating Bitcoin=E2=80=99s ability to effec= tively mitigate emerging threats will prove Bitcoin to be an investment gra= de asset.

    Exchanges & C= ustodians

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

    =E2=80=A2 Early migration is cheap relative t= o potential losses, potential lawsuits over improper custody and reputation= al damage.

    Everyday Users

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

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

    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.

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


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

    If true, the corollary is:


    "Quantum recovered coins only mak= e everyone else's coins worth less. Think of it as a theft from everyone."<= /span>

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


    Backward Compatib= ility

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


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

--
You received this message because you are subscribed to the Google Groups "= Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://grou= ps.google.com/d/msgid/bitcoindev/CADL_X_fpv-aXBxX%2BeJ_EVTirkAJGyPRUNqOCYdz= 5um8zu6ma5Q%40mail.gmail.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/bitcoindev/W2O6Al= 4bdVzx1EkszgN5dhtSUD0GwRgwYcRSWlQzfsvZE0UN5f6HBGXB2zorkGOpdsbDAS_X6xcsrH6zB= IeYbPY8MM_sPfeN9Wblts5Gcog%3D%40proton.me.
-----------------------321ea01a350efca4ca93a06beffb06b7-- -----------------------b9650bce764c22afa1b66fe3468a0590-- -----------------------db104c1b374ca74386808959e2d7a421 Content-Type: application/pgp-keys; filename="publickey - conduition@proton.me - 0x474891AD.asc"; name="publickey - conduition@proton.me - 0x474891AD.asc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="publickey - conduition@proton.me - 0x474891AD.asc"; name="publickey - conduition@proton.me - 0x474891AD.asc" LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgp4ak1FWkRub0tSWUpLd1lCQkFI YVJ3OEJBUWRBcnBZYWFjZDgwcXdocmNaQW9VbW9NSHNWS21iZWlPZUEKcFhXbk1ybFdPZkxOSzJO dmJtUjFhWFJwYjI1QWNISnZkRzl1TG0xbElEeGpiMjVrZFdsMGFXOXVRSEJ5CmIzUnZiaTV0WlQ3 Q2pBUVFGZ29BUGdXQ1pEbm9LUVFMQ1FjSUNaQjRLV3p0aFBhenhRTVZDQW9FRmdBQwpBUUlaQVFL YkF3SWVBUlloQkVkSWthMENNdHJMZGcxM2EzZ3BiTzJFOXJQRkFBQTZhQUVBM1RmNHdqSVoKYnox K0diS0h4K09WQytNUXlVdi84RStoWUpjTE5QZnA0NEFBLzNiak5OTXN4WHdJTGZEM0xManNVVWFo CitBV2JyblVjVUFqQ2R1d3hUT01LempnRVpEbm9LUklLS3dZQkJBR1hWUUVGQVFFSFFDSXYxZW5J MU5MbAo3Zm55RzlVWk1wQ3ZsdG5vc0JrTmhQUVZxT3BXL3RKSkF3RUlCOEo0QkJnV0NBQXFCWUpr T2VncENaQjQKS1d6dGhQYXp4UUtiREJZaEJFZElrYTBDTXRyTGRnMTNhM2dwYk8yRTlyUEZBQUFR TFFEL2NCR2kwUDdwCkZTTkl2N1B6OVpkeUNVQjhzTy90dWZkV3NjQkNZK2ZMYTV3QkFNK0hTL3Jp S014RGt0TkhLakRGc2EvUgpEVDFxUGNBYXZCaXc2dDZ4Ti9jRgo9Y3d5eAotLS0tLUVORCBQR1Ag UFVCTElDIEtFWSBCTE9DSy0tLS0tCg== -----------------------db104c1b374ca74386808959e2d7a421-- --------d4ee08e2c468a0112a73c05870ee9f24dce825395dccfe3438814dc66135cc29 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wrsEARYKAG0Fgmh1vaAJkHgpbO2E9rPFRRQAAAAAABwAIHNhbHRAbm90YXRp b25zLm9wZW5wZ3Bqcy5vcmeidEbKdYQR12gN0VyGk565c9tsOoHal/fAvLC6 kk0vQBYhBEdIka0CMtrLdg13a3gpbO2E9rPFAAAhxgD/fZDBtIZIkeLqDJFi NXiYz4jWK1ioo39DtVZimDnFQpkBAP+E2pIFk/jBQabxhGB8k9+u9zyXFWVs sTcptQ0KyAgM =oakC -----END PGP SIGNATURE----- --------d4ee08e2c468a0112a73c05870ee9f24dce825395dccfe3438814dc66135cc29--