From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 10 Feb 2026 15:25:57 -0800 Received: from mail-oa1-f56.google.com ([209.85.160.56]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vpx7D-00037O-PU for bitcoindev@gnusha.org; Tue, 10 Feb 2026 15:25:57 -0800 Received: by mail-oa1-f56.google.com with SMTP id 586e51a60fabf-40414b6f18dsf6177293fac.3 for ; Tue, 10 Feb 2026 15:25:55 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1770765950; cv=pass; d=google.com; s=arc-20240605; b=ex2Z5BBnfKqi5mTSYSTSAoPaDbfypICgBczyalegMnBczPK9pxUjWLGWrHdcO3P+HV O6gGeXEKfP29RiYm0G4ujPIIEZ8JEM1VF4GUg9z47EsMlJSzxITUBXx5lts3M/UAm+xk a4rbKkIW1rSY+Oq5JzrkfHbROert3pgHZ1IXV6gP9BBP/8rZt2ZAJBWsWAhOyPbbqC8F Gkh8J8MgTSJHkSoi2Q3SgNiHEoRqItpUyxm1jiaPWtyWTALbOyIhrhMfcfXMiAlg0SEY YSTj7D4Rm6OjrQdARZ/UFdDeMfJ6vfazEAjpvmo3vMzJO10jzNMJzEqcL284Z1Xz6Xk0 yNZQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:mime-version:subject :references:in-reply-to:message-id:cc:to:from:date:dkim-signature; bh=85K1dI3Ry1/9tG4dEYwPsv2043r+MssG4nLsO1VDRxo=; fh=lp9/QzFoIqvWg0FFOy6y42qg5E0DkwtNq88WeaEVLZo=; b=b/Vl+EUr7ZHtM75SUO5QbQRyH6P3qNwVDUv7B6JhbzRBt7hdikfpHRk+0O/83/tQrI O0NWI5zVsSvKmH16XNsC7iTcalrmzeiXMfaVowflMI+R4n429fRPv9SVzoTF3XMx34vp YfgZvoP9Y/wRyNaNSJIDMSQ8GKlu73iPVez60N6+3DL23TSQwlV/EpS5SvM++XWnr9im EgwLM66XALl7/dqdpAsENtec3A1rjNEtNpUD0tDDGS9L1kwQVPADs2xiE42/5Os8tA3X fjYI8ScGodM9q1e3v0bDxrsBoGSnY32BWposjGsJpzT0rC3YmpWjiFdmlAKkm8/191l1 Ol9g==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@reardencode.com header.s=mail header.b=eHk9VedA; spf=pass (google.com: domain of freedom@reardencode.com designates 206.125.169.165 as permitted sender) smtp.mailfrom=freedom@reardencode.com; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=reardencode.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1770765950; x=1771370750; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :subject:references:in-reply-to:message-id:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=85K1dI3Ry1/9tG4dEYwPsv2043r+MssG4nLsO1VDRxo=; b=lT7rLNPJjUGRlMpaxCAYbfBONxAGI96rIXUsjhDjBqxqcpF3aHPOxc8+i8M3dsX8Pu sjkaRKiERV4S1loLV0S5QL0ogUVq6C3fxW8ZhbCBOiZ+GqC6d59wpSKad58CBico9k40 tb8hm5knIharDxiT+HWE7ztGM9DFuQ4ZZtywjpDYa2Wjn/1R6Emu5qUomALOBYyrnt9x oihjLAHMqGVfAC3PKk6VKpY1hidee9YsH8P4YH0ogaY+jwHVy3+/fUgUZTzH9esd2Uub GW4WLARX4tK1+MllYpRiSSbA8SwNyohp4HrfA+6XR/ogbH4EPyOUY2iCTBED0sS1bwO+ DCfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770765950; x=1771370750; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :subject:references:in-reply-to:message-id:cc:to:from:date :x-beenthere:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=85K1dI3Ry1/9tG4dEYwPsv2043r+MssG4nLsO1VDRxo=; b=m+zyQ6jYmx/daIeJ9JLgDE3J8dsjXrF63DcupR+jusqfbCkxgoVqn6VgzF16YrjPeT xYV5y8VlzaChYb7nMbgLCcsPj8CE7wXcF7m1ClJjy8lgf1+lbkxqYuxFGTIBFs+THqal 8nSmBFvGd+kj6zqtx19ql6he7jlI45njU/ZQXxYdu6TkdylNzaQIt0rf29b/jIHO7UbR x8tjFEHfCOVd9TpCnRf9HhVmj+mtSo3nXK1fhiUbaMFECI1OGdizGwGt1MsybcD8437R 241u1vsgH38JypMy/wEEoJuaSAULhze6CYT4HVA26nfCGBTfafYadTpb5vXf15YF0R3R deOA== X-Forwarded-Encrypted: i=2; AJvYcCXIpqyKOy2k/4lxztIJUBT+///UPFdaN7u1ZPzaMZcg4WvGNO+M9iSlrUaAw5/eAj8/W6SMlDo16xDF@gnusha.org X-Gm-Message-State: AOJu0YzJLCrv6iTlxEh6TICVAn6XMs58UBWtbX8IqNYAU/HHjCfu+zkM KMPeSB45DEI0X8dfOq13e0U4IBpQGVAU+pxx1nxRXJZ/nkkiFYLvzHPf X-Received: by 2002:a05:6870:844c:b0:409:8473:d76 with SMTP id 586e51a60fabf-40a96c97e91mr7880898fac.18.1770765949305; Tue, 10 Feb 2026 15:25:49 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+GQmhD7RX7TL+svMVLsE/CsjHSAXGKYYnwppY5ZEquW5w==" Received: by 2002:a05:6870:586:b0:3e8:2785:9a19 with SMTP id 586e51a60fabf-40a74d7c164ls4845995fac.1.-pod-prod-08-us; Tue, 10 Feb 2026 15:25:45 -0800 (PST) X-Received: by 2002:a05:6808:c1f1:b0:45e:c2a7:9151 with SMTP id 5614622812f47-462fcb7284fmr8672908b6e.51.1770765945608; Tue, 10 Feb 2026 15:25:45 -0800 (PST) Received: by 2002:a05:6504:1b8d:b0:2d1:a602:e60f with SMTP id a1c4a302cd1d6-2e5637c39c2msc7a; Tue, 10 Feb 2026 13:51:40 -0800 (PST) X-Received: by 2002:a2e:a586:0:b0:386:ac5d:d150 with SMTP id 38308e7fff4ca-386ef087016mr13516611fa.34.1770760297709; Tue, 10 Feb 2026 13:51:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1770760297; cv=none; d=google.com; s=arc-20240605; b=lIZrCJS8XiMybJmK5zbdbPFy9RbUxHamxuWYe6Q2OapPafAdSKOXEbPjWobhnDmfow L4Bg8UWnOSl35JEEU6tIv4NhgOnZ+vaNScqa0V2JdE13lASRW0S5RVtBtyoIEOZh117h LqGnEm7FF2/hXF0GALireZsFS0K34nzKFQFaXTnYXQLRcF8N8EYzVD07APbP3Jj0jvyS 6AoKq5gOzoeMXbbEetYErU6kopRvm/D92htMUUU4XLnQ99ZeYI7meBDAv8P7zAhwxYOh ys6ORWWbA0bfzkUSyLwtEExcnaWMgSUaq7xd3N9qZkdvHcwomWw8QolTuw0IL8tMrfWu IY2g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=mime-version:subject:references:in-reply-to:message-id:cc:to:from :dkim-signature:date; bh=ZccaQehjVCLxs0CCI+kMFnjjXe6WS/XGzAqiaOd6WIk=; fh=MhNL3lrwfbsRO5DJHn9ZZ/LeA3+mAuX0vCziGEghh6s=; b=GxzG8F02BUYzAcQrwICP1C6DkZXqx5XwSH8RNXh+WGt84y0c8fHnVGl8NSC9B0AR78 GMAVGAlS4YryFRdiibDXrDgR4UBkPBTGaG38Rld0ITDodSq1nfMGHThfnuFllBHEkDFG tGOn04BVe/0X6nRTE4t/qrxApIC6oxd1A4E+semBIHwRipmhI8Pp4F527SDWduCNFSa5 VwkmRK/iyRLz1n9ZsyvA5qtNETyTy3HmWtAyjaDw0ZXo1L5FkymGMHMaOnLKNryLqRoL QEeXQjJS0li+NSaQX3kQ2/CqynhvrGE9Q48R95d8PpN+prDyE2HdBywGwRfM8FrPNhrn oPvw==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@reardencode.com header.s=mail header.b=eHk9VedA; spf=pass (google.com: domain of freedom@reardencode.com designates 206.125.169.165 as permitted sender) smtp.mailfrom=freedom@reardencode.com; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=reardencode.com Received: from mail.reardencode.com (mail.reardencode.com. [206.125.169.165]) by gmr-mx.google.com with ESMTPS id 38308e7fff4ca-38704f946b2si19181fa.3.2026.02.10.13.51.36 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Feb 2026 13:51:37 -0800 (PST) Received-SPF: pass (google.com: domain of freedom@reardencode.com designates 206.125.169.165 as permitted sender) client-ip=206.125.169.165; Date: Tue, 10 Feb 2026 13:51:30 -0800 From: "'Brandon Black' via Bitcoin Development Mailing List" To: Ethan Heilman Cc: Bitcoin Development Mailing List Message-ID: In-Reply-To: References: Subject: Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_8_179781947.1770760290371" X-Correlation-ID: X-Original-Sender: freedom@reardencode.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@reardencode.com header.s=mail header.b=eHk9VedA; spf=pass (google.com: domain of freedom@reardencode.com designates 206.125.169.165 as permitted sender) smtp.mailfrom=freedom@reardencode.com; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=reardencode.com X-Original-From: Brandon Black Reply-To: Brandon Black Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -1.0 (-) ------=_Part_8_179781947.1770760290371 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for posting this. What are your thoughts on the alternative mechanism of deploying GSR or sim= ilar in BIP360 and then letting folks build their own DSA2 which can then c= hange over time without additional forks. Most of these would never be spen= t from anyway, and this seems like a dominant approach for DSA2. Sipa pointed out to me on an Optech podcast that this approach is inappropr= iate for DSA1/3 because there are strictly need a vetted ecosystem for regu= lar spends, lightning, aggregation, etc. Best, --Brandon, sent by an Android Feb 9, 2026 07:40:47 Ethan Heilman : > Howdy list, I want to share my thoughts on increasing the security of Bit= coin to long term threats such as quantum and classical breaks in Bitcoin= =E2=80=99s signature algorithms by adding algorithm agility mechanisms to B= itcoin. To quote _RFC 7696: Guidelines for Cryptographic Algorithm Agility[= https://datatracker.ietf.org/doc/html/rfc7696]_: >=20 > =E2=80=9CProtocol designers need to assume that advances in computing pow= er or advances in cryptoanalytic techniques will eventually make any algori= thm obsolete.=C2=A0 For this reason, protocols need mechanisms=C2=A0 to mig= rate from one algorithm suite to another over time. >=20 > Algorithm agility is achieved when a protocol can easily migrate from one= algorithm suite to another more desirable one, over time.=E2=80=9D >=20 > I propose introducing a very secure post-quantum signature algorithm to b= e used alongside the current algorithms. This signature algorithm can be ve= ry expensive in txn fees and block space since it is for emergency migratio= ns only. This enables Bitcoin holders to cheaply and easily create outputs = that =E2=80=9Cfailsafe=E2=80=9D even against=C2=A0 an unexpected break in a= signature algorithm. >=20 > Motivation > =3D=3D=3D=3D > =C2=A0 > Bitcoin should enable a person to self-custody coins for at least one hum= an lifetime, ~75 years. Someone should be able to bury an HD Seed in a coff= ee can and then dig it up in 75 years and spend those coins. No store of va= lue can promise complete safety on long timescales, but the trust we build = by demonstrating that Bitcoin is serious about mitigating long-term low pro= bability risks. Trust and credibility is built when the risk we defended ag= ainst never happens. >=20 > The main risk I will be considering here is the loss of the ability to au= thenticate ownership of coins resulting from a break in a digital signature= algorithm used by Bitcoin. Such risks are extremely unlikely in the short = term (1 to 5 years), but become more likely on 5 to 75 year timescales. Mos= t of the focus in the wider cryptocurrency world has been on mitigating the= quantum threat, but I take a less narrow view of the problem. We should co= nsider not just Quantum attacks on Bitcoin=E2=80=99s signature algorithms a= nd also classical breaks that do not require a quantum computer. One partic= ular area of concern to me is an unexpected breakthrough in Mathematics dri= ven by AI approaches. > To address these risks we propose the following design for protecting hol= ders even against an unexpected break in Bitcoin=E2=80=99s signature algori= thms quantum or otherwise. > Design > =3D=3D=3D=3D > Assume that Bitcoin supported two digital signature algorithms: DSA1 and = DSA2. Each signature scheme would have its own CHECKSIG opcode, CHECKSIG_DS= A1 and CHECKSIG_DSA2. >=20 > Using BIP 360, we could have a leaf script for CHECKSIG_DSA1 and a leaf s= cript for CHECKSIG_DSA2. >=20 > Leaf1: DSA1_PUBKEY, CHECKSIG_DSA1 > Leaf2: DSA2_PUBKEY, CHECKSIG_DSA2 >=20 > If DSA1 was broken, users could simply switch to spending the output with= DSA2 signatures by using leaf2. An attacker that could break DSA1, wouldn= =E2=80=99t be able to learn the public key for DSA1, and thus wouldn=E2=80= =99t be able to spend DSA1, despite DSA1 being vulnerable. >=20 > This approach makes the assumption that the user has not leaked their pub= lic key to an attacker or reused their public keys. As a user wishing to ho= ld Bitcoin in an output over long periods of time generate a fresh set of p= ublic keys for that output. >=20 > Our approach does not defend against the case where DSA1 and DSA2 are bro= ken at the same time. For this reason, DSA1 and DSA2 should use different c= ryptographic assumptions. Additionally DSA2 should use a signature scheme t= hat trades off efficiency for additional security and robustness. This way,= we can get the best of both worlds, DSA1 can be used for everyday signatur= es and if DSA1 is broken, DSA2 can be used to migrate to a new signature sc= heme, say DSA3. Even if DSA3, chosen in haste to replace DSA1, is also foun= d to be weak, holders are still protected. This is because DSA2 is unbroken= , allowing us to replace DSA3 with DSA4. >=20 > DSA1 - Efficient, low cost to use, should support nice-to-have features s= uch as aggregation. > DSA2 - Expensive, extreme levels of security, only used to transition to = new signature schemes. >=20 > A person with an HD seed buried in a coffee can for 75 years is still saf= e even if they don=E2=80=99t transition from DSA1 to DSA3 and since DSA2 is= still safe. When they dig it up, they can use DSA2 to move the output to D= SA3+DSA2. >=20 > Given this framework, let=E2=80=99s think about DSA1 and DSA2 with concre= te algorithms: >=20 > - DSA1 is Schnorr, the currently supported Schnorr signature algorithmin = Bitcoin. > - DSA2 is SLH-DSA (SPHINCS+ SLH-DSA-SHA2-128s). SLH-DSA is a hash based s= ignature algorithm. Hash based signatures are the most likely secure long t= erm. >=20 > If we merged BIP 360 and support for a SLH-DSA CHECKSIG opcode, holders c= ould hedge against a classical or quantum attack against Schnorr, while sti= ll using Schnorr. >=20 > Our approach mitigates the main drawback of the size of SLH-DSA signature= s, their size. SLH-DSA signatures are 8 KB in size, while [0] explores meth= ods for reducing the size of these signatures to 3 KB, 3 KB is still huge. = Because SLH-DSA signatures would not have any additional discount, they wou= ld be very expensive in transaction fees, and only economically worthwhile = to migrate from Schnorr to a new signature scheme. In all other cases the a= ddition of SLH-DSA would exist as unused leaf scripts in the output, which = increases the witness by 32 bytes. >=20 > An additional benefit to this approach of using BIP 360 and SLH-DSA would= be to buy time for non-hash based PQ signature schemes to mature. We are s= eeing rapid advances in research on post-quantum signature schemes and wait= ing a little long might buy us a lot. SLH-DSA would provide an effective he= dge against this risk, while delaying the decision of what PQ signature sch= eme should replace Schnorr in the event of Schnorr's security being weakene= d. >=20 > Q & A > =3D=3D=3D=3D >=20 > Q: Could these signatures be abused to store JPEGs on the blockchain? > A: No because they would have no additional discount. This means they wou= ld have no advantage for JPEGs over what is currently possible. >=20 > Q: Why not use XMSS or Lamport signatures instead of SLH_DSA? > A: 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. That said, it is rea= sonable to consider stateful hash based signature schemes like XMSS, Winter= nitz, or Lamport signatures as the fallback signature, especially if size b= ecomes a concern. >=20 > Q: What non-consensus critical changes would be needed to support this? > A; We=E2=80=99d need to create new wallet standards to provide alternativ= es to BIP32 xpubs. Wallet would have to write code to generate SLH-DSA keys= and create a script tree per signature alg. Wallets would also have to put= into place mechanisms to warn for and prevent public key reuse. >=20 > Q: What consensus critical changes would be needed to support this? > A: We=E2=80=99d need to merge something like BIP 360 and then a new CHECK= SIG opcode for SLH_DSA. >=20 > Q: Couldn=E2=80=99t you do this without BIP 360 by using Taproot instead = and then disabling the taproot key spend path? > A: Yes, however this would be confiscatory, since Taproot allows key spen= d path only outputs. People holding key spend path-only Taproot outputs wou= ld have the coins in those outputs destroyed. BIP 360, in essence is Taproo= t, without the key spend path. BIP 360 provides the same functionality as d= isabling Taproot key spend paths, but rather than being confiscatory, it is= opt in. >=20 > Q: Are you proposing this now because you think that the Bitcoin signatur= e algorithms are under threat? > A: No, I am confident in the Bitcoin signature algorithms and I know of n= o immediate threats. This effort is motivated by longtermism and thinking a= bout how to enable Bitcoin to be safe on timescales of decades or centuries= . >=20 > [0]: Mikhail Kudinov, Jonas Nick, Hash-based Signature Schemes for Bitcoi= n (2025) _https://eprint.iacr.org/2025/2203_ >=20 > I want to acknowledge conduition=E2=80=99s feedback and suggestions on th= is email, including the sentence about xpubs. The ideas above resulted from= conversations between myself, Hunter and Isabel. Similar ideas have been s= uggested on the list before. I make no claims of originality, I am organizi= ng these ideas and my thoughts on them into a concrete design. All errors a= re my own.=C2=A0=C2=A0 >=20 > Thanks, > Ethan >=20 > --=20 > You received this message because you are subscribed to the Google Groups= "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an= email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit https://groups.google.com/d/msgid/bitcoinde= v/CAEM%3Dy%2BWTqe8%3DuqChu2vN3HruiJCvFcDMNP%2BJA0AwyOkaR%3Dz0Cw%40mail.gmai= l.com[https://groups.google.com/d/msgid/bitcoindev/CAEM%3Dy%2BWTqe8%3DuqChu= 2vN3HruiJCvFcDMNP%2BJA0AwyOkaR%3Dz0Cw%40mail.gmail.com?utm_medium=3Demail&u= tm_source=3Dfooter]. --=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/= af3369ef-7390-4695-ad6e-899a6ac8b700%40reardencode.com. ------=_Part_8_179781947.1770760290371 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for pos= ting this.

What are y= our thoughts on the alternative mechanism of deploying GSR or similar in BI= P360 and then letting folks build their own DSA2 which can then change over= time without additional forks. Most of these would never be spent from any= way, and this seems like a dominant approach for DSA2.

Sipa point= ed out to me on an Optech podcast that this approach is inappropriate for D= SA1/3 because there are strictly need a vetted ecosystem for regular spends= , lightning, aggregation, etc.

Best,
--Brandon, se= nt by an Android

Feb 9, 2026 07:40:47 Ethan Heilman <eth3rs@gmail.com>:

Howdy list, I want to share my thoughts on increasing the security of Bi= tcoin to long term threats such as quantum and classical breaks in Bitcoin= =E2=80=99s signature algorithms by adding algorithm agility mechanisms to B= itcoin. To quote RFC 7696: Guidelines = for Cryptographic Algorithm Agility:

=E2=80=9CProtoc= ol designers need to assume that advances in computing power or advances in= cryptoanalytic techniques will eventually make any algorithm obsolete.&nbs= p; For this reason, protocols need mechanisms  to migrate from one alg= orithm suite to another over time.


Algorithm agility is achieved when a protocol can easily migrate = from one algorithm suite to another more desirable one, over time.=E2=80=9D=


I propose introducing a very secure post-quantum signature algori= thm to be used alongside the current algorithms. This signature algorithm c= an be very expensive in txn fees and block space since it is for emergency = migrations only. This enables Bitcoin holders to cheaply and easily create = outputs that =E2=80=9Cfailsafe=E2=80=9D even against  an unexpected br= eak in a signature algorithm.

Motivation
=3D=3D= =3D=3D

 

Bitcoin should enable a person to self-custody coins for at least one hu= man lifetime, ~75 years. Someone should be able to bury an HD Seed in a cof= fee can and then dig it up in 75 years and spend those coins. No store of v= alue can promise complete safety on long timescales, but the trust we build= by demonstrating that Bitcoin is serious about mitigating long-term low pr= obability risks. Trust and credibility is built when the risk we defended a= gainst never happens.

The main risk I will be considering here is the loss of the ability to a= uthenticate ownership of coins resulting from a break in a digital signatur= e algorithm used by Bitcoin. Such risks are extremely unlikely in the short= term (1 to 5 years), but become more likely on 5 to 75 year timescales. Mo= st of the focus in the wider cryptocurrency world has been on mitigating th= e quantum threat, but I take a less narrow view of the problem. We should c= onsider not just Quantum attacks on Bitcoin=E2=80=99s signature algorithms = and also classical breaks that do not require a quantum computer. One parti= cular area of concern to me is an unexpected breakthrough in Mathematics dr= iven by AI approaches.
 To address these = risks we propose the following design for protecting holders even against a= n unexpected break in Bitcoin=E2=80=99s signature algorithms quantum or oth= erwise.
Design
=3D=3D=3D=3D

Assume that Bitcoin supported two digital signature algorithms: DSA1 and= DSA2. Each signature scheme would have its own CHECKSIG opcode, CHECKSIG_D= SA1 and CHECKSIG_DSA2.

Using BIP 360, we could have a leaf = script for CHECKSIG_DSA1 and a leaf script for CHECKSIG_DSA2.
=
= Leaf1: DSA1_PUBKEY, CHECKSIG_DSA1
Leaf2: DSA2_PUBKEY, CHECKSIG_= DSA2

If DSA1 was broken, users could simply switch to spending the output wit= h DSA2 signatures by using leaf2. An attacker that could break DSA1, wouldn= =E2=80=99t be able to learn the public key for DSA1, and thus wouldn=E2=80= =99t be able to spend DSA1, despite DSA1 being vulnerable.


This approach makes the assumption that the user has not leaked their pu= blic key to an attacker or reused their public keys. As a user wishing to h= old Bitcoin in an output over long periods of time generate a fresh set of = public keys for that output.


Our approach does not defend against the case where DSA1 and DSA2= are broken at the same time. For this reason, DSA1 and DSA2 should use dif= ferent cryptographic assumptions. Additionally DSA2 should use a signature = scheme that trades off efficiency for additional security and robustness. T= his way, we can get the best of both worlds, DSA1 can be used for everyday = signatures and if DSA1 is broken, DSA2 can be used to migrate to a new sign= ature scheme, say DSA3. Even if DSA3, chosen in haste to replace DSA1, is a= lso found to be weak, holders are still protected. This is because DSA2 is = unbroken, allowing us to replace DSA3 with DSA4.

DSA1 - E= fficient, low cost to use, should support nice-to-have features such as agg= regation.

DSA2 - Expensive, extreme levels of security, only used to transition to= new signature schemes.


A person with an HD seed buried in a coffee can for 75 years is s= till safe even if they don=E2=80=99t transition from DSA1 to DSA3 and since= DSA2 is still safe. When they dig it up, they can use DSA2 to move the out= put to DSA3+DSA2.


Given this framework, let=E2=80=99s think about DSA1 and DSA2 with concr= ete algorithms:

- DSA1 is Schnorr, the currently supported= Schnorr signature algorithmin Bitcoin.

- DSA2 is SLH-DSA (SPHINCS+ SLH-DSA-SHA2-128s). SLH-DSA is a hash based = signature algorithm. Hash based signatures are the most likely secure long = term.

If we merged BIP 360 and support for a SLH-DSA CHECKS= IG opcode, holders could hedge against a classical or quantum attack agains= t Schnorr, while still using Schnorr.

Our approach mitigates the main drawback of the size of SLH-DSA signatur= es, their size. SLH-DSA signatures are 8 KB in size, while [0] explores met= hods for reducing the size of these signatures to 3 KB, 3 KB is still huge.= Because SLH-DSA signatures would not have any additional discount, they wo= uld be very expensive in transaction fees, and only economically worthwhile= to migrate from Schnorr to a new signature scheme. In all other cases the = addition of SLH-DSA would exist as unused leaf scripts in the output, which= increases the witness by 32 bytes.

An additional benefit t= o this approach of using BIP 360 and SLH-DSA would be to buy time for non-h= ash based PQ signature schemes to mature. We are seeing rapid advances in r= esearch on post-quantum signature schemes and waiting a little long might b= uy us a lot. SLH-DSA would provide an effective hedge against this risk, wh= ile delaying the decision of what PQ signature scheme should replace Schnor= r in the event of Schnorr's security being weakened.

Q &= ; A
=3D=3D=3D=3D

Q: Could these signatures be abus= ed to store JPEGs on the blockchain?
A: No because they would have= no additional discount. This means they would have no advantage for JPEGs = over what is currently possible.

Q: Why not use XMSS or Lam= port signatures instead of SLH_DSA?
A: 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 a= nd software liberties. That said, it is reasonable to consider stateful has= h based signature schemes like XMSS, Winternitz, or Lamport signatures as t= he fallback signature, especially if size becomes a concern.
<= span style=3D"background-color:transparent;font-variant-alternates:normal;c= olor:rgb(0,0,0);vertical-align:baseline;font-size:11pt;font-family:Arial,sa= ns-serif;font-variant-east-asian:normal;font-variant-numeric:normal;">
<= /span>Q: What non-consensus critical changes would be needed to support this?
A; We=E2=80=99d need to create new wallet standards to provide alte= rnatives to BIP32 xpubs. Wallet would have to write code to generate SLH-DS= A keys and create a script tree per signature alg. Wallets would also have = to put into place mechanisms to warn for and prevent public key reuse.
Q: What consensus critical changes would be needed to support t= his?
A: We=E2=80=99d need to merge something like BIP 360 and then= a new CHECKSIG opcode for SLH_DSA.


Q: Couldn=E2=80=99t you do this without BIP 360 by using Taproot = instead and then disabling the taproot key spend path?
A: Yes, how= ever this would be confiscatory, since Taproot allows key spend path only o= utputs. People holding key spend path-only Taproot outputs would have the c= oins in those outputs destroyed. BIP 360, in essence is Taproot, without th= e key spend path. BIP 360 provides the same functionality as disabling Tapr= oot key spend paths, but rather than being confiscatory, it is opt in.
Q: Are you proposing this now because you think that the Bitcoi= n signature algorithms are under threat?
A: No, I am confident in = the Bitcoin signature algorithms and I know of no immediate threats. This e= ffort is motivated by longtermism and thinking about how to enable Bitcoin = to be safe on timescales of decades or centuries.


[0]: Mikhail Kudinov, Jonas Nick, Hash-based Signature Schemes for Bitco= in (2025) https://eprint.iacr.org/2025/2203=


I want to acknowledge conduition=E2=80=99s feedback and suggesti= ons on this email, including the sentence about xpubs. The ideas above resu= lted from conversations between myself, Hunter and Isabel. Similar ideas ha= ve been suggested on the list before. I make no claims of originality, I am= organizing these ideas and my thoughts on them into a concrete design. All errors are my own.  

Thanks,Ethan

--=20
You received this message because you are subscribed to the Google Gro= ups "Bitcoin Development Mailing List" group.=20
To unsubscribe from this group and stop receiving emails from it, send= an email to bit= coindev+unsubscribe@googlegroups.com.=20
To view this discussion visit https://gro= ups.google.com/d/msgid/bitcoindev/CAEM%3Dy%2BWTqe8%3DuqChu2vN3HruiJCvFcDMNP= %2BJA0AwyOkaR%3Dz0Cw%40mail.gmail.com.=20

--
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= /af3369ef-7390-4695-ad6e-899a6ac8b700%40reardencode.com.
------=_Part_8_179781947.1770760290371--