From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 11 Feb 2026 15:14:42 -0800 Received: from mail-oi1-f189.google.com ([209.85.167.189]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vqJPt-0001M6-JS for bitcoindev@gnusha.org; Wed, 11 Feb 2026 15:14:42 -0800 Received: by mail-oi1-f189.google.com with SMTP id 5614622812f47-45f0bfd68a3sf14193639b6e.3 for ; Wed, 11 Feb 2026 15:14:41 -0800 (PST) ARC-Seal: i=3; a=rsa-sha256; t=1770851675; cv=pass; d=google.com; s=arc-20240605; b=X054MZDlaQM9Kdu1jtWzKOzQ65SqR3memeHn5z9YyowPgNnryPOhwaWCex8Pq7fS4A DnlyLXEoSpnIDhlshD6wxHpQuXF9G3K2K9KIEpjIVFkkDaJKu3CzcO20rP/cPlAuGsuq RofyBwaTFNaQia6Qsy9s4t/ClUc74GBmenDCjB5N/cXknuSC44yiL5SJbxPYN4fsh6F+ fkGHRTuS1H+bNDGUUsswowqq31Ae9u6VJ7Okd/0tY4gnl1Y0WVtvDyqS+9yi0G0LF/xc imbJwgi4ppKwkaYyM0HnCsQGoWto8I6cQ/Bf8BCmIHcouIPamx/Ajvc2kPIyCNfhDAvP sgDw== 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=wiDhkUi7ZW4vNbwmTjpJ1mwy2Wnj9Ok3mUSMMpA/+Rw=; fh=FjlgBvEvGV16fT3oO8G/EwLsk/lsv3ax4S/p+wLfovY=; b=HAOjqZlpjijykVkQ2EJOF2rXVZnuwIUFnjHG9131kNKu125XZAs4Eor19q+lLgGzhP ySxQY7ESwnWkXPFdZbYK7QQzgFZeKkpuXlJe+j1ppZke2UjJauyyYm7a1O3gjfz4RC85 c3bR6tmalpEazepxJSOPniIlgyH7ah5R2Mpfgl83Uni7wsja3X0VCuXL1sfB+04hR85o T9VE8BBg8Eh80qd+evnVy9dXF6claFQXC5QRjHZhen3SOKt0QusQPIwvqcoRU1HNIvLB CbO7MOfIhPpIfyzwG7XB6Pb6VQBl+1ZZdySCr/S5J3ONh2rAlCP79srvMB9VcqrzAUsI kgpw==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=b+dXij3b; arc=pass (i=1); spf=pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::535 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=1770851675; x=1771456475; 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=wiDhkUi7ZW4vNbwmTjpJ1mwy2Wnj9Ok3mUSMMpA/+Rw=; b=QoiL5P43dwlkZQdmtK1b9SIAWL1KXVbRogW/VLkzdYC/lGDALG7eIPq8sgZMw0sjlT /+4bPUvAW7HPpizMi9jbUqr4qytdwY/CKJL+9sWXXU5gdQQMUsvWAJQFf3RAO+fuT5w3 ZgwVgjg//Oc9vgc6DYK6MdmccU0Z5pvBnyt3ge+rh7QuAnu/VVMWFpT6ps0hBfC8u7o+ DVKciGayRztiS9wrYsdUddxUEB4vFFwP1lOtOXRrpO9CmKWIWhP1zNrmmh64Y2YQdO0Z mUl97i00FDdNaiicwaT2EGEzL2sDWLGE2Kocm2lfMSwILThTW9vznuw7M6vgay+nlaix tEeg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770851675; x=1771456475; 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=wiDhkUi7ZW4vNbwmTjpJ1mwy2Wnj9Ok3mUSMMpA/+Rw=; b=kFz6ntvyfWoidG0SSyi5x70dIuRCq2x737658dzOZCRG+cm8JlQWvNZIDJDePfRlK3 MeWkIJk9wdJ5ZoRGS/LOXaGnE+fzRuE7d8Oc553VnWoVfzboVU3Vuq3Di5JN4KuMd/+u rYUj9gGPcQxpHbXVFwXJWF6MUoUNdqgBGDyXqo7NeWDspd/9PS2OYGf91mS4K/somJCf UgHYz/qUEIBc14wEFEKyhXltoe4nnK/HTMB7g2X83pNVrR92xj5Cgxhuogc7gVoPMtrK 53hVLj2/dQZR2BRX/Naif7NP6pjG/eqZmq1TG5vmnC20nB6S9yXvebOTQoQJDMVwH8jc /0Cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770851675; x=1771456475; 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=wiDhkUi7ZW4vNbwmTjpJ1mwy2Wnj9Ok3mUSMMpA/+Rw=; b=pGi/AYbYDGleYpARTfoeQXWQCtDY7sC/JNztPz/W4Sm0yoLfTd41hfR4vYxrRPDlXP Dp07xL7KVRGRVdkIaWF/8er80FDkjJiVriSM2i7bfg/1C/4EydMNUL2iuayApX8zho47 RUHIo3jCIf6/VWVQaMZhfDXM62XT2SrSzdUn5Fh2p4Sg9jNGAXTtTcp5ZEkb9zesnP9Q gcjIRRMQAwxfKLeNK32ZjxJe81dM2R7Ej6MqOcjINbgZIN1WuRZRB2CjjFM2wEe77Vpw uDDcr7s5O8Hc1V3GsPxI6cg4ONDZL6WeYMAmz0MnJ7bGwYHLgbj6jXoRUF3R4LWfTdh7 tpEQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AJvYcCV54KeWYMeqUCrpMIQ/dgMYTFpBP4HIPdog2TDcar3MO5BZwODuIFDwBQuj9HKoGsM0FwU+WJgjmO5y@gnusha.org X-Gm-Message-State: AOJu0YxWyvXGctnz5MHERoFb2zSVADbmIhJdLNqHaOSRGggsxdmM5Jxv ImwUsbte2OQ2JtDghfpmVnsoUUDtFCRNvvUDoBSTTBBrFEDj/PZ4uOBc X-Received: by 2002:a05:6808:1919:b0:44d:ae36:dd86 with SMTP id 5614622812f47-4637b8d3ec1mr544206b6e.59.1770851675143; Wed, 11 Feb 2026 15:14:35 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+EKOZ3zbEqNpUu8YMV/f+vA+r0IWvzugkDMQ26FkZCJZw==" Received: by 2002:a05:6870:1b85:b0:3ff:c482:532 with SMTP id 586e51a60fabf-40eca6c04e5ls40772fac.1.-pod-prod-06-us; Wed, 11 Feb 2026 15:14:30 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCUzr4H3bXnupyLCzQYnOBYvrWTcsoEbxFIoMIKaATdZr6ECbddtQwE7WVVCBWiN1aExvIZs9lFzDgF7@googlegroups.com X-Received: by 2002:a05:6808:bd5:b0:44f:e912:ea97 with SMTP id 5614622812f47-4637b68329cmr511667b6e.18.1770851669946; Wed, 11 Feb 2026 15:14:29 -0800 (PST) Received: by 2002:a05:620a:124e:b0:892:e292:65ef with SMTP id af79cd13be357-8cb33766c50ms85a; Wed, 11 Feb 2026 14:57:47 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCUH4TgXmHt3Lf/qlVRn9JkX+ZMuQrwx6w8MV+xSKQ+u6B+daN0L+w5CAB8znWmZotL2iDC/0CCXoWv3@googlegroups.com X-Received: by 2002:a05:622a:14d2:b0:501:502b:8c6b with SMTP id d75a77b69052e-50691cbb8cemr15885501cf.9.1770850666729; Wed, 11 Feb 2026 14:57:46 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1770850666; cv=pass; d=google.com; s=arc-20240605; b=kAmdBdAHuwLptiL07+v9Nko+CSxr6UpKMMRFIufMs+S1emsYiLjsXuXP7WEEftCmdw c5ZEu0+goZhCZEOOMIPxx1o32LWq8YYdiZA2pG2zigLVQUieX7WS8MIIxd3F8vaI86Ip eI/r50uL61/0vTPwTrDIGzN1rMve91L/IQL/AnVdWi3eRqI82paSXEWrKUYsjiR1fZ4n 3FUICX4ZrqIPTetkQL+IwOMBpi5pbDCxDs/BwYQlEOZ9FoDnbIxnrjpzDiAQxacw3aae VyCuqlV5p/YLc1PyZpsaWoQBsj7bVOKjvoankKq+t+X0yoIQvsw94nom+Kr2cy9Hbe51 71hw== 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=OOznOEKWayi5ZG7bu4j9ExZ5hSf6Ll9zw0AEVHXqN2M=; fh=HXyx+d/lUkINhkqCW2OsL3Rs2UvpgOyHebh50z7nicQ=; b=XbAeN/pKOL6alg7X+eb96yCyj5OaWso1SnBCiYluSmyNDIcLomSk6FWkmdWp8bjkKQ BnIn6G/PQniE7/sHiGAbslbrOf66ztoBZNKX1WyobBH3aqRJYJQT0PRtk+9n2MlHDw4W 9i2H8v/G0PT0J+Yu/9RdUlYvMVysdtDukX1cbUWx5qC1uS2i0X/5gItYF4MSyw1BDIYQ YsE+P9SYgp9/RHFuUHQ7tUNqhTbw7PwqhyeJhAlLJJKEN7FgcMpF3nqzH1BtdEJvz/8d wKc/2VPzYrvFFpwdDW2ScoDPO4mWC1cxyuTjeYLuCt+a72CNus0au26pxXOBlwM0Tu2v tDiQ==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=b+dXij3b; arc=pass (i=1); spf=pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::535 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-pg1-x535.google.com (mail-pg1-x535.google.com. [2607:f8b0:4864:20::535]) by gmr-mx.google.com with ESMTPS id d75a77b69052e-50684b2f445si813781cf.8.2026.02.11.14.57.46 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 11 Feb 2026 14:57:46 -0800 (PST) Received-SPF: pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::535 as permitted sender) client-ip=2607:f8b0:4864:20::535; Received: by mail-pg1-x535.google.com with SMTP id 41be03b00d2f7-c2a9a9b43b1so3281792a12.2 for ; Wed, 11 Feb 2026 14:57:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1770850666; cv=none; d=google.com; s=arc-20240605; b=RvpI1ZaeEl2Wp24KF2gV5bouCvFgeVX8fAxV/5LdXoeoF0YiBg1vA/qI/6T1f2qXnO jdxSV1m36bWyQRv/nA+voAKDOsrx19eMKEnhGF50d+1dNDovHIAi1hhFDd4cpgmqUgFX 9xhy+j+TX8bCa+asEb/jZhY/ri5nk47vPd0vaTQESqiyfX9TuihdDeAUHCMt95/hT0vO h71sys4MRYwG9bNxxc4Q6cfKF9EluO9Qz6QhiCCbLSVpiECA6q8ZKg04KFnB9SPrfd/0 AjHlKUuDft5AtTQRZxdOiHqGeP7ip+FiqYurqc5tIS6QMXj3wQxApDwA3UPjLtKvMtVl NChA== 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=OOznOEKWayi5ZG7bu4j9ExZ5hSf6Ll9zw0AEVHXqN2M=; fh=HXyx+d/lUkINhkqCW2OsL3Rs2UvpgOyHebh50z7nicQ=; b=XxnvbOiaa85VYKR7YercqLFx7SOIMJ6759pMFAMZHZwfNXJB2A61JEIfVY85zWAYfg WwZos+2l3nL3WB2mstpA0KzSbLoB4wMcGKxyFScqo86lld5IDz4zrJ/RVRkKnaRpM9wR 174vVVI+eKNZMiH1N0CeuAJn7gnNCho6ZIQ1XGbmeb8VNX21rs/ivgBkc0jTV5wTyOiY irPczbz1YRDDSquoshuzOUUmzwB2+0/MjPppZBJSmO2xP8bLJJ1bmyGZY8qAIDqkxXS/ rSxFQ2sWbm+UOTHNNCBtyuJEPD+JJ4zqjHvcbGKtubWTtITIbf0/VRlLwc/+eqjZjqkz 684A==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Forwarded-Encrypted: i=1; AJvYcCXel5pRrLthkZzl7/r3wGTrYd3TRAgaU+4NkKydIXg/wtqW65a0xQ1a7Ei9EMKcgj1nAy7mcEEMP2Wk@googlegroups.com X-Gm-Gg: AZuq6aKyGtGVoRh27F62YItOJmoB8jHxYoisTrAStBnwQ+nBfDWx+AbgzdJ1k85vmec yDyHc+xuRnRF4zxRIP/fhsrflSwn8Hc3aaKONFrsrtYNazBCZs/HqgwAc8J6Bisth++WRSATEcV bnQmopsgw9XXeryXXJfarw1Gt/ytfq8lSVBIXd5dM0molK02NkE9wHERUHmBDYQBRWVuHOUNsrO 0gQ8d0lMJFz+PCrfEA9uKdXmD3ohVvNBklt/whUrl2tT90lT22L8EIxPfiv38AN5Mr5ZhRFXqn9 5FXVqdXG0pujSI6t+91dVdny3wOaqsWKw47MTBZEKBHDRBzgBRZnyDJ0HX1GZUt2dsrEAOI8/oJ w2mFRtfwBDW46xDZO2O68rNYIYAe4auoZfz6aATSxiHV7vfQW2YF9F99tplmXf86FHCena8Ry6+ diaovX6+MAPDTal4vWAVQsAA3n0A== X-Received: by 2002:a17:90b:528f:b0:354:c602:a573 with SMTP id 98e67ed59e1d1-3568f413a1cmr800444a91.27.1770850665705; Wed, 11 Feb 2026 14:57:45 -0800 (PST) MIME-Version: 1.0 References: <22073a56-1cbf-4ba9-a2ea-46c621d4619c@mattcorallo.com> In-Reply-To: <22073a56-1cbf-4ba9-a2ea-46c621d4619c@mattcorallo.com> From: Ethan Heilman Date: Wed, 11 Feb 2026 17:57:09 -0500 X-Gm-Features: AZwV_QhSUYxJJgHEjIl4PKCH8JGVKGoQ2_NTYI_6YVqwi6YQy1A0ezaiKTc6C0U 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="000000000000e136b6064a944cf4" 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=b+dXij3b; arc=pass (i=1); spf=pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::535 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 (/) --000000000000e136b6064a944cf4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > 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. > ~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. It is better to make Bitcoin safe than promise safety that requires a future hardfork. This is especially true since as you point out lower supply is incentivized, so a soft fork that freezes coins would be fighting 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 that 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 themselves as quantum safe. The cost in transaction fees to a user is small, a 1 input P2MR transaction would only be 37 bytes larger when compared with a 1 input P2TR transaction. Those 37 bytes are in the witness, so the real cost is ~10 vbytes. 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. 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. > 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. > 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 address and which can be spend from like a valid address and hwoever at some future time, it may or may not, become frozen. [0]: https://chaincode.com/bitcoin-post-quantum.pdf On Wed, Feb 11, 2026 at 1:53=E2=80=AFPM Matt Corallo wrote: > > > On 2/10/26 11:44 AM, Ethan Heilman wrote: > > > If Bitcoin disables Taproot key path spends before Q-day, then doing > this via Taproot instead of > > BIP 360 would be preferable. > > > > I worry about making the transition to quantum-safe outputs depend on a > contentious debate over a > > confiscatory soft fork. Uncertainty over whether the soft fork would be > released and if released > > would be activated means that wallets and custodians are unlikely to > have invested the resources > > into upgrading to support script only P2TR. > > 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...supply > and demand is king, especially with the "confiscatory" nature is basicall= y > nil as ~all wallets today > use seedphrases, which could still be spent with a ZK proof-of-seedphrase > :). > > > The benefit of BIP 360's P2MR (Pay-to-Merkle-Root) + SLH_DSA is that it > avoids this controversy by > > being opt-in and non-confiscatory. This also means that BIP 360 + > SLH_DSA is likely to activated > > early, allowing wallets and custodians ample time to build support afte= r > activation. > > The drawback being that it will see zero relevant adoption until its way > too late. > > The only entities that would reasonably adopt something like this are > large custodians, who aren't > worth worrying about as they'll easily migrate all their coins over the > course of a few days or > weeks in an emergency scenario, and highly specialty wallets. The point o= f > any PQ soft fork today is > if it can actually drive wallets to start making progress on PQ > deployment. A new address type that > is 10x more expensive to transact with is going to see ~zero adoption in > "consumer wallets" until > its urgent, at which point its obviously way, way too late. > > 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 that don't use > seedphrases like Bitcoin Core. > > > > We could define a new SegWit version that is a copy of Taproot. The > new version number simply > > signals that the owner consents to a future deactivation of key path > spends. Unlike BIP 360, this > > approach would still require actually disabling the key path before > Q-day, but it is not > > confiscatory and allows using Taproot's benefits until then (with > a privacy hit from having two > > versions of Taproot in parallel). > > > > Let's call this P2TRD (Pay-to-Tap-Root-Disablable). BIP 360 evolved fro= m > this P2TRD idea, to > > minimize the following hazards in P2TRD. > > > > 1. P2TRD requires a soft fork that depends on accurately predicting > Q-day or when EC Schnorr is > > classically broken. We must not only predict Q-day but also convince th= e > community that the > > prediction is correct. If we mess up the timing, Bitcoin is > significantly harmed. This means that > > people will constantly be yelling that we are messing up the timing. It > will make quantum FUD worse > > not better. > > No it doesn't - it requires a soft fork when the risk is imminent, but it > happening somewhat before > that time is okay too. > > > 2. P2TRD (Pay-to-Tap-Root-Disablable) to be non-confiscatory users mus= t > create a script spend that > > replicates their key spend, But users and wallets are likely to screw > this up and not create script > > spends. The is no way to see if a wallet is actually creating the scrip= t > spend on the blockchain. > > I mean people can create invalid addresses today in plenty of ways. How i= s > this unique? > > > 3. To be safe from long-exposure attacks P2TRD can't use the same publi= c > key for the script spend as > > the key spend. Since wallets will prefer the key spend to the script > spend, a user might not realize > > if they lost the keying material for their script spend until after > activation. > > It would almost certainly just be a key derived from the seedphrase via > another hash function, so > there's no real risk of this. > > 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%2BWRk6JU2xNdh6YYQE9VmkH1kv-CwBSYBxu0C0WocyKwNQ%40mail.gmail.com. --000000000000e136b6064a944cf4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=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, s= upply, over the side with lower supply...

Completely agree, the ince= ntives 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.<= br>
>=C2=A0 ~all wallets today use seedphrases, which could still be spent with a ZK pr= oof-of-seedphrase :).

I'm all for putting ZKPs in consensus, but= it seems unlikely to me that it will happen. It is better to make Bitcoin = safe than promise safety that requires a future hardfork. This is especiall= y true since as you point out lower supply is incentivized, so a soft fork = that freezes coins would be fighting an uphill battle.

>=C2=A0=C2= =A0 Hell, *any* PQ soft fork is going to see limited adoption in "consumer= wallets" until its urgent,=C2=A0hence why I think the community will = be basically forced to disable insecure spend paths and only
allow spend= s via ZK proof-of-seedphrase. But at least something that doesn't also = 10x transaction=C2=A0costs might reasonably be adopted by default by wallet= s that don't use seedphrases like Bitcoin Core.

I disagre= e. If we get P2MR and SLH_DSA/SHRINCS the wallets can use quantum-safe outp= uts (Schnorr OR PQ) with Schnorr as the default spend. The wallets can mark= et themselves as quantum safe. The cost in transaction fees to a user is sm= all, a 1 input P2MR transaction would only be 37 bytes larger when compared= with a 1 input P2TR transaction. Those 37 bytes are in the witness, so the= real cost is ~10 vbytes.

Yes, if Q-day happens, time passes and the= n quantum computers become powerful enough to perform short-exposure attack= s, anyone needing to move their coins to an output have=C2=A0to pay fees fo= r 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 likely to have a security flaw than SLH_DSA.
<= br>If efficient quantum signatures or compression techniques are developed,= we can and should adopt them. If they are efficient enough, they can becom= e the default. This proposal is designed to keep funds safe in the intermed= iate period while better techniques are developed to cover the tail risk wh= ere Q-day happens before the technology we need to completely ready.
>=C2=A0 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 to= o long and misjudge the risk and Q-day happens before the soft fork activat= es? What happens if freeze fork is activated but then 3 years pass and it l= ooks like a CRQC isn't going to happen after all? Now people who had th= eir coins frozen are pushing to undo the soft fork.

This approach c= arries too much risk from uncertainty and it was "the plan" it si= gnles that Bitcoin=C2=A0 leaving things up to chance that don't have to= be left to chance.

Enabling people to opt in as early as possible e= nables the prudent to protect themselves for very little effort and cost. T= hose people know their coins are safe and can still use their coin as they = did before.

>=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 1= 00% valid address and which can be spend from like a valid address and hwoe= ver at some future time, it may or may not, become frozen.

On Wed, Feb 11, = 2026 at 1:53=E2=80=AFPM Matt Corallo <lf-lists@mattcorallo.com> wrote:


On 2/10/26 11:44 AM, Ethan Heilman wrote:
>=C2=A0 > If Bitcoin disables Taproot key path spends before Q-day, t= hen doing this via=C2=A0Taproot instead of
> BIP 360 would be preferable.
>
> I worry about making the transition to quantum-safe outputs depend on = a contentious debate over a
> confiscatory soft fork. Uncertainty over whether the soft fork would b= e released and if released
> would be activated means that wallets and custodians are unlikely to h= ave invested the resources
> into upgrading to support script only P2TR.

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...supply
and demand is king, especially with the "confiscatory" nature is = basically nil as ~all wallets today
use seedphrases, which could still be spent with a ZK proof-of-seedphrase := ).

> The benefit of BIP 360's P2MR (Pay-to-Merkle-Root)=C2=A0+ SLH_DSA = is that it avoids this controversy by
> being opt-in and non-confiscatory. This also means that BIP 360 + SLH_= DSA is likely to activated
> early, allowing wallets and custodians ample time to build support aft= er activation.

The drawback being that it will see zero relevant adoption until its way to= o late.

The only entities that would reasonably adopt something like this are large= custodians, who aren't
worth worrying about as they'll easily migrate all their coins over the= course of a few days or
weeks in an emergency scenario, and highly specialty wallets. The point of = any PQ soft fork today is
if it can actually drive wallets to start making progress on PQ deployment.= A new address type that
is 10x more expensive to transact with is going to see ~zero adoption in &q= uot;consumer wallets" until
its urgent, at which point its obviously way, way too late.

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 insecur= e spend paths and only
allow spends via ZK proof-of-seedphrase. But at least something that doesn&= #39;t also 10x transaction
costs might reasonably be adopted by default by wallets that don't use = seedphrases like Bitcoin Core.

>=C2=A0 > We could define a new SegWit version that is a copy of Tapr= oot. The new version number simply
> signals that the owner=C2=A0consents to a future deactivation of key p= ath spends. Unlike BIP 360, this
> approach would still require actually disabling the key path before Q-= day, but=C2=A0it is not
> confiscatory and allows using Taproot's benefits until then (with = a=C2=A0privacy hit from having two
> versions of Taproot in parallel).
>
> Let's call this P2TRD (Pay-to-Tap-Root-Disablable). BIP 360 evolve= d from this P2TRD idea, to
> minimize the following hazards in P2TRD.
>
> 1.=C2=A0 P2TRD requires a=C2=A0soft fork that depends on accurately pr= edicting Q-day or when EC Schnorr is
> classically broken. We must not only predict Q-day but also convince t= he community that the
> prediction is correct. If we mess up the timing, Bitcoin is significan= tly harmed. This means that
> people will constantly be yelling that we are messing up the timing. I= t will make quantum FUD worse
> not better.

No it doesn't - it requires a soft fork when the risk is imminent, but = it happening somewhat before
that time is okay too.

> 2.=C2=A0 P2TRD (Pay-to-Tap-Root-Disablable) to be non-confiscatory use= rs must create a script spend that
> replicates their key spend, But users and wallets are likely to screw = this up and not create script
> spends. The is no way to see if a wallet is actually creating the scri= pt spend on the blockchain.

I mean people can create invalid addresses today in plenty of ways. How is = this unique?

> 3. To be safe from long-exposure attacks P2TRD can't use the same = public key for the script spend as
> the key spend. Since wallets will prefer the key spend to the script s= pend, a user might not realize
> if they lost the keying material for their script spend until after ac= tivation.

It would almost certainly just be a key derived from the seedphrase via ano= ther hash function, so
there's no real risk of this.

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%2BWRk6JU2xNdh6YYQE9VmkH1kv-CwBSYBxu0C0WocyKwNQ%= 40mail.gmail.com.
--000000000000e136b6064a944cf4--