From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 12 Feb 2026 10:41:55 -0800 Received: from mail-oa1-f55.google.com ([209.85.160.55]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vqbdS-0001eN-6L for bitcoindev@gnusha.org; Thu, 12 Feb 2026 10:41:55 -0800 Received: by mail-oa1-f55.google.com with SMTP id 586e51a60fabf-4081db82088sf1188745fac.1 for ; Thu, 12 Feb 2026 10:41:53 -0800 (PST) ARC-Seal: i=3; a=rsa-sha256; t=1770921708; cv=pass; d=google.com; s=arc-20240605; b=WLe3Y5hka43+agVIDcC3WgvD/sACxEdyB2HwJvKLpEGhKofkg5SvNx/uuZTUm+ztzD V8HsNB0EQEJuBCwkHYAkPSGZuNTY2ZjKoMFVBGSv/mbzZ/yoCa2x43whNelp/g7If2i5 sPhZx3Ss0MObbVa9Q7LMj+Erpr8pmgB17YyWbwixoQK6tzsl5S45Uz3lQkoa0IwXdT6y gwuPjXKDpfI3bpBHOwrdL6y89H7yuU6d+gAQMCUuWb0c1WvapeD5eqsev14QO/h64R6e OZJaogLrICysyYXeuQ7CjJOav2oDM60EM2QLHq6bNqOAf8sm+nB/6s7ofVcFouQrYZfr 3yAA== ARC-Message-Signature: i=3; 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:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=7NEaQtYj9gIdQrrWS4CCmHhRL8tT1GHNXjbyfIZkolE=; fh=QQ4osULdD+5YjKCLz+/Q+/C6qrVVJ6qKoIT2AEYAyRE=; b=OhUH844HkBYFbw3orAy88Le2vgS/6T5U/xTvof+CVPiEH2I/pyW8tEHMKN8MrWdrfo VzITw+iiyGXbBQcU6kjZYP8YiXMZXTK+vQfYrqsa2h3/JAxg+EFbrLgf2csUtG5iM2Iz NLnaMh6eXhaCLFm8l74ISvhC0k/GNSgZqmT8wIP/RJp7/WJtOMPWX0R2VKGwNmPVEfYC FU27ZCdY5yOUNTffU2NaOX9jWEvUheWSFEepMLuJl11OTYAwtion+YwYigxN0siD/Gox 0PPWOpcxHICBYWyeYTZPqSFgP3rNRZ3UWPONRrQWOBYxiTieAD1LAyx+0qu6QIQ3XyAu MIIw==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=EG7Gi39p; arc=pass (i=1); spf=pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::62a as permitted sender) smtp.mailfrom=eth3rs@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1770921708; x=1771526508; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=7NEaQtYj9gIdQrrWS4CCmHhRL8tT1GHNXjbyfIZkolE=; b=Efg6d6lgiQLXMNy6D7Cn1e4/BxvG76xdfvB5u6J+p+eJL1/hp8TpOMNIgM00PoCA18 ceTzG7sDENrNazy5wleCXuM3XHD+NLqoUcZen/wUCTkyMiywoQdUxK6SAEyT10pF3xt8 9sENl8ddO84DN4+XRU3SeBM1INvmv24jsjGuu3auipQS0ydo+PTcs5MODquP136C9kaK n0++4EZj/0UHZiNdpCvuHgmo0QIETcZBOFSDpLK8wUzRdxa9j7RAHqYQYPUcTBobYzyj GREBcWRQkGFY5PaNUw+TWNGOFI5XJAoMUklPxI1M2snHqiI5ZNJ8OAvNZEgja9/1Ci3v Y+tA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770921708; x=1771526508; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to; bh=7NEaQtYj9gIdQrrWS4CCmHhRL8tT1GHNXjbyfIZkolE=; b=dvliTYcsQD0+CWyFCwiEFq1c02uhoWaPga0sRnZWnjLfNAaDAAhcUoy/XXo2erGPpj knquKJ4jQh1WAh8tCqlONjdGnIiSYd6CTtAvw8CwKQtEb8eSCGwiojh89PlmziEfn0EV bjReGjkFCChTODICRKM5+CtTdhIeqevdO9LcpyaR7bB+21gsywIs5JxKLA9mhBeiDDLH fJTzYg9cTyuU0oedgdejS2Utb9mqSqoyIom/rYuHmvs+ZRjHrhDaAMjeW/3exG99DmaB FTQ1Ctpw+r8yWr20/YL8OZRyx9IgYfKNoAqSr4Up/knPj1yQtrRorfGjsVPW+8H9k+Ck IF5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770921708; x=1771526508; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-gm-gg:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=7NEaQtYj9gIdQrrWS4CCmHhRL8tT1GHNXjbyfIZkolE=; b=sUIlxm4JgLMqpnl/q8/2r7f615H295tt1Bgc6GbVSYwmhUhKOr7hXjc5RURHfjhEB6 nhS0+i9mZfLK/IHheQHUcJkb0NEDKqUafAyMPjs9JPpoLuLFfVxjBBIS8D2C6hOuw5Pj IS/Bbkjz0YVGTzuUC+SAVIog1ds1ljFhr5UuZSyFFk9WR12Uvjq0SfYgrjAg9eaex5cc g3AbUqXXCYZv5qo2kxiRvea4XiKYxfniuoxn614ue0Mdk4gfRMjlxyxETGRcZ5lpZ2SO 7HiT5KyJ9GURwAaYKgj1DciCpMB6lJXwQhXDMSw06+fOzqjxSHgn0HdL/X1LRN98U+Pr Epuw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AJvYcCUFAswJpzSGhGbW5b/Dxw73piCVt8W33IS1UqQvCvj9JB8ItJyBvYSF7o/qhXTjWefHhyvi7yWHqR5e@gnusha.org X-Gm-Message-State: AOJu0YzBilLhJYpMrdolBJ3jjftTtFSqW+kvrjJHj4MlBjNLoXwO6Gi7 aLHOWmvwbBYKD5CulqfGqUQBLQyaZYLc6++BiwgBwTku/2ruB4TC4/Oa X-Received: by 2002:a05:6871:1c6:b0:403:f8ca:3fb2 with SMTP id 586e51a60fabf-40ec6f54f66mr1791484fac.17.1770921708086; Thu, 12 Feb 2026 10:41:48 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+Ew/tzv1FG/mf5HFe/TegGEWkV71rpTLP9A1CkC5d30Ng==" Received: by 2002:a05:6871:3301:b0:409:6328:a767 with SMTP id 586e51a60fabf-40eca620de7ls932935fac.1.-pod-prod-04-us; Thu, 12 Feb 2026 10:41:44 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCUWyM405J29SsTqsOnS3zzWmKegExFllRel3e7MYifwQbZBFRyx0qZ9JzDOFosOG7kTL1KsKGrunTuU@googlegroups.com X-Received: by 2002:a05:6808:c14a:b0:45f:13ad:83c1 with SMTP id 5614622812f47-4637b8cad03mr1966444b6e.51.1770921703938; Thu, 12 Feb 2026 10:41:43 -0800 (PST) Received: by 2002:a05:6808:a61c:10b0:455:f49f:e029 with SMTP id 5614622812f47-46396926dddmsb6e; Thu, 12 Feb 2026 10:09:26 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCXX6yzUKZ3nqrRAyyM3BIH9WF4Xb/4BeojXRcyQXctQoy9O6WM2DSxIfZXecRNc5a7ghTYar1A9sn59@googlegroups.com X-Received: by 2002:a05:6a21:7a8d:b0:38d:fa67:e87f with SMTP id adf61e73a8af0-394484768ecmr4073052637.12.1770919765294; Thu, 12 Feb 2026 10:09:25 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1770919765; cv=pass; d=google.com; s=arc-20240605; b=NS2WkFfnxCVjK2WDxxbfstpaAPvb6NmnRV6a5WrjwUFMyiaGfMRN5P+044t+M+PyCA l70Q3CRirMIxKTrdlVY1YbXTLFGYrD24caHEQj0rfgo+U4vaU1YR5lKZIK6qbdkEiICK 9tw33EGY/WDRK0TQX6jPddjmvgb/qZniP8TiVn2FRTFrepPKwZwCGaGLxOMdaFltgqkB yPGuRax0oOnUSwqfapr0RVOp0x43+UCnxWNHjQ+GuwbY5Z91sIIFc1M2PPsU9qlAsuQx WSQW1YMbH31hWu2FHta3Afd/AaPr0tpLZZXeTkXmpqE/dXxt2s3jAkGUBi3RsMDg3vgc aVSQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=l5aM0JBDH0yp8teRZc4XJMbrsjo1TeHRDziXvFpEobw=; fh=y17uXD66YdDJAaWGS6r9ErmjsTcRiUpuomevHcVUqxw=; b=WShTGEbn/7PWLO7DnXLdHONHx1yBfwYzVlDOaEaROKYUDq5a5eg9HWFoY38YMQrjpi NCZU7N3FyJXIHM2vdmGEYQRa3l9C2YDguco2QoP72P4fgOki1hjisTEIvQTn/U4GY0di +IqylOvGZmv9an5R4CnIWVwb8GoRw6CWptlYGecLrk4KBrTp9bq2WW1o6WDQBunWLEeb H5yqJtL+RPFrL+4ZBLD+zURyXTHTt6KVikzvGb8d/U12UmZzXPbgp+wTNXhJl7WN6rT+ rax9cmIrIWo3/4mosxM7pSbRJfvBh0Ivg+PtFQHRIZbfP/YYSuoYLT9EPYBr0P41eXDM 6Ozg==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=EG7Gi39p; arc=pass (i=1); spf=pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::62a as permitted sender) smtp.mailfrom=eth3rs@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com. [2607:f8b0:4864:20::62a]) by gmr-mx.google.com with ESMTPS id 41be03b00d2f7-c6e39ed9c89si37754a12.4.2026.02.12.10.09.25 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 12 Feb 2026 10:09:25 -0800 (PST) Received-SPF: pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::62a as permitted sender) client-ip=2607:f8b0:4864:20::62a; Received: by mail-pl1-x62a.google.com with SMTP id d9443c01a7336-2ab39b111b9so476085ad.1 for ; Thu, 12 Feb 2026 10:09:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1770919765; cv=none; d=google.com; s=arc-20240605; b=CG/l4p65y8XwqN6Wf+Z8RhWPVS6a6T1csObBaYjB/iw17aDbwGHelLQxQsmO9/nkte daVDVecXUTr8P6BoIvGXjVkPGtm2UBb5LSsNUPkxEVG9C4ZNWsYLvwyqXhXwDqCgW1Pe d++JsRof5kSa8j4zM+i51SkX3OYOksWv4nIF3DG65GhDHtMbgjkoPnauzbNSimY9f1ND jF1v8+FULU7MUf1wZkK5f9oIcg4SHmbYWPQLcZSDwCZHL8pHHRQfV0kWI/OF+QHWW/kd zQYbY8kuj9rbh+0Uh6CL9uormyKVDNtetlJUMrqUb6smd/pb5kDI8ps7ESCW24YY7tTM yvZg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=l5aM0JBDH0yp8teRZc4XJMbrsjo1TeHRDziXvFpEobw=; fh=y17uXD66YdDJAaWGS6r9ErmjsTcRiUpuomevHcVUqxw=; b=b7QDWBqzsB3IVcU8agLSwrfeKUiZMsWGX8lBqKtHigXZBvs8DKpBIu5JXjf1xQI07N 8Kt38Er1bfrSvtc4PjjMSlEAeC8TicWzZiCYqAhAu9E022IkQ9+s1gxFaRv5ZrvzAyjX 701aAhKU4FzqMoU1/pkPnLzaL9Sz+1t4HIKdRp3FEgFfVyieZuudvuLAZY1ja0hA01X9 Jyjbl0B3Wk6J9lKot0zRgrcwCcAG3NFUZLUrcmAvRA+gQ/n9whC8VttisI1pFlqRg2+M 6970M0VV3tvPXt76HfhymO9guVrZfeCVlzE4E7KisDUulaFOF33VydCxrgwsIV5YKYY1 IqvA==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Forwarded-Encrypted: i=1; AJvYcCXBbwXoDF0oWeSvNsXteM3xJsfU6f2KDZw+ODGlRdAVR7i9rSg99Kz3MGM+AVqDOMilVNvnzAYTs5hm@googlegroups.com X-Gm-Gg: AZuq6aJ23+BQs7mWOzkYQ4el5rSKcGBAGn/fzXc9bPMFglgxChGDv7h/gbveVJYMNWa SpqNdzCLJL5ulshIzoq22fsq4xyTsXwZv/hrPGWhJ7MaOltoiWFu3a4+sxIOUh+9eNpQpHX5Ntb 0pmhBHnLlJ6+AhVZ6/GqLYQotrJ61xrbMyUxQDhyKrBUnHLfRz0KzB4blEPBO8saFhlzxUeTEzH 2oX6ai3/3ODE1VsJhYllCHPFueqgXYNbl8qwac9d3uYrfpmMX1/ysm01By+CbudSw/+AmxLSr2b EdQBn/W/6v7MYxsc0EzPBNC3JRxiCrTu3l65r8PaZhzRXCdQ9jmCJXOnOfOzsqGQjzfOnWQzGMs BnM4ROcYJIsJlcYw1zJi9JIDjI55924z2XVBOj+RvJh3dSFyM8i/oMsfnWOqF+1pj61sDsVbSF7 mEk7IDoQ81obUGIxfXO3eP3PQqWA== X-Received: by 2002:a17:902:d50b:b0:2a7:b039:4b52 with SMTP id d9443c01a7336-2ab39886eb0mr36751425ad.1.1770919764706; Thu, 12 Feb 2026 10:09:24 -0800 (PST) MIME-Version: 1.0 References: <22073a56-1cbf-4ba9-a2ea-46c621d4619c@mattcorallo.com> <1f0ebca9-2d23-44f9-8e6d-aaea99a832e3@mattcorallo.com> In-Reply-To: <1f0ebca9-2d23-44f9-8e6d-aaea99a832e3@mattcorallo.com> From: Ethan Heilman Date: Thu, 12 Feb 2026 13:08:48 -0500 X-Gm-Features: AZwV_Qhxh15ZA520h1x7l26_ANtnZ7u-0qa0lEtA98LqQHB18xqZqOmsyMIII24 Message-ID: Subject: Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms To: Matt Corallo Cc: Jonas Nick , bitcoindev@googlegroups.com Content-Type: multipart/alternative; boundary="000000000000804a65064aa463a9" X-Original-Sender: eth3rs@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=EG7Gi39p; arc=pass (i=1); spf=pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::62a as permitted sender) smtp.mailfrom=eth3rs@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.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 (/) --000000000000804a65064aa463a9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Yep, we absolutely agree! I just don't see a reason to do P2MR over just utilizing P2TR (or maybe P2TRv2). Here is my P2TRv2/ P2TRD vs P2MR analysis. Terms: - P2TRv2-disable-soft-fork - refers to the soft-fork that disables key spend paths for P2TRv2 outputs, but does not disable key spend paths for other P2TR outputs. - Q-day-long - The day at which long exposure attacks start happening. Set of outcomes for P2TRv2: Future-A: Q-day-long happens and P2TRv2-disable-soft-fork is NOT activated. Funds are stolen from P2TRv2 outputs, trust in Bitcoin declines. Future-B: Q-day-long happens and P2TRv2-disable-soft-fork is activated. P2TRv2 outputs are protected from quantum attacks. Set of outcomes for P2MR: Future-C: Funds in P2MR are safe even if Q-day-long happens unexpectedly. The risk of Future-A will be priced into the value of Bitcoin. We can reduce Future-A risk by activating P2TRv2-disable-soft-fork as early as possible. Activating P2TRv2-disable-soft-fork as early as possible is equivalent to activating P2MR. Thus, might as well activate P2MR instead. Do we want to tell holders: - Move to P2TRv2 and then trust us to activate the P2TRv2-disable-soft-fork in time - Or move to P2MR, you'll be safe. > Still, I think my point stands - in the face of many bitcoiners writing off the quantum threat, wallets aren't going to have a lot of incentive to adopt technologies that make things marginally more expensive. Maybe in 2027, but what about 2028, 2029? If we see steady progress toward a CRQC the drumbeat will become louder and louder and wallets will want to tell their users they are quantum-safe and secure against classical attacks on ECC. The first parties to move over will likely be big holders willing to pay a trivial increase in fees for security against existential tail risks. > I'm confused by this comment - a soft fork that disables insecure spend paths to avoid them being stolen is likely going to have a very easy time, not "fight an uphill battle"? soft-fork-1: Disables insecure key spend paths in P2TR. I don't have an opinion on the ethics of this, but the incentives are aligned to make this happen (reduces supply). soft-fork-2: ZKP proof of seed phase to allow people to safely spend from a disabled key spend path. The incentives are aligned to oppose this soft-fork (increases supply). The incentives support soft-fork-1 happening, but soft-fork-2 not happening. I don't claim to predict a future here, but the incentive issue here worries me. Other questions: Soft-fork-1 must be designed so that soft-fork-2 is not a hard fork, that seems doable, has anyone written up a plan for it? How big is this proposed PQ ZKP proof of seed phase? I've been assuming ~100kb per spend since we have to use PQ ZKPs. On Thu, Feb 12, 2026 at 9:56=E2=80=AFAM Matt Corallo wrote: > > > On 2/11/26 5:57 PM, Ethan Heilman wrote: > > > For what its worth I do not see a scenario where a decision > ultimately made by the market will > > pick the fork side with materially, say 5-10x higher, supply, over the > side with lower supply... > > > > Completely agree, the incentives favor lower supply. I wouldn't want to > count on it happening and > > even if it does happen the freeze fork might not freeze P2TR. According > to the 2025 chaincode report > > [0] P2TR represents only 0.75% of total supply. > > I believe we're talking past each other, then. This was a side note - as > Jonas mentioned it seems > reasonable that a P2TR-based QC signature validation opcode could come > with an on-chain signaling > bit (i.e. a "Taproot V2" that is functionally identical but indicates the > presence of a QC signature > script path available). > > > > ~all wallets today use seedphrases, which could still be spent with = a > ZK proof-of-seedphrase :). > > > > I'm all for putting ZKPs in consensus, but it seems unlikely to me that > it will happen. > > We just agreed that its highly likely that insecure spend paths are > disabled. I do not remotely see > how such an action could occur if the result is that a large number of > coins are seized. The only > viable approach way for that is to allow seedphrase-based wallets to > retain access. > > > It is better > > to make Bitcoin safe than promise safety that requires a future hardfor= k. > > There is no hardfork required here. > > > This is especially true > > since as you point out lower supply is incentivized, so a soft fork tha= t > freezes coins would be > > fighting an uphill battle. > > I'm confused by this comment - a soft fork that disables insecure spend > paths to avoid them being > stolen is likely going to have a very easy time, not "fight an uphill > battle"? > > > > Hell, *any* PQ soft fork is going to see limited adoption in > "consumer wallets" until its > > urgent, hence why I think the community will be basically forced to > disable insecure spend paths and > > only > > allow spends via ZK proof-of-seedphrase. But at least something that > doesn't also 10x > > transaction costs might reasonably be adopted by default by wallets tha= t > don't use seedphrases like > > Bitcoin Core. > > > > I disagree. If we get P2MR and SLH_DSA/SHRINCS the wallets can use > quantum-safe outputs (Schnorr OR > > PQ) with Schnorr as the default spend. The wallets can market themselve= s > as quantum safe. > > This flies in the face of the last 15 years of experience with Bitcoin > wallets. Yea, it sounds > great, but we've got 15 years of experience showing that wallets only > adapt when they go out of > business/stop being maintained and get replaced with new wallets (which > often ship with the latest > technology). Worse, many bitcoiners (maybe rightfully, maybe not) entirel= y > write off the quantum > threat - all the more reason they will simply not adopt any changes. > > > The cost > > in transaction fees to a user is small, a 1 input P2MR transaction woul= d > only be 37 bytes larger > > when compared with a 1 input P2TR transaction. Those 37 bytes are in th= e > witness, so the real cost > > is ~10 vbytes. > > Apologies, I had understood the P2MR proposal to only feature PQC-based > schemes, rather than also > offering schnorr as an option, leading me to incorrectly conclude it woul= d > be drastically more > expensive, rather than marginally so. > > Still, I think my point stands - in the face of many bitcoiners writing > off the quantum threat, > wallets aren't going to have a lot of incentive to adopt technologies tha= t > make things marginally > more expensive. > > Worse, there's no real advantage here over just doing in the taproot key > path - because of address > reuse a wallet relying on P2MR + schnorr anyway will ~always have its > public key revealed so we > might as well continue relying on P2TR to save the 37 witness bytes and > get the same result (that > wallets can do something cheap with "just" a key derivation change and > explicitly opt in to a future > soft fork which disables the then-insecure spend paths). > > > Yes, if Q-day happens, time passes and then quantum computers become > powerful enough to perform > > short-exposure attacks, anyone needing to move their coins to an output > have to pay fees for an > > additional 8,000 bytes (SLH_DSA) or 324 bytes (SHRINCs). This is still > better than a PQ ZKP proof of > > the seed which would be between 20,000 to 120,000 bytes and more likely > to have a security flaw than > > SLH_DSA. > > Yep, I'm not proposing at all that we do nothing because a ZKP of > seedphrase is an option, rather we > should add support for SHRINCS and encourage wallet adoption. But at the > same time we should > understand that we're incredibly unlikely to see the kind of adoption in > time to avoid the need to > do something like a ZKP of seedphrase when the time comes. > > This is also probably the least interesting point of contention, FWIW - > this is a decision for a > future bitcoin community, not a decision for us to make today. > > > If efficient quantum signatures or compression techniques are developed= , > we can and should adopt > > them. If they are efficient enough, they can become the default. This > proposal is designed to keep > > funds safe in the intermediate period while better techniques are > developed to cover the tail risk > > where Q-day happens before the technology we need to completely ready. > > Yep, we absolutely agree! I just don't see a reason to do P2MR over just > utilizing P2TR (or maybe > P2TRv2). > > > > No it doesn't - it requires a soft fork when the risk is imminent, > but it happening somewhat > > before that time is okay too. > > > > We might wait too long and misjudge the risk and Q-day happens before > the soft fork activates? What > > happens if freeze fork is activated but then 3 years pass and it looks > like a CRQC isn't going to > > happen after all? Now people who had their coins frozen are pushing to > undo the soft fork. > > > This approach carries too much risk from uncertainty and it was "the > plan" it signles that Bitcoin > > leaving things up to chance that don't have to be left to chance. > > > > Enabling people to opt in as early as possible enables the prudent to > protect themselves for very > > little effort and cost. Those people know their coins are safe and can > still use their coin as they > > did before. > > We agree. I believe your response is based on a misunderstanding of my > argument, hopefully clarified > above. > > > > I mean people can create invalid addresses today in plenty of ways. > How is this unique? > > > > P2TRD would be an address, which looks exactly like a 100% valid addres= s > and which can be spend from > > like a valid address and hwoever at some future time, it may or may not= , > become frozen. > > Sure, but this is still no different than any other P2TR script-path > structure - you have to test > things you use, even if you use them rarely, which is the entire point of > the P2TR design :). > > Matt > --=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/= CAEM%3Dy%2BU673Q1U09Z_xrumiBjU9q9xKGnMOE3OC41Qt651g2ROw%40mail.gmail.com. --000000000000804a65064aa463a9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0 Yep, we absolutely agree! I just don't see = a reason to do P2MR over just utilizing P2TR (or maybe P2TRv2).

Here= is my P2TRv2/ P2TRD vs P2MR analysis.

Terms:
- P2TRv2-disable-soft-fork - refer= s to the soft-fork that disables key spend paths for P2TRv2 outputs, but do= es not disable key spend paths for other P2TR outputs.
- Q-day-long - T= he day at which long exposure attacks start happening.

Set of outcom= es for P2TRv2:
Future-A: Q-day-long happens and P2TRv2-disable-soft-fork= is NOT activated.=C2=A0Funds are stolen from P2TRv2 outputs, trust in Bitc= oin declines.
Future-B:=20 Q-day-long happens and P2TRv2-disable-soft-fork is activated. P2TRv2 output= s are protected from quantum attacks.

Set of outcomes for P2MR:
F= uture-C: Funds in P2MR are safe even if Q-day-long happens unexpectedly.
The risk of Future-A will be priced into the value of Bitcoin. We can = reduce Future-A risk by activating=C2=A0P2TRv2-disable-soft-fork as early a= s possible.=C2=A0Activating P2TRv2-disable-soft-fork as early as possible i= s equivalent to activating P2MR. Thus, might as well activate P2MR instead.=

Do we want to tell holders:
- Move to P2TRv2 and then tru= st us to activate the P2TRv2-disable-soft-fork in time
- Or move to P2M= R, you'll be safe.

>=C2=A0 Still, I think my point stands - in the face of many bitcoiners writing off= the quantum threat,=C2=A0wallets aren't going to have a lot of incenti= ve to adopt technologies that make things marginally=C2=A0more expensive.
Maybe in 2027, but what about 2028, 2029? If we see steady progress t= oward a CRQC the drumbeat will become louder and louder and wallets will wa= nt to tell their users they are quantum-safe and secure against classical a= ttacks on ECC.

The first parties to move over will likely be big hol= ders willing to pay a trivial increase in fees for security against existen= tial tail risks.

>=C2=A0 I'm confused by this comment - a sof= t fork that disables insecure spend paths to avoid them being=C2=A0stolen i= s likely going to have a very easy time, not "fight an uphill battle&q= uot;?

soft-fork-1: Disables insecure key spend paths in P2TR. I don&= #39;t have an opinion on the ethics of this, but the incentives are aligned= to make this happen (reduces supply).
soft-fork-2: ZKP proof of seed ph= ase to allow people to safely spend from a disabled key spend path. The inc= entives are aligned to oppose this soft-fork (increases supply).

The= incentives support soft-fork-1 happening, but soft-fork-2 not happening. I= don't claim to predict a future here, but the incentive issue here wor= ries me.

Other questions:

Soft-fork-1 must be designed so tha= t soft-fork-2 is not a hard fork, that seems doable, has anyone written up = a plan for it?=C2=A0

How big=C2=A0is this proposed PQ ZKP proof of s= eed phase? I've been assuming ~100kb per spend since we have to use PQ = ZKPs.


On Thu, Feb 12, 2026 at 9:56=E2=80= =AFAM Matt Corallo <lf-lists= @mattcorallo.com> wrote:


On 2/11/26 5:57 PM, Ethan Heilman wrote:
>=C2=A0 > For what its worth I do not see a scenario where a decision= ultimately made by the market will
> pick the fork side with materially, say 5-10x higher, supply, over the= side with lower supply...
>
> Completely agree, the incentives favor lower supply. I wouldn't wa= nt to count on it happening and
> even if it does happen the freeze fork might not freeze P2TR. Accordin= g to the 2025 chaincode report
> [0] P2TR represents only 0.75% of total supply.

I believe we're talking past each other, then. This was a side note - a= s Jonas mentioned it seems
reasonable that a P2TR-based QC signature validation opcode could come with= an on-chain signaling
bit (i.e. a "Taproot V2" that is functionally identical but indic= ates the presence of a QC signature
script path available).

>=C2=A0 > ~all wallets today use seedphrases, which could still be sp= ent with a ZK proof-of-seedphrase :).
>
> I'm all for putting ZKPs in consensus, but it seems unlikely to me= that it will happen.

We just agreed that its highly likely that insecure spend paths are disable= d. I do not remotely see
how such an action could occur if the result is that a large number of coin= s are seized. The only
viable approach way for that is to allow seedphrase-based wallets to retain= access.

> It is better
> to make Bitcoin safe than promise safety that requires a future hardfo= rk.

There is no hardfork required here.

> This is especially true
> since as you point out lower supply is incentivized, so a soft fork th= at freezes coins would be
> fighting an uphill battle.

I'm confused by this comment - a soft fork that disables insecure spend= paths to avoid them being
stolen is likely going to have a very easy time, not "fight an uphill = battle"?

>=C2=A0 > Hell, *any* PQ soft fork is going to see limited adoption i= n "consumer wallets" until its
> urgent,=C2=A0hence why I think the community will be basically forced = to disable insecure spend paths and
> only
> allow spends via ZK proof-of-seedphrase. But at least something that d= oesn't also 10x
> transaction=C2=A0costs might reasonably be adopted by default by walle= ts that don't use seedphrases like
> Bitcoin Core.
>
> I disagree. If we get P2MR and SLH_DSA/SHRINCS the wallets can use qua= ntum-safe outputs (Schnorr OR
> PQ) with Schnorr as the default spend. The wallets can market themselv= es as quantum safe.

This flies in the face of the last 15 years of experience with Bitcoin wall= ets. Yea, it sounds
great, but we've got 15 years of experience showing that wallets only a= dapt when they go out of
business/stop being maintained and get replaced with new wallets (which oft= en ship with the latest
technology). Worse, many bitcoiners (maybe rightfully, maybe not) entirely = write off the quantum
threat - all the more reason they will simply not adopt any changes.

> The cost
> in transaction fees to a user is small, a 1 input P2MR transaction wou= ld only be 37 bytes larger
> when compared with a 1 input P2TR transaction. Those 37 bytes are in t= he witness, so the real cost
> is ~10 vbytes.

Apologies, I had understood the P2MR proposal to only feature PQC-based sch= emes, rather than also
offering schnorr as an option, leading me to incorrectly conclude it would = be drastically more
expensive, rather than marginally so.

Still, I think my point stands - in the face of many bitcoiners writing off= the quantum threat,
wallets aren't going to have a lot of incentive to adopt technologies t= hat make things marginally
more expensive.

Worse, there's no real advantage here over just doing in the taproot ke= y path - because of address
reuse a wallet relying on P2MR + schnorr anyway will ~always have its publi= c key revealed so we
might as well continue relying on P2TR to save the 37 witness bytes and get= the same result (that
wallets can do something cheap with "just" a key derivation chang= e and explicitly opt in to a future
soft fork which disables the then-insecure spend paths).

> Yes, if Q-day happens, time passes and then quantum computers become p= owerful enough to perform
> short-exposure attacks, anyone needing to move their coins to an outpu= t have=C2=A0to pay fees for an
> additional 8,000 bytes (SLH_DSA) or=C2=A0324 bytes (SHRINCs). This is = still better than a PQ ZKP proof of
> the seed which would be between 20,000 to 120,000 bytes and more likel= y to have a security flaw than
> SLH_DSA.

Yep, I'm not proposing at all that we do nothing because a ZKP of seedp= hrase is an option, rather we
should add support for SHRINCS and encourage wallet adoption. But at the sa= me time we should
understand that we're incredibly unlikely to see the kind of adoption i= n time to avoid the need to
do something like a ZKP of seedphrase when the time comes.

This is also probably the least interesting point of contention, FWIW - thi= s is a decision for a
future bitcoin community, not a decision for us to make today.

> If efficient quantum signatures or compression techniques are develope= d, we can and should adopt
> them. If they are efficient enough, they can become the default. This = proposal is designed to keep
> funds safe in the intermediate period while better techniques are deve= loped to cover the tail risk
> where Q-day happens before the technology we need to completely ready.=

Yep, we absolutely agree! I just don't see a reason to do P2MR over jus= t utilizing P2TR (or maybe
P2TRv2).

>=C2=A0 > No it doesn't - it requires a soft fork when the risk i= s imminent, but it happening somewhat
> before that time is okay too.
>
> We might wait too long and misjudge the risk and Q-day happens before = the soft fork activates? What
> happens if freeze fork is activated but then 3 years pass and it looks= like a CRQC isn't going to
> happen after all? Now people who had their coins frozen are pushing to= undo the soft fork.

> This approach carries too much risk from uncertainty and it was "= the plan" it signles that Bitcoin=C2=A0
> leaving things up to chance that don't have to be left to chance.<= br> >
> Enabling people to opt in as early as possible enables the prudent to = protect themselves for very
> little effort and cost. Those people know their coins are safe and can= still use their coin as they
> did before.

We agree. I believe your response is based on a misunderstanding of my argu= ment, hopefully clarified
above.

>=C2=A0 > I mean people can create invalid addresses today in plenty = of ways. How is this unique?
>
> P2TRD would be an address, which looks exactly like a 100% valid addre= ss and which can be spend from
> like a valid address and hwoever at some future time, it may or may no= t, become frozen.

Sure, but this is still no different than any other P2TR script-path struct= ure - you have to test
things you use, even if you use them rarely, which is the entire point of t= he P2TR design :).

Matt

--
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/CAEM%3Dy%2BU673Q1U09Z_xrumiBjU9q9xKGnMOE3OC41Qt651g2ROw%= 40mail.gmail.com.
--000000000000804a65064aa463a9--