From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 13 Feb 2026 08:22:02 -0800 Received: from mail-oa1-f64.google.com ([209.85.160.64]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vqvvd-00080i-5U for bitcoindev@gnusha.org; Fri, 13 Feb 2026 08:22:02 -0800 Received: by mail-oa1-f64.google.com with SMTP id 586e51a60fabf-4094f9a49a1sf8593302fac.1 for ; Fri, 13 Feb 2026 08:22:01 -0800 (PST) ARC-Seal: i=3; a=rsa-sha256; t=1770999715; cv=pass; d=google.com; s=arc-20240605; b=Lr1TnZcSXC3xVanAnO/P+R6tdkvEX9JtpUyY63elndwJIGIDZWy9MDR28jgmyP4EzJ h0hNDZX8I20j2RAZ8akW1INyTzd76XImoqs3YZ/xDz2GejKpTVFBeMasYHnjd577EaIa rUaeNge/3DtpRYWo9fVehKkkzSnMgVW9DmP+gbx5zPTFq7HCg+dyoAXxH0skjmHJ1XQ2 Z/ltIX4GY9ady6NddQr2a893+HTJRwRz/CncWjYvIkNaNTgAUOp2wxElYjbAFmS2AbFJ k2ts+8ahhL8FvYu6DRiQvygubfIpyibN+3ieVELuKc/bHdf3kxZBvcVmd4+3VhA97FvO iF9w== 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=vIE2MfT3e9Eh5HZxxX5zmjkmLCBzp0kbULYsxK52q8M=; fh=gRPKCQAeGruHUNnNkWeCABhKBMh+STY0NGaFMHqW7zc=; b=DfDAkz7EDHXDBZsNQzNFAmgMq6NYSIv4wa0K/C/G/sPbCZd9IzHSShBwaXthVwX77z KX9kvBXeOCFmsJbfIYnYC1bpldiRAjNyhkOWbmLefN2p3We0j3GEswL3UB/Ry2U8LlBY AmZAQhQseF2av4S4hza1sgmUOgQzAoSrvkUT7GF1yxDNzRgXNdjVU/g9njhBtDzUMT1K zxSgKlpvDC/uv7EXmjSnRK+oJzx/UpIsWUKoBZxsFArcaYpLFJCcO7sBilmwvLvN5rEF /OVIhcabx9/7uyBRduNjkH27FsiAOiVodx5Mw4lwtt6JkCDGPU6NrjiGPl2XULkd1k2U +04w==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=VKSU9tzg; arc=pass (i=1); spf=pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::629 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=1770999715; x=1771604515; 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=vIE2MfT3e9Eh5HZxxX5zmjkmLCBzp0kbULYsxK52q8M=; b=PV2vV0iOP6ytLmAyjavthlfXKQpiRU9D07oIw4qZZIwFfCAWJvU1HN1nfPBa7VVzkA HcxFTrDHpTSuz4M7k3R/ZYDBxkj6Bu5g7ucIAWykCi3E6NVOnwVEaOgpttRUyXsYmp1H bGWcXqOQRQqYz0367aEwSfd69zmf7uFF5soG4eN0syjrLM/q4l586fpGVNcN+g73eNMI ww10mnqKIbxi9xCNugUuB4RC56y0zw80k+JEuvFlWbOKo6FSXiletqGVh0+Gr/2SwaC8 i8e9M6WX0nYJrXRCTukDLOgiA+Jb13YX+3P2uJ2Pbw0Wrc5JuyEQeLVc/SrYHP7I5XLY rzEA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770999715; x=1771604515; 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=vIE2MfT3e9Eh5HZxxX5zmjkmLCBzp0kbULYsxK52q8M=; b=G9WfJrceuqm4zzpBSh1fcxYk0qgRSSmY969BkU5VxJXTaINN9RX13yjHj70YPhjZhO DkJOVztleMfpnQ8X/Fa3wwCExNmrvrT4XDo5JL8Xa0sKNP0kh2IU/Kq+Y8xfiZqzq1Co AWVO/pigW6+V22mdyUYx29x1fJRrXA4KH9L4TQStO/0XaicQEz31UjyvD2L2k/tnaY+Y VC5xidGuNnATZL6W7GjOeJhQ7rqyRH9NDjUvoeVnIhYc4ZEc1O/r6Z2gusT6G9TvlcPw QOD1cWVZD/mzdBggo1AB5lthVB0FxunQy2TxKzV+TM4teP77lnBOH2iMwwTq87az0Z5x FsOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770999715; x=1771604515; 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=vIE2MfT3e9Eh5HZxxX5zmjkmLCBzp0kbULYsxK52q8M=; b=BWt47dL+W+poe1IQoTpiZfLOr3B+L24A6gRzBbstzkYPsZWvO1EhBuqGrRFmJHopCt D5xI5kaV7CRfGTOEL5ua9CwIHj8HeJsVHh3jw2mTaTyd/vyoFwMdN5tZiptUsJGaEnNt aB256LxP5WHuAnkXdKwu3m0tVvo9PcVVO73yfPuAI6YHV5M/VpM7Yq90SWCE6V3unHG0 o+nY51ukzJLtyz0rdNOubPn3DQdko4MJqkMwcBSJB8UftYjeN1bCNYm87eBkG6Dvm9SE gPA2lVlHW8cn2CicbnYyp5VM77DI6cmhS+1lfrFobh4WzgqLyijlYVz1/FcC9avctnGf Cw8w== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AJvYcCXn7lpLhStK5RcNV6Aow00kTqrM5qJeJxQS0cpqOlue9chF8T6vH10W/kFSm+gMg/ljnOoLv7Zk2ND2@gnusha.org X-Gm-Message-State: AOJu0Yz9Dgw5GntS1Z0bfmCiFeVoJxis4+GeqOiuuZJxN+Mxf1lF3zV5 mm06TXUFM4STB67G2YPs6e7zNhZLjd89n0we6f+0JPUuuZjxsl5zhLN4 X-Received: by 2002:a05:6870:30f:b0:409:6da8:c8f4 with SMTP id 586e51a60fabf-40ef3ad3c3dmr1266776fac.6.1770999715332; Fri, 13 Feb 2026 08:21:55 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+Hsfd4RhSRvgR9IFibpvmwyV+piqrxhBSQPq4bH90GgFQ==" Received: by 2002:a05:6870:f21e:b0:3e8:2785:9a19 with SMTP id 586e51a60fabf-40eca6341b8ls1485279fac.1.-pod-prod-08-us; Fri, 13 Feb 2026 08:21:50 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCWARx+REfBVlPbaaoQgVZ/TibUDjOZYZ2pqsBluxbz/J/asgauwu7tIG84GkCBaXkwzen7zmH2T4OdD@googlegroups.com X-Received: by 2002:a05:6808:b3a:b0:45c:8fa8:7497 with SMTP id 5614622812f47-4639f1a36c8mr920443b6e.34.1770999710264; Fri, 13 Feb 2026 08:21:50 -0800 (PST) Received: by 2002:ae9:e101:0:b0:8b2:e5d4:9264 with SMTP id af79cd13be357-8cb33765a09ms85a; Thu, 12 Feb 2026 12:35:59 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCVqek0274CiKLL36ypdjVk0pm03gZREweT3+xDBm+DZ/0BWQz4pjB/9C9PELFq05uTtXSS/WcmuVgU8@googlegroups.com X-Received: by 2002:a05:622a:18a9:b0:4ed:e5c1:797 with SMTP id d75a77b69052e-506a6a41272mr70531cf.23.1770928558699; Thu, 12 Feb 2026 12:35:58 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1770928558; cv=pass; d=google.com; s=arc-20240605; b=j3VUjNGfBoLF0+fJTpYYzo5e0aDbJEN21B7ohudkoWTFcZRcgdVgsOJmfO+F/fQ2Sv llcdJeYeSG3Hbb2aw3PMLo38zAy5XNgGAUPjxkSgQG8tC0GYvwUKuuxCsbQhhHCdw484 +smrSgvbbiu2leF3R4J8xak00jCnJzdW8AluE2GixrkGRWsZL8tFDEmP+PjotMqL6mIB p0IWxyblJjWuFfPKBCgMEdRRsZctEAQU79Fxm8IAVslD3oO6NFfD6h8wCHgDuyO+kfOD INT3Xgbn5Fv09quSQH0eLAwUix5sENyB2eydVvfYiRzuyyxp0YoyExBve9vDlG8/iQDM RGgA== 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=52o8DZgaXn5ELK2gGFIZ40vER55m8WZyaXezkI6Dfik=; fh=XjvuH4EDkPge600TW4X3kJqJJBbZcVPkvVPM4MFOfng=; b=LOssPVfaEa45BW1l494d/MGUC9Q5N0f1pE2kkwU+L3ewjl845X5lgKBYXDCfxKpUw1 eu0zi5zZy0sDttiyWutCbqTKzA6ukA151RbDF7mMdIohAfmFqaw7bGP1BS8MtMW43cLa vVBojiOApn1IXp4pQB0n5UTzWaudN+0ITxsRHZ1fPcvy98cjKJHI3s90/s97ZpEWbB48 DFa8Xu90eq2HzRA45D4A9Wxb1jlJhrjGZNp7rANKoWo01C53G2BLLGS99VXHJ2wNmsPe N0lkT86nfxABRkdSAQQAcUODe3bXN6+61wu26bvwMBubMa+jsQy2yZBVV/8Ja4nfEZBL 9Fjg==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=VKSU9tzg; arc=pass (i=1); spf=pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::629 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-x629.google.com (mail-pl1-x629.google.com. [2607:f8b0:4864:20::629]) by gmr-mx.google.com with ESMTPS id d75a77b69052e-506a04b133dsi623921cf.3.2026.02.12.12.35.58 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 12 Feb 2026 12:35:58 -0800 (PST) Received-SPF: pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::629 as permitted sender) client-ip=2607:f8b0:4864:20::629; Received: by mail-pl1-x629.google.com with SMTP id d9443c01a7336-2a962230847so1858765ad.3 for ; Thu, 12 Feb 2026 12:35:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1770928558; cv=none; d=google.com; s=arc-20240605; b=GQLFBBThL+Qx10SSzMX87GzqqPDQ1kXM7t/Hvg3as6BQS6OjwYO6vp2+2XDwjFXXyM FHN2kP0lsIAqwP8ueI1i3cwPzdUEAo1FhGvsTFFzobdSsD2/a/9k8Y/3oltDXTPuwaL+ jBag5b5jfd2EBnVO2/mt6hqyXHlZ063mORQ4vt8BIs44QAWBxBdn173W+jGo71OC+7e1 QVnSLw/89WNW87sIwexZ3BVoM9wEW9B2o/otV43mDJPf8oTNrubhXsVieft4PbSoIEGq /nU6p/t344Z5M3XwHbjloMIqn0ZETc49jEYRM+VEBwdiM7GontWLS9iEhYBSGKG5oPVZ NkNA== 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=52o8DZgaXn5ELK2gGFIZ40vER55m8WZyaXezkI6Dfik=; fh=XjvuH4EDkPge600TW4X3kJqJJBbZcVPkvVPM4MFOfng=; b=Zb6/zLSRtlgMU7mNDlJPLg4OkYid2JdfE1Fcacm+GWzaDwrMqs89auya9qTTApDgpl f8PmHhInnT5yvxB3gYsSfTvqjuF1gKk07Wf+iQ/QkbKF3D8N8xBLi/FyDqlYtWyphlcJ MwOW5gj4xMSUBYnyqeUG1tblgNwWKXHqn984dPaAA/SJvqqa9wx0jdg3nOM7K8h1Avn0 JZRBGP065sgP2XfcpWF1REjOPUoiZcOr4OJSo9eyTZWgVi37wl39v/nVZJnzTrRj95PW P90ARzZ2NVQxS2BqOOpKNKSPKc4PehweeeWFA0jbDdG4r6ikY5ai+nEDbb51ecv+ndmp ZODQ==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Forwarded-Encrypted: i=1; AJvYcCWw9b5umi5qtBfQ/c02+aPUodhAkWvYWZQ2SnNv5jUkhuUcXFcqxLflQW9wmSQmPrzCydStMxTmpMWQ@googlegroups.com X-Gm-Gg: AZuq6aKMRe/q8nE37U11pSVWxN/J85IOIiEOndVlT//agxBq1gaEFO1CIKJO2SSZbrz QfD0yrlKqZ3Kb2HvaM7sT7XKbmWYRpSBQckF2l8KPWEKFWdJ6yEChzXJfkdt0WmKPqIvXlvHuBC //foy5YtIwBQUm93OBxbEfK6t+rnDOipxZNRvzOCKOqTDOnlFIhiHOZQhu+Qqe3E5X+8QYg7+aw vzKd7PE5xROMQi502NIWUruL3FRv4H3JpQvs06jZitzXPQjqLA+9+FOorBW1hmsnppj3OmNuohT sgGkb4GKNZSQUhLD6vqO6+705DjIldwFVEcvpH68md0V7AbcKyEZ5FvJNGIP0nZzk9xp1vGSEyQ RbZICPAYfiooQBqIe/3cdhpBPFYvll7ePT+HxyJtss4wmuMh0llyjt+8v6Gmwsby2lGz/9z9PaP dDBv61fZhDSy3myfqYQjr1wPWHlmDFvUPG21bo X-Received: by 2002:a17:90b:56c4:b0:354:bf10:e6a3 with SMTP id 98e67ed59e1d1-356a77792e7mr357532a91.11.1770928557652; Thu, 12 Feb 2026 12:35:57 -0800 (PST) MIME-Version: 1.0 References: <22073a56-1cbf-4ba9-a2ea-46c621d4619c@mattcorallo.com> <1f0ebca9-2d23-44f9-8e6d-aaea99a832e3@mattcorallo.com> In-Reply-To: From: Ethan Heilman Date: Thu, 12 Feb 2026 15:35:20 -0500 X-Gm-Features: AZwV_QioyGQpALyG6ugNjxJEX60vrDeyfW7OEAROeBK64Kbnu-sO8FlYwf2Wby0 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="0000000000009a012b064aa66f53" 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=VKSU9tzg; arc=pass (i=1); spf=pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::629 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 (/) --0000000000009a012b064aa66f53 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Replying to Waxwing, and Matt in this email Waxwing: > If supply and demand is king, why not just delete supply as much as possible? No more mining? I agree with you that a soft-fork that simply burns outputs to reduce supply is unlikely to activate. I do agree with Matt's point given the specific circumstances here. Everyone would want soft-fork1. It freezes coins that would otherwise be stolen with the promise to unfreeze them with a planned PQ ZKP proof of seed phrase. Even the people whose coins would be frozen would want soft-fork1 since it protects them. This makes it very likely that if the threat of quantum theft is credible, soft-fork1 would activate and everyone would be happy with this result (assuming it activates in time). Now time passes, and the people whose coins are frozen want soft-fork2. They feel they have waited long enough, but there is a problem. While soft-fork1 was trivial to write, soft-fork2 requires a complex PQ ZKP that will become consensus critical to Bitcoin. This is a complex task requiring expertise. Will it actually get done? By whom? Assume soft-fork2 actually gets built. Now it has to get activated. Blocking a soft-fork is much easier than activating a soft-fork and this will be a particularly contentious soft-fork. Some will argue it is unfair that holders who did the right thing and upgraded to secure outputs will be forced to on the consensus risks of a dangerous soft-fork simply to unfreeze coins that the original owners didn't even bother to secure. Others will just stall soft-fork2 by saying it hasn't been tested enough or there isn't consensus. Making this worse, miners are unlikely to want to increase supply. Getting miners to activate soft-fork2 is much harder than soft-fork1. Soft-fork1 activated because everyone was aligned. Soft-fork2 no longer has that alignment and is much riskier. "Aww shucks, we really support unfreezing these coins, but we the miners just don't think the current iteration is ready for prime time, why don't you put more work into it and try again in five years." - every five years until the heat death of the universe. Matt: > I believe this is largely only possible either with an ethereum-style "difficulty bomb" or simply doint it all in one go. The do it all in one go approach avoids the incentive problem, but how will this be built? How many cryptographers are willing to invest the years of effort to create a soft fork that is unlikely to activate, all to protect holders who can't be bothered to move to a safer output? The most likely outcome is some kid just writes a simple soft-fork that freezes all the insecure outputs, and miners activate it because they have cover to reduce supply/pump the price. I'm not endorsing this course of action, but it impacts my thinking on building PQ ZKP proof of seed phrase. I ask myself why spend 5+ years on a PQ ZKP proof of seed phrase soft-fork just to watch a low effort soft-fork annihilate all that work? > No, P2TRv2 and P2MR are totally equivalent here. Because address reuse is rampant, P2MR will *also* require an equivalent P2MR-disable-soft-fork. The only material difference is the cost, and some small minority that doesn't do heavy address reuse. Wallets that encourage Schnorr key reuse with P2MR should be thrown out the metaphorical airlock. Wallets claiming quantum safety must warn a user if that user has exposed a Schnorr public key on the blockchain and make it easy to move to a new address. There is UX work to be done on this problem, but it is achievable and worthwhile. On Thu, Feb 12, 2026 at 2:16=E2=80=AFPM Matt Corallo wrote: > > > On 2/12/26 1:08 PM, Ethan Heilman wrote: > > > 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 unexpectedl= y. > > > > 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. > > No, P2TRv2 and P2MR are totally equivalent here. Because address reuse is > rampant, P2MR will *also* > require an equivalent P2MR-disable-soft-fork. The only material differenc= e > is the cost, and some > small minority that doesn't do heavy address reuse. > > > > 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 pa= y > a trivial increase in fees > > for security against existential tail risks. > > Right, so the first parties to move will be the ones we don't really care > about (because they can > just move quickly later anyway) :). > > > > 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. > > Fair. Given the ethics questions and the amount of pushback I have to > imagine every effort *has* to > be made to allow maximum wallets to retain coin ownership as otherwise th= e > resulting Bitcoin has > less value just because of seizure concerns. This all depends a ton on > specifics, though - has it > been 5 years since P2TRv2 was added? 10? 25? When did wallets start > migrating in earnest? Did they > even until it was too late? > > > 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? > > I believe this is largely only possible either with an ethereum-style > "difficulty bomb" or simply > doint it all in one go. > > > 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. > > Yes, I imagine quite large. Hence good to push migration along first. If > migration is limited, I > imagine there will be some desire to provide strong fee-discounts for > these ZKPs, maybe also > aggregating them in blocks. > > 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%2BUh63i0nYt4zcsPzpeNW2nwGhowCqQEHxLEE8EYMRY%3DsA%40mail.gmail.com. --0000000000009a012b064aa66f53 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=C2=A0Replying to Waxwing, and Matt in this email

W= axwing:
> If supply and demand is king, why not just delete supply as= much as possible? No more mining?

I agree with you that a soft-fork= that simply burns=C2=A0outputs to reduce supply is unlikely to activate. I= do agree with Matt's point given the specific circumstances here.
<= br>Everyone would want soft-fork1. It freezes coins that would otherwise be= stolen with the promise to unfreeze them with a planned PQ ZKP proof of se= ed phrase. Even the people whose coins would be frozen would want soft-fork= 1 since it protects them. This makes it very likely that if the threat of q= uantum theft is credible, soft-fork1 would activate and everyone would be h= appy with this result (assuming it activates in time).

Now time pass= es, and the people whose coins are frozen want soft-fork2. They feel they h= ave waited long enough, but there is a problem. While soft-fork1 was trivia= l to write, soft-fork2 requires=C2=A0a complex PQ ZKP that will become cons= ensus critical=C2=A0to Bitcoin. This is=C2=A0a complex task requiring exper= tise. Will it actually get done? By whom?

Assume soft-fork2 actually= gets built. Now it has to get activated. Blocking a soft-fork is much easi= er than activating a soft-fork and this will be a particularly contentious = soft-fork.

Some will argue it is unfair that holders who did the rig= ht thing and upgraded to secure outputs will be forced to on the consensus = risks of a dangerous soft-fork simply to unfreeze coins that the original o= wners didn't even bother to secure. Others will just stall soft-fork2 b= y saying it hasn't been tested enough or there isn't consensus.=C2= =A0 Making this worse, miners are unlikely to want to increase supply. Getting = miners to activate soft-fork2 is much harder than soft-fork1.

Soft-= fork1 activated because everyone was aligned. Soft-fork2 no longer has that= alignment and is much riskier.

"Aww shucks,=C2=A0we really sup= port unfreezing these coins, but we the miners just don't think the cur= rent iteration is ready for prime time, why don't you put more work int= o it and try again in five years." - every five years until the heat d= eath of the universe.

Matt:
>=C2=A0 I believe this is largely only possible either with an ethereum-style "= ;difficulty bomb" or simply=C2=A0doint it all in one go.

The do= it all in one go approach avoids the incentive problem, but how will this = be built?=C2=A0How many cryptographers are willing to invest the years of e= ffort to create a soft fork that is unlikely to activate, all to protect ho= lders who can't be bothered to move to a safer output?

The most = likely outcome is some kid just writes a simple soft-fork that freezes all = the insecure outputs, and miners activate it because they have cover to red= uce supply/pump the price. I'm not endorsing this course of action, but= it impacts my thinking on building PQ ZKP proof of seed phrase. I ask myse= lf why spend 5+ years on a PQ ZKP proof of seed phrase soft-fork just to=C2= =A0watch a low effort soft-fork annihilate all that work?

> No, = P2TRv2 and P2MR are totally equivalent here. Because address reuse is rampa= nt, P2MR will *also* require an equivalent P2MR-disable-soft-fork. The only= material difference is the cost, and some small minority that doesn't = do heavy address reuse.

Wallets that encourage Schnorr key reuse w= ith P2MR should be thrown out the metaphorical airlock. Wallets claiming qu= antum safety must warn a user if that user has exposed a Schnorr public key= on the blockchain and make it easy to move to a new address. There is UX w= ork to be done on this problem, but=C2=A0it is achievable and worthwhile.

On Thu, Feb 12, = 2026 at 2:16=E2=80=AFPM Matt Corallo <lf-lists@mattcorallo.com> wrote:


On 2/12/26 1:08 PM, Ethan Heilman wrote:
>=C2=A0 >=C2=A0 Yep, we absolutely agree! I just don't see a reas= on 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.<= br> > - 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 activ= ated.=C2=A0Funds 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 unexpected= ly.
>
> 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 as possible.=C2=A0Ac= tivating P2TRv2-disable-soft-fork as
> early as possible is equivalent to activating P2MR. Thus, might as wel= l 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.

No, P2TRv2 and P2MR are totally equivalent here. Because address reuse is r= ampant, P2MR will *also*
require an equivalent P2MR-disable-soft-fork. The only material difference = is the cost, and some
small minority that doesn't do heavy address reuse.

>=C2=A0 > Still, I think my point stands - in the face of many bitcoi= ners writing off the quantum
> threat,=C2=A0wallets aren't going to have a lot of incentive to ad= opt technologies that make things
> marginally=C2=A0more expensive.
>
> Maybe in 2027, but what about 2028, 2029? If we see steady progress to= ward a CRQC the drumbeat will
> become louder and louder and wallets will want to tell their users the= y are quantum-safe and secure
> against classical attacks on ECC.
>
> The first parties to move over will likely be big holders willing to p= ay a trivial increase in fees
> for security against existential tail risks.

Right, so the first parties to move will be the ones we don't really ca= re about (because they can
just move quickly later anyway) :).

>=C2=A0 >=C2=A0 I'm confused by this comment - a soft fork that d= isables insecure spend paths to avoid them
> being=C2=A0stolen 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 ha= ve an opinion on the ethics of
> this, but the incentives are aligned to make this happen (reduces supp= ly).
> soft-fork-2: ZKP proof of seed phase to allow people to safely spend f= rom 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 happ= ening. I don't claim to
> predict a future here, but the incentive issue here worries me.

Fair. Given the ethics questions and the amount of pushback I have to imagi= ne every effort *has* to
be made to allow maximum wallets to retain coin ownership as otherwise the = resulting Bitcoin has
less value just because of seizure concerns. This all depends a ton on spec= ifics, though - has it
been 5 years since P2TRv2 was added? 10? 25? When did wallets start migrati= ng in earnest? Did they
even until it was too late?

> Other questions:
>
> Soft-fork-1 must be designed so that soft-fork-2 is not a hard fork, t= hat seems doable, has anyone
> written up a plan for it?

I believe this is largely only possible either with an ethereum-style "= ;difficulty bomb" or simply
doint it all in one go.

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

Yes, I imagine quite large. Hence good to push migration along first. If mi= gration is limited, I
imagine there will be some desire to provide strong fee-discounts for these= ZKPs, maybe also
aggregating them in blocks.

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.co= m/d/msgid/bitcoindev/CAEM%3Dy%2BUh63i0nYt4zcsPzpeNW2nwGhowCqQEHxLEE8EYMRY%3= DsA%40mail.gmail.com.
--0000000000009a012b064aa66f53--