From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 24 Feb 2026 19:42:23 -0800 Received: from mail-oo1-f56.google.com ([209.85.161.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 1vv5n4-0001QR-QQ for bitcoindev@gnusha.org; Tue, 24 Feb 2026 19:42:23 -0800 Received: by mail-oo1-f56.google.com with SMTP id 006d021491bc7-679c6ef1538sf53530853eaf.3 for ; Tue, 24 Feb 2026 19:42:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1771990936; x=1772595736; 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=wybhONVpRo5Tt5yPygzA6kwPwLVXSW7UQkTkGm951B8=; b=h5YpRUzyXWfEyD5itWf8e0etpXg3+1Nb5GmLH7Uwvd4Y2aWWWC4yKIzx7kDNloXgMX Mpwf6YtvpMwt3+8KSygrSUPYRoFGEPcz7zF0AvdR7HAoMYP5Rp/t6fdoFnZ8sWIPq4ne nL9JaweutLdAnnq160HbqUnUozZRtrDPdVsDt73j4rB+xvlAdymmYzhgtbVUC0CdfzSE d/cNkoDEwaMIZis7ujzZOZ63/JqMMCgQs1+8CHwZO+bs1XL0GGJO2p5wyFI8g3ugEpZs EX0SsXh7JavXNg/U/hmE180aYBAOcJFJC1PCDLoYO3VDcq+/IEjRlF3Du7deKXN7C8JW iFHA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1771990936; x=1772595736; 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=wybhONVpRo5Tt5yPygzA6kwPwLVXSW7UQkTkGm951B8=; b=Rxklx/TZAJiGzHKaBS4uPfBUfnpUjy5oipkHQBqsomVyZqOQUfLCviUem8RzD/rVN8 a53Y+8O2zwI4Hzx8fYFeukZ6uzcmRvLjUJ1FZNSwW0g/TWFqOLzi+oCr1tGHQvliSrno 1Jo7ewL8JTyp1QjFKUGUugNMXFUfuanKXOLCmtcpvMFR2tjbYzl2xcpG7Bgjxu11BLWe DiFHBc9rKYZsdQrgbq2Xh1546ek9JlAH2se1eG9VR4MeKRDrME94RjqyXP4CsH4zQlyA el7G9lCukjaMRyXiAH0/6Nz+V8ZwyfjD8mnx6uN/BuATj1GBMx7q94ZUfQ0Jj2uee6Af +gJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771990936; x=1772595736; 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=wybhONVpRo5Tt5yPygzA6kwPwLVXSW7UQkTkGm951B8=; b=FxT3lfLJLqa1W4841MsHhRJaWGu0vJHGRZic22GLwwmAOaJHY14ctg0jHDF8VMeN0m 2ITpOeLYn20y0F84dVx6ReGTyu9gL9SqTZm0xtTU+bt7ZdynkQP/RjYVKso45cqJht+F txIvKjXuRMsXyOfgAlMwjcPR4v8OE5Cs+gkvi/UNFeDtWuCKWaB3g9Z6mwr30yECWp2d R01pTjxRAaDrfG9k/mWZITUNnsuVoMG0ScAwK2rF03LohMlHZk3aS6ASG4KTIKJQhzgV BBisr7Cw3JpZ5eKJQMI4prkr3DOE4sWliF2BbRnySk49YwqZHbJfrMtdIkMVK5HC+abt i6PQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCURg+QFVClBLifY1t4hCOiPYloopsNpRyNPTeq98VFktQyhZ+aIefj4WenUP8+LthZEC+niAbocb+/L@gnusha.org X-Gm-Message-State: AOJu0YyDI0jfzL0/iusNSlw+MhO3IdCYmw3+P924kiu1roANGGxJgg5t kaYh/ZES4P4fgxSP44kuxqb4/0v3GL4g89W4ducJFePLwyAE/80hOkPZ X-Received: by 2002:a4a:ee14:0:b0:667:7e1a:2040 with SMTP id 006d021491bc7-679c44e39d0mr8257678eaf.48.1771990936366; Tue, 24 Feb 2026 19:42:16 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+HpH8o42vbzFXCXTEuKq2XwRT1XMu4DdKpaHqpDfveRLA==" Received: by 2002:a05:6820:f065:b0:678:6b70:ffec with SMTP id 006d021491bc7-679deeb0755ls219558eaf.2.-pod-prod-00-us-canary; Tue, 24 Feb 2026 19:42:12 -0800 (PST) X-Received: by 2002:a05:6808:1583:b0:45e:fff5:89b4 with SMTP id 5614622812f47-4648bc3373amr1448256b6e.10.1771990931908; Tue, 24 Feb 2026 19:42:11 -0800 (PST) Received: by 2002:a05:690c:868e:20b0:796:d04e:652b with SMTP id 00721157ae682-7979c51bfe7ms7b3; Mon, 23 Feb 2026 16:12:06 -0800 (PST) X-Received: by 2002:a05:690c:93:b0:797:ce9d:5c9e with SMTP id 00721157ae682-7982b7bbbaamr97580147b3.10.1771891925375; Mon, 23 Feb 2026 16:12:05 -0800 (PST) Date: Mon, 23 Feb 2026 16:12:04 -0800 (PST) From: Alex To: Bitcoin Development Mailing List Message-Id: <2e1d77b5-080c-423c-9796-d5ba3f22017dn@googlegroups.com> 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/mixed; boundary="----=_Part_2832_844757667.1771891924920" X-Original-Sender: alexhultman@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_2832_844757667.1771891924920 Content-Type: multipart/alternative; boundary="----=_Part_2833_626843584.1771891924920" ------=_Part_2833_626843584.1771891924920 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 verify= =20 1000 sigs per second using the non-optimized reference implementation. A=20 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 need= =20 this we can just make a ZK proof of the seed phrase" - I'm pretty sure such= =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, regardless= ,=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 read= y=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 wro= te: > >> >>> >>> I'd be excited to learn about this as an option. Erik, could you please= =20 >>> answer my previous questions about the viability of your linked protoco= l?=20 >>> I'm not questioning its quantum-resistance properties (yet). I'm wonder= ing=20 >>> how it is possible to instantiate this scheme in a way that allows a wa= llet=20 >>> to actually use this commit/reveal scheme without knowing the final=20 >>> destination CTV templates (denoted T & E in the delving post) in advanc= e 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 muc= h=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 around= =20 >> implementation and node safety... but i think you could do many kinds of= =20 >> vaulting schemes with it alone. >> >> >> But in the case of hash-based signature (HBS) schemes, i disagree. HBS i= s=20 >>> already mature. Whatever cryptanalytic breakthroughs the future holds, = we=20 >>> can be reasonably sure that SHA256 preimage resistance will hold for a = long=20 >>> time, so HBS security will hold. Even today md4 and md5 preimage resist= ance=20 >>> still holds. Securing coins using hashes alone is the ideal fallback, a= nd=20 >>> even if HBS is not the most efficient class of schemes, that doesn't ma= tter=20 >>> so much if we don't use HBS as our primary everyday signature scheme. I= ts=20 >>> 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 o= f=20 >> 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 fo= r=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, 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. >> > --=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/= 2e1d77b5-080c-423c-9796-d5ba3f22017dn%40googlegroups.com. ------=_Part_2833_626843584.1771891924920 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable You don't need "the perfect signature" on day 1, you just need something ev= eryone can agree on is good enough as a migration step. SLH-DSA can indeed = fill that role - it means a transaction will cost about 10x more than now.<= div>
Whether SLH-DSA or ML-DSA is picked is IMO less import= ant because eventually "the perfect signature" will be ready:=C2=A0https://= sqisign.org/

SQIsign is 65 + 148 bytes and my DDR3 era Haswell P= C (from 2014) can verify 1000 sigs per second using the non-optimized refer= ence implementation. A modern budget CPU can do 30k verifications per secon= d.

You only need SLH-DSA as an (optional) signature that maybe i= s never even used at all. It's just an insurance. When I hear people say "w= e don't need this we can just make a ZK proof of the seed phrase" - I'm pre= tty sure such a ZK proof is much larger than SLH-DSA anyways and would requ= ire a total halt of the Bitcoin network and be way less efficient. With SLH= -DSA you would get that migration done seamlessly and more efficient anyway= s.

m=C3=A5ndag 23 februari 2026 kl. 23:03:03 UTC+1 skrev Ethan Heil= man:
>=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 learn about this as an option. Erik, could you pleas= e answer my previous questions about the viability of your linked protocol?= I'm not questioning its quantum-resistance properties (yet). I'm w= ondering how it is possible to instantiate this scheme in a way that allows= a wallet to actually use this commit/reveal scheme without knowing the fin= al destination CTV templates (denoted T & E in the delving post) in adv= ance of creating the phase 0 locking script.
=
I provided an example script that shows how it works:=C2=A0<= a href=3D"https://gist.github.com/earonesty/ea086aa995be1a860af093f93bd45bf= 2" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://www.g= oogle.com/url?hl=3Dsv&q=3Dhttps://gist.github.com/earonesty/ea086aa995b= e1a860af093f93bd45bf2&source=3Dgmail&ust=3D1771977878173000&usg= =3DAOvVaw2bh3PacIQ5Lz6WhshcGnlI">https://gist.github.com/earonesty/ea086aa9= 95be1a860af093f93bd45bf2. 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 flexibility needed for the final spend, since you don&#= 39;t commit to it.=C2=A0 =C2=A0

however someone has pointed out a fe= e-problem that CCV's value-aware composability can solve.=C2=A0 =C2=A0c= oming around to thinking the ccv-based construction would be necessary.=C2= =A0 =C2=A0CCV is more powerful but requires much more care in policy and an= alysis.=C2=A0 CTV is trivial, we could merge it tomorrow and hardly worry a= bout surface area issues.=C2=A0 =C2=A0TXHASH is only slightly more complica= ted.=C2=A0 CCV has a much bigger burden of proof around implementation and = node safety... but i think you could do many kinds of vaulting schemes with= it alone.


But in the case of hash-based signature (HBS) sch= emes, i disagree. HBS is already mature. Whatever cryptanalytic breakthroug= hs the future holds, we can be reasonably sure that SHA256 preimage resista= nce will hold for a long time, so HBS security will hold. Even today md4 an= d 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 sch= emes, that doesn't matter so much if we don't use HBS as our primar= y everyday signature scheme. Its value lies in security, not efficiency.

When I mean "too soon", I'm includin= g SPHINCS, not sure what

1.=C2=A0Earlier versions of the SPHINCS framework were found to be susc= eptible to=C2=A0fault attacks2. Earlier "Tight" proof for v1 SPHINCS was flawed, leading to 6= 0 bits of security, not 128

> If you're worried about = stuff like how xpubs would work with HBS, we have solutions for that too, a= nd they are mostly drop-in replacements for existing standards.
<= br>
I thought "tweaking", in general, is lost in SPHINC= S, as well as multiparty sigs.=C2=A0 Be interested to see those solutions.= =C2=A0 =C2=A0But, regardless, 17kb sigs are... not compatible with a decent= ralized bitcoin, imo.=C2=A0 =C2=A0Lattice-sigs are the only reasonable PQ w= ay 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/2e1d77b5-080c-423c-9796-d5ba3f22017dn%40googlegroups.com.
------=_Part_2833_626843584.1771891924920-- ------=_Part_2832_844757667.1771891924920--