From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 10 Feb 2026 12:49:33 -0800 Received: from mail-oa1-f60.google.com ([209.85.160.60]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vpufs-00060t-Pg for bitcoindev@gnusha.org; Tue, 10 Feb 2026 12:49:33 -0800 Received: by mail-oa1-f60.google.com with SMTP id 586e51a60fabf-409483fc17asf6450385fac.2 for ; Tue, 10 Feb 2026 12:49:32 -0800 (PST) ARC-Seal: i=3; a=rsa-sha256; t=1770756566; cv=pass; d=google.com; s=arc-20240605; b=NNmUfdtri9C4KlwtnB6ST1CurCAa+YMSO6bYqysV4E6OhrUiiC8eGhT8Z9avAA3WdK NFMfUdgLZmg6l81Ap4YLXol8uTH96OVaBI9MBHp2DLxR/kOcpGq4uS1/c6ReW832qGdp 77Bi86YqUxJ4jXg40LtLFUy80DU33hyVLnF4MCQZz941EFQwZy9gw04DIILuno6rdv0X W5DdajbB3v6R3WnudNzaLs/N/sh3GIRGtK93dXLPdlsJhOo6oOwiYMTvvY1NK0YjE6Jl I1R7HggEW7MkvZvKb2826tj19l2047eSH+IBLUh8OOkAFaOBhGfLJiuUUdrG9t02i2lJ jDhA== 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=4A4nPBzKwxLXCTSmobdauQwlIOU7upERtbrcSUwA+kQ=; fh=U/IaDNbJK1XjrEDlJk5+UOkT6tYZ5eEb1Wc7lbiGxOQ=; b=Fs0NkNPP8MFF+fQAAV1L7FtYb+Z+PUVZa3CHRFzzl80GdrPABuefgD7ffNoqBR6M7U txCqxaM78qA16M4CQVEF4FPRFVvFjiDnVExCbaa/dEgaAdRlFtilK01YFgR7mT4QfY/C X/iIlNGpNa9Ud6Zkx6Dt7C0KGEtO2XrnY1AtMWYwPglgGgXyaYTUEd9udA0r4iQxekpk uKVGQBd/KL6IH6fLnYRUmCnoRyRoPv9DE4yNTg9wcp0rc4YFz/hCafmU3KPhiF4sbApM mgPq0JkC8Iq4NuCBHfVfKvshtvXa4+WZ137WUoHNqcmesbjT6gHC8NAVD989ZvL4qEg4 b7vQ==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b="cdsQ5z/a"; arc=pass (i=1); spf=pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::52b 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=1770756566; x=1771361366; 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=4A4nPBzKwxLXCTSmobdauQwlIOU7upERtbrcSUwA+kQ=; b=slv8zCFbzvZYKELTs+0ZNZv9/19YYtrxy/YxHlraCifd7gSeaoUENS+zq1GTj/0Zij r51rLctg9NkqpUC9jVybEjGD0bpMMj7m5EOZ/31P+k9Pe5U/9qkloAKVpEPcAPVnD2d0 1ovIX9lRXylgx6hX79dl58l/0H1oMNZPXtsEYgjVQAmLuqa0XI+wKE+qZ+EDeIVRkoXg 9VTyTLQMxbCv7PSJRwIShJp1HQdUuUfQSWC01xD4JiN0g0dMkKlstKEn3odzN4G4RX5j 5CL/iHs27T0ALfmWA68gK+9jj9rF//btiEm5AZYzHzaj/bgMawXETcQiDhy2g35AJXCE iR3g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770756566; x=1771361366; 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=4A4nPBzKwxLXCTSmobdauQwlIOU7upERtbrcSUwA+kQ=; b=LacymXgsGTBa2LbYgRcvUlM8GjwiLuar/mzd7BiVTMflxj1tgcJytao7FMsc6Tq8Wp VQVY3iL+ZrKmh44C4jACxMNEbkhi8vgLnEKrQbaDoHF/JPxjU74puoUuqUgG5LmpuTU6 HSV2DwFAxg+kgP2IG/gAdXrEEndGcoEkIfF/jFZWQOP+twb+C0QmCS7wCD8fI4Ozf/dD efDV2JezZl+CeO78u31co9GRCYGi5YY1nMWxIDg/4yRGJ6vP0b70jvFcUm9XxmqWIWzu 5afKFFSy9xA1Zq4Jh9sHmMC7YAeg5NKEQhMGcycE0MdyYnGbF+QIcC85J15HToMzP0OY PJoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770756566; x=1771361366; 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=4A4nPBzKwxLXCTSmobdauQwlIOU7upERtbrcSUwA+kQ=; b=qbvFdEf037NikEXUH5CfZ4fnbjujp/P3cvgrB9Fo0M8PEeQHNfFB3mH/mq3Se54oaN CFGb7f/yFuITBV6KnhOTCUDXRBgWttow9wUeTFzqs66sCIODs+DwC8hVSgs0uoBY6m1h Eg/39EODAkUFFK0BSDUZRKVVD5cwqL/YttlZbjVSmr0QaBOKSco7TivqgWLCVXQneLXG ygnA+CsJZwfs3P5KT9Xti+Q9xh3gFSdKby+7WMT46knSAiQbclvqIqwHPWBBYOlwirMY qPDiY/ZbnmO8wu+vFk2uh5tPBQYrsdjpLdBF2hGg2HOmOd81zBa/Rv7Y39Csmf/0h99e cVAw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AJvYcCUjQwiMbXTRXJjZi8zqyMpIst2ok4XeXJXjbPcKvM8w1NDTiN/1f11HXyVYEyKnpbMz8j8ZBiguKvUz@gnusha.org X-Gm-Message-State: AOJu0Yxn1u7HK/0foW3CEpA9TbLfMLyC6DyuHY4qqXXh+hbIn262AoJX helAX+qhZPQ7S+jagcz2FazGlpAOVVvlVUf4nFGhoPJs3zuvxxR8/eY3 X-Received: by 2002:a05:6871:729:b0:409:965c:5cc4 with SMTP id 586e51a60fabf-40a96caaafemr8853770fac.23.1770756565981; Tue, 10 Feb 2026 12:49:25 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+FbvqRUZlKiGDepHSFGUAnt1zb0VnAC0820pNeeByhMgw==" Received: by 2002:a05:6870:586:b0:3e8:2785:9a19 with SMTP id 586e51a60fabf-40a74d7c164ls4776229fac.1.-pod-prod-08-us; Tue, 10 Feb 2026 12:49:19 -0800 (PST) X-Received: by 2002:a05:6808:10d3:b0:45c:92d9:ca5f with SMTP id 5614622812f47-462fcb1f31cmr7478979b6e.43.1770756559455; Tue, 10 Feb 2026 12:49:19 -0800 (PST) Received: by 2002:a05:6808:31c8:b0:45f:66d:3206 with SMTP id 5614622812f47-462fc4f847bmsb6e; Tue, 10 Feb 2026 08:44:39 -0800 (PST) X-Received: by 2002:a05:6a21:338a:b0:392:e5c4:6959 with SMTP id adf61e73a8af0-393ad02a6d9mr17551345637.36.1770741878138; Tue, 10 Feb 2026 08:44:38 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1770741878; cv=pass; d=google.com; s=arc-20240605; b=TLmak7jvF1QeQIMxf+BEsrwUwLHWFTSMcOWt3/JS6fBCoL61uhFA6tpSgFoPJDda/c 48Tju4/U4PBDY0G4Bkotne83vDJYtvAYkqiKzGAcUS2p1RkD/bTyOoHm4ePERtc6qb12 9sZfEj223fkLa1n1aUs7UodoEXcf59FAW7AbkufkONPcEV6xRGanXYtb95XJGgOwrm6V k0fyVjxl680cpVl9S5fy49nkZeCO+h6HND7D2ODg7SODqILaAkYA/V0E/UnYebx6Zoat BeK9u9HStPHWuyIsV+KkMjBS4ViP4U6Z/kqWzdHMqwoMEQ+9DKWA3X3eYiQXosYwcHF0 ki4Q== 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=Nm6m1p4L7fy78ddWV7TJOYLWAcj703pDBEy4eEzh/FU=; fh=MjdRPwMMqTCvqsS0x8/KiUP5ScpwSKUUuPzaYsRCcYc=; b=T9OXLzyZzra/6BnQVB91/86r9cidz4BFjqcuFZldf0QnjkpELxjI75pIdR7nXijI+L 773BHSq5YLPpx7Ukxg+ielRyoy5NT8ajFNc49O3KQ1k9XUEA0A+lofRc5PlIH7IukYsK 9BV2oNNCQ+ndK+HT0NdXTLcr16wqphGL1aRL0FD2uMJJY8WHMcbZRo9D9Q2v9ETiMYfZ l9iXno4t405vYR8HTuuEDWoseZAkqRPqYBqaWY31OJLox1NlWM6TjqxZfhpBXBOAww2y OROgWeTuNTBgzBaxdt8z/l9qd3v8MaYLfd1uAj9mIDW1Zpv6Mfgoj9wO2D3UcxKPA9lq G7ww==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b="cdsQ5z/a"; arc=pass (i=1); spf=pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::52b 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-x52b.google.com (mail-pg1-x52b.google.com. [2607:f8b0:4864:20::52b]) by gmr-mx.google.com with ESMTPS id 41be03b00d2f7-c6dcb613f65si525186a12.3.2026.02.10.08.44.38 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Feb 2026 08:44:38 -0800 (PST) Received-SPF: pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::52b as permitted sender) client-ip=2607:f8b0:4864:20::52b; Received: by mail-pg1-x52b.google.com with SMTP id 41be03b00d2f7-c6de0527ce1so592090a12.2 for ; Tue, 10 Feb 2026 08:44:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1770741878; cv=none; d=google.com; s=arc-20240605; b=AqzCKkg3DqbUJNPlTR2VIAnmEP1owlSduOBNHm/cU9MHaf0X0gezgpmjAlF45x3nNq Z6uNaj4Gg9uIytL5OtKaJ8P6oPf+Kp95hdGjPS3ZI3Pwig3GbO0u4bspZ5GVopQfryFQ V6wi7zFudJDjOxIWUewb2Y1S2yy1MoSUvGlBb9H4lBgpYHdQWbNl8DLAxofpJiOcgyRq lwa4ZFWZH/LUsLbABVG0ANJVm8CB48/7mOT9ARZiNi8BC50TEVRpGLMx7mZw9IKALlao JdmWKgUfepyHdi/Rdm9Z42K9bG35CV2Pjrk/lBSmqJVN8tavEJloCjxrX5tMl54gxpTL 8J/w== 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=Nm6m1p4L7fy78ddWV7TJOYLWAcj703pDBEy4eEzh/FU=; fh=MjdRPwMMqTCvqsS0x8/KiUP5ScpwSKUUuPzaYsRCcYc=; b=iJejxHgnTUUrCdRhZyFqWSUqPhv1djR+q3/h1RtH2QVszmmaZLWwKPYKHym3dpBdtH qKvkNqi3xknriBWHUEuZ+bxHggliABJ05uRXiAQvTsBALG1Qn1NPUIL1mYRuYhWUPiqE icCgO+aJqPPUfwyQxXwTguwv2iWOXN8q6yHxpkh0HyR2qfIAwdeiRPGeEQBIktsW5RDF ZugesflHz2XRWIU/fyINw9kvZaButUUstZg/jrMRxCXDMui/PvtNUfD03nMwcg0/Pend ZLDiJjHoGO+BUiCJFsjQSGBNtN1lGBLPa1db8Bwejxct1YFx9uJ//6DsOVcMdzpk62yg MYLQ==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Gm-Gg: AZuq6aLxkV8PsKXbm/p4XDu4JH4nd27qSSHAsPzHPQkXdqQjz3gEzHvgQhYqf/rSKEY eGd/d7OFkKEpsJBix7soRndXVQRl15e1//Dw/tdhiyzh/gLoWBIHEL8OUhNod79+FACKjNbep/u B5Kp5RZ0wFtlBd4YmHNGMgf5Z3XjIr1/u04aFKZkQYoNXlC3O1jbAA3Hy7kCrKCWofWhk1N3mTJ MVsMMmymeisUheGG/77YB5o/S4AK2UUGBv8hP4Vw+22Fc7yzD2cwWjVGa2jwFEIZ5kLzZEg8S0u kQ9DURhBTyOnp3gA3GwRr3BTpBbo+SBBVQifkWcGnWyomI1n6c6Jz3rV9647RLhGrS1ONxr1BRt +8qM9L+IXI6wnun21FYYkr0439kcvKIf7I2x9AqnTpMYaNg76S1SL+rhXTQ9prg7vwkkVJgM8AB MnETT3sm83Th8FrUdq+W+VlD4pLQ== X-Received: by 2002:a17:90b:3c47:b0:34a:a65e:e6ad with SMTP id 98e67ed59e1d1-354b3c423d2mr13527008a91.1.1770741877345; Tue, 10 Feb 2026 08:44:37 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ethan Heilman Date: Tue, 10 Feb 2026 11:44:01 -0500 X-Gm-Features: AZwV_Qif4zda8Q5cucT6ZCIaYFwdU6nlgP8HkUcIvPnMEzbT8VKWR8E9XD2bRMI 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: Jonas Nick Cc: bitcoindev@googlegroups.com Content-Type: multipart/alternative; boundary="00000000000096934d064a7af87c" 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="cdsQ5z/a"; arc=pass (i=1); spf=pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::52b 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 (/) --00000000000096934d064a7af87c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Appreciate your feedback on this proposal, Jonas > I agree that reusing an already standardized scheme like SLH-DSA has the real benefit of building on an existing ecosystem and allowing for faster deployment. The downside is that SLH-DSA is less efficient for Bitcoin than alternative hash-based signatures. I want to introduce some new terminology here: Everyday signature algorithms: These are the signature algorithms users employ for daily transactions. Backup signature algorithms: These are signature algorithms used to migrate from a broken everyday signature algorithm to new everyday signature algorithm. I agree that for the everyday signatures we need something much smaller than SLH_DSA's 8kb signature. If we expect everyday signature algorithms to weaken at a rate requiring replacement every 40 years, backup signatures will represent a very small fraction of Bitcoin signatures, making their size less important. Even then, if a break in a everyday signature algorithm is not unexpected, we can use everyday signatures to make the transition to the new everyday signature algorithm. The most likely use for backup signatures is for someone who stored their BTC in an output for 50 years, didn't move their coins when the everyday signature algorithm was weakened, and then didn't move their coins when it was completely broken. Say someone who put their coins in a safety deposit box, got sick, died and their estate now wants to safely move the coins. They would use the backup signature to move to a new output because there is no other safe option. > Those costs are therefore a more binding design constraint than ecosystem support, which can be built up over time through focused effort. I agree with you here, as long as we constrain ourselves to everyday signature algorithms. Backup signatures should optimize for security and standardness. > 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. 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 after activation. > 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 from 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 the 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. 2. P2TRD (Pay-to-Tap-Root-Disablable) to be non-confiscatory users 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 script spend on the blockchain. 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 spend, a user might not realize if they lost the keying material for their script spend until after activation. Hazard 2 and 3 make harzard 1 worse by making the Q-day soft-fork to disable key spends in P2TRD more controversial. Imagine a giant custodian finds out all their coins are burned after the soft fork activates, they might bribe miners to unactivate the soft fork to give a chance to move the coins. That probably won't happen but why take the risk? Signaling a willingness to take unnecessary risks could also harm Bitcoin's credibility= . Additionally, by only having script path spends in BIP 360, wallets who want to claim to use BIP 360 support must actually build script spend support. Users will know that their script spends work because they are actively using them. BIP 360 +SLH_DSA solves problem 1 by never allowing key path spends in BIP 360 outputs. This allows us to reach quantum safety without having to predict Q-Day. This also allows Bitcoin to demonstrate it is quantum safe, rather than the hopes of quantum-safety depend on an uncertain future soft fork. This settles the safety issue early, removing the risk of a Q-day soft fork disaster and calming fears about such an event. On Tue, Feb 10, 2026 at 4:11=E2=80=AFAM Jonas Nick = wrote: > Hi Ethan, > > Thanks for the thoughts. A few comments on the specifics follow. > > > I prefer SLH_DSA because it is likely to be well supported outside of > Bitcoin > > and Bitcoin can benefit from this ecosystem of support in the form of > HSMs, > > hardware acceleration and software liberties. > > I agree that reusing an already standardized scheme like SLH-DSA has the > real > benefit of building on an existing ecosystem and allowing for faster > deployment. > The downside is that SLH-DSA is less efficient for Bitcoin than alternati= ve > hash-based signatures. > > If this is not intended to be a short-term solution, efficiency > considerations > (e.g., ~50% smaller signatures) likely outweigh the benefits of an > established > ecosystem. While the Bitcoin space does have the ability to standardize n= ew > efficient schemes and invest in software libraries and custom HSM support= , > the > verification resource constraints of the entire Bitcoin network are much > harder > to influence. Those costs are therefore a more binding design constraint > than > ecosystem support, which can be built up over time through focused effort= . > > > Q: Couldn=E2=80=99t you do this without BIP 360 by using Taproot inste= ad and > then > > disabling the taproot key spend path? > > A: Yes, however this would be confiscatory, since Taproot allows key > spend > > path only outputs. > > If Bitcoin disables Taproot key path spends before Q-day, then doing this > via > Taproot instead of BIP 360 would be preferable. It would allow users to > benefit > from Taproot's efficiency and privacy properties until key path spends ar= e > disabled. > > There's also an alternative that Matt Corallo mentioned to me recently > which I > haven't seen discussed on the mailing list. 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, thi= s > 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). > > -- > 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/bitcoindev/ea3a12db-e3fd-44b2-a22c-b960= ed7ec6d3%40gmail.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/= CAEM%3Dy%2BU_PV7dA5Azr7D4Rnr40QaHKUrxdLmx0zPPjYoE-HZ%3DHw%40mail.gmail.com. --00000000000096934d064a7af87c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Appreciate your feedback on this proposal, Jonas

&g= t;=C2=A0 I agree that reusing an already standardized scheme like SLH-DSA has the re= al benefit of building on an existing ecosystem and allowing for faster dep= loyment.=C2=A0The downside is that SLH-DSA is less efficient for Bitcoin th= an alternative=C2=A0hash-based signatures.

I want to introduce some = new terminology here:

Everyday signature algorithms: These are the s= ignature algorithms users employ for daily transactions.
Backup signatur= e algorithms: These are signature algorithms used to migrate from a broken = everyday signature algorithm to new everyday signature algorithm.

I = agree that for the everyday signatures we need something much smaller than = SLH_DSA's 8kb signature. If we expect everyday signature algorithms to = weaken at a rate requiring replacement every 40 years, backup signatures wi= ll represent a very small fraction of Bitcoin signatures, making their size= less important. Even then, if a break in a everyday signature algorithm is= not unexpected, we can use everyday signatures to make the transition to t= he new everyday signature algorithm.

The most likely use for backup= signatures is for someone who stored their BTC in an output for 50 years, = didn't move their coins when the everyday signature algorithm was weake= ned, and then didn't move their coins when it was completely broken. Sa= y someone who put their coins in a safety deposit box, got sick, died and t= heir estate now wants to safely move the coins. They would use the backup s= ignature to move to a new output because there is no other safe option.
=
>=C2=A0 Those costs are therefore a more binding design constraint than=C2=A0ecosys= tem support, which can be built up over time through focused effort.
I agree with you here, as long as we constrain ourselves to everyday signa= ture algorithms. Backup signatures should optimize for security and standar= dness.

>=C2=A0 If Bitcoin disables Taproot key path spends before Q-day, then doing this v= ia=C2=A0Taproot instead of BIP 360 would be preferable.

I worry abou= t making the transition to quantum-safe outputs depend on a contentious deb= ate over a confiscatory soft fork. Uncertainty over whether the soft fork w= ould be released and if released would be activated means that wallets and = custodians are unlikely to have invested the resources into upgrading to su= pport script only P2TR.

The benefit of BIP 360's P2MR (Pay-to-Me= rkle-Root)=C2=A0+ SLH_DSA is that it avoids this controversy by being opt-i= n and non-confiscatory. This also means that BIP 360=C2=A0 + SLH_DSA is likely to activated early, allowing wallets and custodians amp= le time to build support after activation.

>=C2=A0 We could define a new SegWit version that is a copy of Taproot. The new ver= sion number simply signals that the owner=C2=A0consents to a future deactiv= ation of key path spends. Unlike BIP 360, this
approach would still requ= ire actually disabling the key path before Q-day, but=C2=A0it is not confis= catory and allows using Taproot's benefits until then (with a=C2=A0priv= acy hit from having two versions of Taproot in parallel).

Let's = call this=C2=A0 P2TRD (Pay-to-Tap-Root-Disablable). BIP 360 evolved from this P2TRD idea, t= o minimize the following hazards in P2TRD.

1.=C2=A0 P2TRD requires a= =C2=A0soft fork that depends on accurately predicting Q-day or when EC Schn= orr is classically broken. We must not only predict Q-day but also convince= the community that the prediction is correct. If we mess up the timing, Bi= tcoin is significantly harmed. This means that people will constantly be ye= lling that we are messing up the timing. It will make quantum FUD worse not= better.

2.=C2=A0 P2TRD (Pay-to-Tap-Root-Disablable) to be non-confi= scatory users must create a script spend that replicates their key spend, B= ut users and wallets are likely to screw this up and not create script spen= ds. The is no way to see if a wallet is actually creating the script spend = on the blockchain.

3. To be safe from long-exposure attacks P2TRD ca= n't use the same public key for the script spend as the key spend. Sinc= e wallets will prefer the key spend to the script spend, a user might not r= ealize if they lost the keying material for their script spend until after = activation.

Hazard 2 and 3 make harzard 1 worse by making the Q-day = soft-fork to disable key spends in P2TRD more controversial. Imagine a gian= t custodian finds out all their coins are burned after the soft fork activa= tes, they might bribe miners to unactivate the soft fork to give a chance t= o move the coins.=C2=A0 That probably won't happen but why take the ris= k?=C2=A0Signaling a willingness to take unnecessary risks could also harm B= itcoin's credibility.

Additionally, by only having s= cript path spends in BIP 360, wallets who want to claim to use BIP 360 supp= ort must actually build script spend support. Users will know that their sc= ript spends work because they are actively using them.=C2=A0=C2=A0

B= IP 360 +SLH_DSA solves problem 1 by never allowing key path spends in BIP 3= 60 outputs. This allows us to reach quantum safety without having to predic= t Q-Day. This also allows Bitcoin to demonstrate it is quantum safe, rather= than the hopes of=C2=A0q= uantum-safety=C2=A0depend on an uncertain future soft fork. This set= tles the safety issue early, removing the risk of a Q-day soft fork disaste= r and calming fears about such an event.






<= /div>
On Tue, Feb 10, 2026 at 4:11=E2=80=AFAM Jonas Nick <= ;jonasd.nick@gmail.com> wro= te:
Hi Ethan,
Thanks for the thoughts. A few comments on the specifics follow.

=C2=A0> I prefer SLH_DSA because it is likely to be well supported outsi= de of Bitcoin
=C2=A0> and Bitcoin can benefit from this ecosystem of support in the fo= rm of HSMs,
=C2=A0> hardware acceleration and software liberties.

I agree that reusing an already standardized scheme like SLH-DSA has the re= al
benefit of building on an existing ecosystem and allowing for faster deploy= ment.
The downside is that SLH-DSA is less efficient for Bitcoin than alternative=
hash-based signatures.

If this is not intended to be a short-term solution, efficiency considerati= ons
(e.g., ~50% smaller signatures) likely outweigh the benefits of an establis= hed
ecosystem. While the Bitcoin space does have the ability to standardize new=
efficient schemes and invest in software libraries and custom HSM support, = the
verification resource constraints of the entire Bitcoin network are much ha= rder
to influence. Those costs are therefore a more binding design constraint th= an
ecosystem support, which can be built up over time through focused effort.<= br>
=C2=A0> Q: Couldn=E2=80=99t you do this without BIP 360 by using Taproot= instead and then
=C2=A0> disabling the taproot key spend path?
=C2=A0> A: Yes, however this would be confiscatory, since Taproot allows= key spend
=C2=A0> path only outputs.

If Bitcoin disables Taproot key path spends before Q-day, then doing this v= ia
Taproot instead of BIP 360 would be preferable. It would allow users to ben= efit
from Taproot's efficiency and privacy properties until key path spends = are
disabled.

There's also an alternative that Matt Corallo mentioned to me recently = which I
haven't seen discussed on the mailing list. We could define a new SegWi= t version
that is a copy of Taproot. The new version number simply signals that the o= wner
consents to a future deactivation of key path spends. Unlike BIP 360, this<= br> 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).

--
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 bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/ea3a12d= b-e3fd-44b2-a22c-b960ed7ec6d3%40gmail.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.co= m/d/msgid/bitcoindev/CAEM%3Dy%2BU_PV7dA5Azr7D4Rnr40QaHKUrxdLmx0zPPjYoE-HZ%3= DHw%40mail.gmail.com.
--00000000000096934d064a7af87c--