From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 25 Feb 2026 03:32:55 -0800 Received: from mail-ot1-f55.google.com ([209.85.210.55]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vvD8P-0008G2-UI for bitcoindev@gnusha.org; Wed, 25 Feb 2026 03:32:55 -0800 Received: by mail-ot1-f55.google.com with SMTP id 46e09a7af769-7d4c3d9dd70sf96975706a34.1 for ; Wed, 25 Feb 2026 03:32:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1772019168; x=1772623968; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=HBCik76TmWzV4UWVQg+QX3rxD4/k+vEUn9ZtzBJgvNI=; b=kSXJ4X8k+ZviRj1UbBgKAn/rRl2HJgxesSrpvAanT5xhNEd2p7q7Zk+VvmuqZwH913 YSWGnkEmJqJrLxmt6Lyho12EO91SSsJSnELBmus9KpyIikFZjpeeYwBf8k7HygJIiC2U zZ6sGUXlMRzlqhT+LBCLQLlTgXAaSAYHWXiSUtBlqvmTxlKbcunstIkF6H7jkVG7QW/W XMglLTQnI5ZmeKUgXc4VEHS2WUYW/8RYagCcbZJn4eHpcZGU3l2YMFHM3X0EOSCSm537 PHgAS5B6QxNMieu37+lLYIjkm4c6OoAID0v/7S4yTeYG7r3fHpjgiayGEakuMG/GKQEq sbrg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772019168; x=1772623968; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=HBCik76TmWzV4UWVQg+QX3rxD4/k+vEUn9ZtzBJgvNI=; b=eU7dBysbpZTGmTI5u9EK1H3/0E3cDLlSyBEN1GmClLAhJA4YKAUTGvsM9Rpu5wPTM1 vnEVuNUAk9Qpns/0ieZWuHfSuvOB5aosGlDVR0NWThFU2hTv7vNGqaf3eqk/8s7/7JAp 0JPfTHfn+N2qAOn+Up93J40Kl+UPGTFch8toYUiwd4BCiwtSe54yNFIWE8U0CKdOBOcr o4wYe+Jg9a6VDzh+NIYp9y7pNBdAqqIJjT+CTN44rQxI+LAMsbuDxqXwqC2Gkk6l0m08 XzY7e50sRr4/qcbBz4N41Thih+5ZOATzAXabmyI8X9RGNoPQ4EfwXqpEJMHq0kiU81i7 iLhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772019168; x=1772623968; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=HBCik76TmWzV4UWVQg+QX3rxD4/k+vEUn9ZtzBJgvNI=; b=Hwvfw833TB8+aTtMirVLmmHu9Jv40CIyhr0ULrIk7sMvy+5egv58mrx6keFmLgN810 Sy8tO3aron5k+Absf/VLpDV+/z9SRkTYUIt5Pxpo/LfMzCfegH2W4mErQ1NgMRQ9kN11 TK7mN+4m3GaP+yNJdt8p4Y3OdhajNxa/QlyIVlViJYeaLl+66X2zcR8R+KKnIFi4wamC WfjcbhhO4HUdyCkBqRqfvjK4nLfe5MJkxGe9/d87VkpGzGqoH6pByg8t9d6ZdzkkDpSE DfhgNvPNC3PCsk23dTlh8ti+5RC/kb97q/HWg87HnGy+JOh2s5v+53UK0/4vB9Kwndsx W9BA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCWqdy6JMvDxEosu0+q64sT7fJ13VY1hvtZEsGu0EscgLxB1tFSIhMm/Xrs+DzymjnknYV8Eodq67otD@gnusha.org X-Gm-Message-State: AOJu0YwgQTVXwR9IsTw89iU+GqAcJhX9Q+l0MBe3CDGlITXjxoSrixd8 smaWxD2ffLu76Wobc28usAzxmcluTxkw1wKi4qVTmvtlG1hGa3dBERqm X-Received: by 2002:a05:6870:8997:b0:409:62c9:5cb8 with SMTP id 586e51a60fabf-4157ac21970mr9739437fac.10.1772019167637; Wed, 25 Feb 2026 03:32:47 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+HKrqG26wgAZU4wp9N47p/+9Ipz6h22gkYcyLxD0+HSLA==" Received: by 2002:a05:6870:47a0:b0:40f:1fb:db8f with SMTP id 586e51a60fabf-415ee1c9697ls256721fac.1.-pod-prod-09-us; Wed, 25 Feb 2026 03:32:42 -0800 (PST) X-Received: by 2002:a05:6808:1b21:b0:45c:9936:10be with SMTP id 5614622812f47-46446387894mr8358315b6e.42.1772019162284; Wed, 25 Feb 2026 03:32:42 -0800 (PST) Received: by 2002:a05:690c:930f:20b0:797:d142:b0fa with SMTP id 00721157ae682-79866a23fc6ms7b3; Wed, 25 Feb 2026 02:43:54 -0800 (PST) X-Received: by 2002:a05:690c:d91:b0:798:4d34:cc3e with SMTP id 00721157ae682-7984d34ce73mr73743807b3.21.1772016234204; Wed, 25 Feb 2026 02:43:54 -0800 (PST) Date: Wed, 25 Feb 2026 02:43:53 -0800 (PST) From: Javier Mateos To: Bitcoin Development Mailing List Message-Id: <5ce409f5-2416-4d79-9883-c2fb4b3eaaa8n@googlegroups.com> In-Reply-To: <2e1d77b5-080c-423c-9796-d5ba3f22017dn@googlegroups.com> References: <2e1d77b5-080c-423c-9796-d5ba3f22017dn@googlegroups.com> 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/mixed; boundary="----=_Part_4590_1709356964.1772016233771" X-Original-Sender: javierpmateos@gmail.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 (/) ------=_Part_4590_1709356964.1772016233771 Content-Type: multipart/alternative; boundary="----=_Part_4591_1201631379.1772016233771" ------=_Part_4591_1201631379.1772016233771 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi list, Ethan=E2=80=99s framework of using Schnorr for everyday spending and a hash= based=20 signature as a fallback inside P2MR strikes me as the right direction. I=E2= =80=99ve=20 been working on a concrete proposal for that fallback role. WOTS-Tree [1] is essentially XMSS parameterized for Bitcoin: SHA-256=20 truncated to 128 bits for the WOTS+ chains, and full SHA-256 for the Merkle= =20 tree. The fallback witness is 675 bytes with 1,024 leaves, or 353 bytes for= =20 single use UTXOs. Verification is bounded at 4,601 hash computations. It is deployed as a leaf under BIP 341 and is compatible with BIP 360. When= =20 spending with Schnorr, the extra cost is the same ~10 vbytes as any other= =20 unused leaf. It is stateful, which I understand is not ideal for everyone. However,=20 unlike generic XMSS, the main risk of stateful schemes reusing an index and= =20 breaking security is mitigated here because the blockchain already records= =20 which leaves have been used. The paper describes a three step state=20 recovery protocol based on the UTXO set, and chain isolation ensures that= =20 RBF does not force signature reuse. Paper with full security reduction, implementation, and test vectors: [1] https://eprint.iacr.org/2026/374 [2] https://github.com/javierpmateos/wots-tree Best regards, Javier El mi=C3=A9rcoles, 25 de febrero de 2026 a las 0:42:16 UTC-3, Alex escribi= =C3=B3: > You don't need "the perfect signature" on day 1, you just need something= =20 > everyone can agree on is good enough as a migration step. SLH-DSA can=20 > indeed fill that role - it means a transaction will cost about 10x more= =20 > than now. > > Whether SLH-DSA or ML-DSA is picked is IMO less important because=20 > eventually "the perfect signature" will be ready: https://sqisign.org/ > > SQIsign is 65 + 148 bytes and my DDR3 era Haswell PC (from 2014) can=20 > verify 1000 sigs per second using the non-optimized reference=20 > implementation. A modern budget CPU can do 30k verifications per second. > > You only need SLH-DSA as an (optional) signature that maybe is never even= =20 > used at all. It's just an insurance. When I hear people say "we don't nee= d=20 > this we can just make a ZK proof of the seed phrase" - I'm pretty sure su= ch=20 > a ZK proof is much larger than SLH-DSA anyways and would require a total= =20 > halt of the Bitcoin network and be way less efficient. With SLH-DSA you= =20 > would get that migration done seamlessly and more efficient anyways. > > m=C3=A5ndag 23 februari 2026 kl. 23:03:03 UTC+1 skrev Ethan Heilman: > >> > I thought "tweaking", in general, is lost in SPHINCS, as well as=20 >> multiparty sigs. Be interested to see those solutions. But, regardles= s,=20 >> 17kb sigs are... not compatible with a decentralized bitcoin, imo. =20 >> Lattice-sigs are the only reasonable PQ way forward and they aren't rea= dy=20 >> yet. >> >> SPHINCS is ~8kb (7,888 bytes) not 17kb. >> >> SPHINCS SLH-DSA-128s has 32 byte public keys and 7,856 byte signatures >> Total size of 7,888 bytes not 17kb. >> >> The Lattice sigs aren't that much better than SPHINCS=20 >> >> CRYSTALS-Dilithium ML-DSA has 1,312 byte public keys and 2,420 byte=20 >> signatures >> Total size of 3,732 bytes.=20 >> >> Falcon has 897 byte public keys and 666 signatures >> 1,563 bytes >> >> ML-DSA currently has the most support in the Lattice world, but it is=20 >> still too large to be a drop in replacement for ECC without a witness=20 >> discount. If we had to choose tomorrow, I'd advocate for ML-DSA with a= =20 >> massive witness discount, but I'd be very unhappy with the witness=20 >> discount. If the witness discount was out of the question, then I'd=20 >> advocate for something similar to 324-byte stateful hash based SHRINCS= =20 >> signature. Neither is ideal. >> >> My current thinking is to use SLH-DSA as a backup. This keeps us safe if= =20 >> everything goes wrong and allows us to reach safety early so we can take= =20 >> time to determine the right drop-in replacement for ECC. Hopefully in 3= =20 >> years, SQI-sign is fast enough to be considered. >> >> On Mon, Feb 23, 2026 at 2:08=E2=80=AFPM Erik Aronesty wr= ote: >> >>> >>>> >>>> I'd be excited to learn about this as an option. Erik, could you pleas= e=20 >>>> answer my previous questions about the viability of your linked protoc= ol?=20 >>>> I'm not questioning its quantum-resistance properties (yet). I'm wonde= ring=20 >>>> how it is possible to instantiate this scheme in a way that allows a w= allet=20 >>>> to actually use this commit/reveal scheme without knowing the final=20 >>>> destination CTV templates (denoted T & E in the delving post) in advan= ce of=20 >>>> creating the phase 0 locking script. >>>> >>> >>> I provided an example script that shows how it works:=20 >>> https://gist.github.com/earonesty/ea086aa995be1a860af093f93bd45bf2. you= =20 >>> don't pin to the final destination in phase 0. >>> >>> txhash is a partial-commitment, not over all fields. this give the=20 >>> flexibility needed for the final spend, since you don't commit to it. = =20 >>> >>> however someone has pointed out a fee-problem that CCV's value-aware=20 >>> composability can solve. coming around to thinking the ccv-based=20 >>> construction would be necessary. CCV is more powerful but requires mu= ch=20 >>> more care in policy and analysis. CTV is trivial, we could merge it=20 >>> tomorrow and hardly worry about surface area issues. TXHASH is only= =20 >>> slightly more complicated. CCV has a much bigger burden of proof aroun= d=20 >>> implementation and node safety... but i think you could do many kinds o= f=20 >>> vaulting schemes with it alone. >>> >>> >>> But in the case of hash-based signature (HBS) schemes, i disagree. HBS= =20 >>>> is already mature. Whatever cryptanalytic breakthroughs the future hol= ds,=20 >>>> we can be reasonably sure that SHA256 preimage resistance will hold fo= r a=20 >>>> long time, so HBS security will hold. Even today md4 and md5 preimage= =20 >>>> resistance still holds. Securing coins using hashes alone is the ideal= =20 >>>> fallback, and even if HBS is not the most efficient class of schemes, = that=20 >>>> doesn't matter so much if we don't use HBS as our primary everyday=20 >>>> signature scheme. Its value lies in security, not efficiency. >>>> >>> >>> When I mean "too soon", I'm including SPHINCS, not sure what >>> >>> 1. Earlier versions of the SPHINCS framework were found to be=20 >>> susceptible to fault attacks >>> 2. Earlier "Tight" proof for v1 SPHINCS was flawed, leading to 60 bits= =20 >>> of security, not 128 >>> >>> > If you're worried about stuff like how xpubs would work with HBS, we= =20 >>> have solutions for that too, and they are mostly drop-in replacements f= or=20 >>> existing standards. >>> >>> I thought "tweaking", in general, is lost in SPHINCS, as well as=20 >>> multiparty sigs. Be interested to see those solutions. But, regardle= ss,=20 >>> 17kb sigs are... not compatible with a decentralized bitcoin, imo. =20 >>> Lattice-sigs are the only reasonable PQ way forward and they aren't re= ady=20 >>> yet. >>> >> --=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/= 5ce409f5-2416-4d79-9883-c2fb4b3eaaa8n%40googlegroups.com. ------=_Part_4591_1201631379.1772016233771 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi list,

Ethan=E2=80=99s framework of using Schnorr for everyday spending and a h= ash based signature as a fallback inside P2MR strikes me as the right direc= tion. I=E2=80=99ve been working on a concrete proposal for that fallback ro= le.

WOTS-Tree [1] is essentially XMSS parameterized for Bitcoin: SHA-256 tru= ncated to 128 bits for the WOTS+ chains, and full SHA-256 for the Merkle tr= ee. The fallback witness is 675 bytes with 1,024 leaves, or 353 bytes for s= ingle use UTXOs. Verification is bounded at 4,601 hash computations.

It is deployed as a leaf under BIP 341 and is compatible with BIP 360. W= hen spending with Schnorr, the extra cost is the same ~10 vbytes as any oth= er unused leaf.

It is stateful, which I understand is not ideal for everyone. However, u= nlike generic XMSS, the main risk of stateful schemes reusing an index and = breaking security is mitigated here because the blockchain already records = which leaves have been used. The paper describes a three step state recover= y protocol based on the UTXO set, and chain isolation ensures that RBF does= not force signature reuse.

Paper with full security reduction, implementation, and test vectors: [1] https://e= print.iacr.org/2026/374
[2] https://github.com/javierpmateos/wots-tree

Best regards,
Javier


El mi=C3=A9rcoles, 25 de febrero de 2026 a l= as 0:42:16 UTC-3, Alex escribi=C3=B3:
You don't need "the perfect signature&quo= t; on day 1, you just need something everyone can agree on is good enough a= s a migration step. SLH-DSA can indeed fill that role - it means a transact= ion will cost about 10x more than now.

Whether SLH-DSA o= r ML-DSA is picked is IMO less important because eventually "the perfe= ct signature" will be ready:=C2=A0https://sqisign.org= /

SQIsign is 65 + 148 bytes and my DDR3 era Haswell PC (from 201= 4) can verify 1000 sigs per second using the non-optimized reference implem= entation. A modern budget CPU can do 30k verifications per second.

Y= ou only need SLH-DSA as an (optional) signature that maybe is never even us= ed at all. It's just an insurance. When I hear people say "we don&= #39;t need this we can just make a ZK proof of the seed phrase" - I= 9;m pretty sure such a ZK proof is much larger than SLH-DSA anyways and wou= ld require a total halt of the Bitcoin network and be way less efficient. W= ith SLH-DSA you would get that migration done seamlessly and more efficient= anyways.

m=C3=A5ndag 23 februari 2026 kl. 23:03:03 UTC+1 skrev Ethan= Heilman:
>=C2=A0 I thought "tweaking", in general, is lost in SPHINCS, as well as = multiparty sigs.=C2=A0 Be interested to see those solutions.=C2=A0 =C2=A0Bu= t, regardless, 17kb sigs are... not compatible with a decentralized bitcoin= , imo.=C2=A0 =C2=A0Lattice-sigs are the only reasonable PQ way forward and = they aren't ready yet.

SPHINCS is ~8kb (7= ,888 bytes) not 17kb.

SPHINCS SLH-DSA-128s has 32 byte public keys a= nd=C2=A07,856 byte signatures
Total size of 7,888 bytes not 17kb.
The Lattice sigs aren't that much better than=C2=A0 SPHINCS=20

CRYSTALS-Dilithium ML-DSA has 1,312 byte public keys and 2,420 byte= signatures
Total size of 3,732 bytes.

Falcon has 897 byte public keys and 666 signatures
1,563 bytes
ML-DSA currently has the most support in the Lattice world, but it is= still too large to be a drop in replacement for ECC without a witness disc= ount. If we had to choose tomorrow, I'd advocate for ML-DSA with a mass= ive witness discount, but I'd be very unhappy with the witness discount= . If the witness discount was out of the question, then I'd advocate fo= r something similar to 324-byte stateful hash based SHRINCS signature. Neit= her is ideal.

My current thinking is to use SLH-DSA as a backup. Thi= s keeps us safe if everything goes wrong and allows us to reach safety earl= y so we can take time to determine the right drop-in replacement for ECC. H= opefully in 3 years, SQI-sign is fast enough to be considered.

On Mon, Feb 2= 3, 2026 at 2:08=E2=80=AFPM Erik Aronesty <er...@q32.= com> wrote:


I'd be excited to l= earn about this as an option. Erik, could you please answer my previous que= stions about the viability of your linked protocol? I'm not questioning= its quantum-resistance properties (yet). I'm wondering how it is possi= ble to instantiate this scheme in a way that allows a wallet to actually us= e this commit/reveal scheme without knowing the final destination CTV templ= ates (denoted T & E in the delving post) in advance of creating the pha= se 0 locking script.

I provide= d an example script that shows how it works:=C2=A0https://gist.github.com/earonesty/ea086aa995be1a860af093f93bd45bf2= . you don't pin to the final destination in phase 0.

txhash = is a partial-commitment, not over all fields.=C2=A0 this=C2=A0give the flex= ibility needed for the final spend, since you don't commit to it.=C2=A0= =C2=A0

however someone has pointed out a fee-problem that CCV's= value-aware composability can solve.=C2=A0 =C2=A0coming around to thinking= the ccv-based construction would be necessary.=C2=A0 =C2=A0CCV is more pow= erful but requires much more care in policy and analysis.=C2=A0 CTV is triv= ial, we could merge it tomorrow and hardly worry about surface area issues.= =C2=A0 =C2=A0TXHASH is only slightly more complicated.=C2=A0 CCV has a much= bigger burden of proof around implementation and node safety... but i thin= k you could do many kinds of vaulting schemes with it alone.

=

But in the case of hash-based signature (HBS) schemes, i disagree. HBS is = already mature. Whatever cryptanalytic breakthroughs the future holds, we c= an be reasonably sure that SHA256 preimage resistance will hold for a long = time, so HBS security will hold. Even today md4 and md5 preimage resistance= still holds. Securing coins using hashes alone is the ideal fallback, and = even if HBS is not the most efficient class of schemes, that doesn't ma= tter so much if we don't use HBS as our primary everyday signature sche= me. Its value lies in security, not efficiency.

= When I mean "too soon", I'm including SPHINCS, not sure what<= br>
1.=C2=A0Earlier versi= ons of the SPHINCS framework were found to be susceptible to=C2=A0fault attacks
2. Earlier "Tight&q= uot; proof for v1 SPHINCS was flawed, leading to 60 bits of security, not 1= 28

> If you're worried about stuff like how xpubs woul= d work with HBS, we have solutions for that too, and they are mostly drop-i= n replacements for existing standards.

I thought &= quot;tweaking", in general, is lost in SPHINCS, as well as multiparty = sigs.=C2=A0 Be interested to see those solutions.=C2=A0 =C2=A0But, regardle= ss, 17kb sigs are... not compatible with a decentralized bitcoin, imo.=C2= =A0 =C2=A0Lattice-sigs are the only reasonable PQ way forward and they aren= 't ready yet.

--
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/bitcoind= ev/5ce409f5-2416-4d79-9883-c2fb4b3eaaa8n%40googlegroups.com.
------=_Part_4591_1201631379.1772016233771-- ------=_Part_4590_1709356964.1772016233771--