From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 26 Feb 2026 05:32:13 -0800 Received: from mail-ot1-f63.google.com ([209.85.210.63]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vvbTQ-0004xR-76 for bitcoindev@gnusha.org; Thu, 26 Feb 2026 05:32:13 -0800 Received: by mail-ot1-f63.google.com with SMTP id 46e09a7af769-7d4c2b7f4casf4870391a34.2 for ; Thu, 26 Feb 2026 05:32:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1772112726; x=1772717526; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to: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=+kOifYWUoq8Fe8Aw6zQqrJQS6lqDVxvrRoFirVQOtbM=; b=iTArY2hQnkaLlOx9MKChQ0EpoYFXfvnc6+ScEFGdYdXyaIn09XELKdz8BusDiRC/q3 pogjV+Azx4Sq1Tg2LtOYJbZ8VgleWdjXSoPEOlPG2Y/wI9KiTm4W9NxZahIgi6q9mXBk BmrBmiiW/tdqR/kMuuAx9VMS4XmsmsupaP3Bw4SlbS8KmrumgUayUKWMzhbZdwPvf8CP PEIFe61td5+GR8W6BURcolLU3C2ZlFUD8m0MqYBfuPA7u8sigAnyfy4LMEHWg+89L4oQ TRa6r7d0H1fmGzy8NsIA8GG9tYgku3u69ggaDM/ncuSrdd93v2E57viK7do1Rp8WzPR3 PZpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772112726; x=1772717526; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:x-original-sender :mime-version:subject:references:in-reply-to:message-id:to:from:date :x-beenthere:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=+kOifYWUoq8Fe8Aw6zQqrJQS6lqDVxvrRoFirVQOtbM=; b=aDv81OL3GRK1PbyTfY2jPVTglF5Lb1aDqf7ePuI/88grSjDmJEQC+6WIE62XF+s39W RNASI2WN0WB2wdpBAzauvwYNWqwj31EI7SNXU+u8MVUnjNUrIfnk2fYkdu6UKM2PfTuJ KrS9/o6uqPgy0uZw5tCZij+IkVqQvf6U7XmEVOLLNFOP4x6IfMt4szrbEHDK+rsGA4K8 w5PeG3l5TRqrvuWKX8+1BqrIZnt3281bwnkQe9h6uFLWhQRAXFE0+6IMCvaGq3Q9MzAX BAsniOTsfmeRclIaOeZiATNX56v4oanuxOIb1Y7RTqIMbU7e19EtuNhbcwF98HoEAwN8 VoBQ== X-Forwarded-Encrypted: i=1; AJvYcCVg8nsEOu9E5PFSnw38x4cxIzwNIINdiNT6qD9ohbLI7EcK3BTIPF32Oe4KDUbbwNXQj/eBBH0Ff/Yt@gnusha.org X-Gm-Message-State: AOJu0YyUbkgR/aE7QYALo2cf/2g5hFCul7Q1MXaymgPmcEzrzso+yGsu QhGA7Uv7jaOMMfLStUOkzpnsyYnjo9En4aXzmVdJJ5brCdJ/kSVaOseT X-Received: by 2002:a05:6870:30f:b0:409:40bb:6b5d with SMTP id 586e51a60fabf-415ffdd7906mr2826168fac.32.1772112725739; Thu, 26 Feb 2026 05:32:05 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+Hfna89k/0PRhvbnNQi9QVT4vKYBzBJiv0tAi47oegfLw==" Received: by 2002:a05:6870:581:b0:40e:fc6f:d551 with SMTP id 586e51a60fabf-415ee1c95b3ls88490fac.1.-pod-delta-03-us; Thu, 26 Feb 2026 05:31:59 -0800 (PST) X-Received: by 2002:a05:6808:4f23:b0:45a:9068:6421 with SMTP id 5614622812f47-464462f6acbmr7597054b6e.3.1772112718925; Thu, 26 Feb 2026 05:31:58 -0800 (PST) Received: by 2002:a05:690c:c007:b0:794:2788:2ae4 with SMTP id 00721157ae682-7986692eec0ms7b3; Thu, 26 Feb 2026 05:24:29 -0800 (PST) X-Received: by 2002:a05:690c:8:b0:798:6e05:4c2c with SMTP id 00721157ae682-7986e0553d7mr36025777b3.0.1772112268009; Thu, 26 Feb 2026 05:24:28 -0800 (PST) Date: Thu, 26 Feb 2026 05:24:27 -0800 (PST) From: "'Mikhail Kudinov' via Bitcoin Development Mailing List" To: Bitcoin Development Mailing List Message-Id: <45c53988-f011-4bc5-b58b-7656dcf5d080n@googlegroups.com> In-Reply-To: <5ce409f5-2416-4d79-9883-c2fb4b3eaaa8n@googlegroups.com> References: <2e1d77b5-080c-423c-9796-d5ba3f22017dn@googlegroups.com> <5ce409f5-2416-4d79-9883-c2fb4b3eaaa8n@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_61896_2071111466.1772112267546" X-Original-Sender: mkudinov@blockstream.com X-Original-From: Mikhail Kudinov Reply-To: Mikhail Kudinov 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_61896_2071111466.1772112267546 Content-Type: multipart/alternative; boundary="----=_Part_61897_1452974830.1772112267546" ------=_Part_61897_1452974830.1772112267546 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Javier, Thank you for your work. I am happy that more people are looking at the=20 possibility of using Hash-based schemes as a PQ solution for Bitcoin. As far as I understood, the main idea was to propose concrete=20 instantiations/parameters, and essentially, the small signatures come from= =20 the 2^10 limit on the number of signatures + fast route for the first=20 signature. The other proposal was to use 128-bit hash functions for chains,= =20 which I think is the default way for the 128-bit security requirement.=20 I don't see why one needs to use the full 256 hashes in the Merkle trees.= =20 In the signature context, we don't require collision resistance for=20 security. We only need target collision resistance, which can not be=20 attacked with the birthday paradox.=20 As for the statefulness issue: I agree that the blockchain does record the= =20 signed transactions, but some of them may not end on the blockchain, hence= =20 it is not a 100% reliable source of state. Given that the reuse of a nonce= =20 leads to a forgery of the signature scheme, we can not use blockchain state= =20 as a source of state.=20 As for the comparison with the alternative schemes, I think we should not= =20 omit the number of supported signatures. It is an important metric that is= =20 tightly related to the efficiency of a hash-based signature scheme.=20 Regarding some details that you mention in the paper:=20 Second-preimage resistance is not enough for the security of W-OTS+. Even= =20 in [9] they require preimage resistance and undetectability. There is a=20 newer and tighter proof for XMSS, which can be found=20 here: https://eprint.iacr.org/2023/408 (based on=20 https://eprint.iacr.org/2022/346).=20 To achieve 128-bit security with the non-tight reduction strategy, one=20 needs to add K + log(lw) bits rather than just log(lw). But with the tight= =20 proof I referenced, this loss can be avoided. I also did not understand how you suggest deriving the public seed from the= =20 transaction, given that the public seed is needed to compute the public key= =20 root.=20 The original SPHINCS scheme used HORST, not FORS. FORS was introduced later= =20 for SPHINCS+ (SLH-DSA). Best, Mike On Wednesday, February 25, 2026 at 12:32:47=E2=80=AFPM UTC+1 Javier Mateos = wrote: > Hi list, > > Ethan=E2=80=99s framework of using Schnorr for everyday spending and a ha= sh 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 Merk= le=20 > tree. The fallback witness is 675 bytes with 1,024 leaves, or 353 bytes f= or=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.=20 > When spending with Schnorr, the extra cost is the same ~10 vbytes as any= =20 > other 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 a= nd=20 > breaking security is mitigated here because the blockchain already record= s=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 escrib= i=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 eve= n=20 >> used at all. It's just an insurance. When I hear people say "we don't ne= ed=20 >> this we can just make a ZK proof of the seed phrase" - I'm pretty sure s= uch=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, 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. >>> >>> 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 i= f=20 >>> everything goes wrong and allows us to reach safety early so we can tak= e=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 w= rote: >>> >>>> >>>>> >>>>> I'd be excited to learn about this as an option. Erik, could you=20 >>>>> please answer my previous questions about the viability of your linke= d=20 >>>>> protocol? I'm not questioning its quantum-resistance properties (yet)= . I'm=20 >>>>> wondering how it is possible to instantiate this scheme in a way that= =20 >>>>> allows a wallet to actually use this commit/reveal scheme without kno= wing=20 >>>>> the final destination CTV templates (denoted T & E in the delving pos= t) in=20 >>>>> advance of creating the phase 0 locking script. >>>>> >>>> >>>> I provided an example script that shows how it works:=20 >>>> https://gist.github.com/earonesty/ea086aa995be1a860af093f93bd45bf2.=20 >>>> you 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 m= uch=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 arou= nd=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= =20 >>>>> is already mature. Whatever cryptanalytic breakthroughs the future ho= lds,=20 >>>>> we can be reasonably sure that SHA256 preimage resistance will hold f= or 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 idea= l=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 = for=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, regardl= ess,=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 r= eady=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/= 45c53988-f011-4bc5-b58b-7656dcf5d080n%40googlegroups.com. ------=_Part_61897_1452974830.1772112267546 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Javier,

Thank you for your work. I am happy that more peopl= e are looking at the possibility of using Hash-based schemes as a PQ soluti= on for Bitcoin.

As far as I understood, the main idea was to pro= pose concrete instantiations/parameters, and essentially, the small signatu= res come from the 2^10 limit on the number of signatures + fast route for t= he first signature. The other proposal was to use 128-bit hash functions fo= r chains, which I think is the default way for the 128-bit security require= ment.=C2=A0
I don't see why one needs to use the full 256 hashes in th= e Merkle trees. In the signature context, we don't require collision resist= ance for security. We only need target collision resistance, which can not = be attacked with the birthday paradox.
As for the statefulness issue:= I agree that the blockchain does record the signed transactions, but some = of them may not end on the blockchain, hence it is not a 100% reliable sour= ce of state. Given that the reuse of a nonce leads to a forgery of the sign= ature scheme, we can not use blockchain state as a source of state.=C2=A0
As for the comparison with the alternative schemes, I think we sh= ould not omit the number of supported signatures. It is an important metric= that is tightly related to the efficiency of a hash-based signature scheme= .=C2=A0

Regarding some details that you mention in the paper: Second-preimage resistance is not enough for the security of W-OTS+. Ev= en in [9] they require preimage resistance and undetectability. There is a = newer and tighter proof for XMSS, which can be found here:=C2=A0https://epr= int.iacr.org/2023/408 (based on https://eprint.iacr.org/2022/346).
To= achieve 128-bit security with the non-tight reduction strategy, one needs = to add K + log(lw) bits rather than just log(lw). But with the tight proof = I referenced, this loss can be avoided.
I also did not understand how = you suggest deriving the public seed from the transaction, given that the p= ublic seed is needed to compute the public key root.=C2=A0
The origina= l SPHINCS scheme used HORST, not FORS. FORS was introduced later for SPHINC= S+ (SLH-DSA).


Best,
Mike


On Wednesday, Febru= ary 25, 2026 at 12:32:47=E2=80=AFPM UTC+1 Javier Mateos wrote:

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://eprint.iacr.o= rg/2026/374
[2] https://github.com/javierpmateos/wots-tree

Best regards,
Javier


El mi=C3=A9rcoles, 25 de febrero de 2026 a las 0:4= 2:16 UTC-3, Alex escribi=C3=B3:
You don't need "the perfect signature" on day 1, yo= u just need something everyone can agree on is good enough as a migration s= tep. SLH-DSA can indeed fill that role - it means a transaction will cost a= bout 10x more than now.

Whether SLH-DSA or ML-DSA is pic= ked is IMO less important because eventually "the perfect signature&qu= ot; will be ready:=C2=A0https://sqisign.org/

SQ= Isign is 65 + 148 bytes and my DDR3 era Haswell PC (from 2014) can verify 1= 000 sigs per second using the non-optimized reference implementation. A mod= ern budget CPU can do 30k verifications per second.

You only need SL= H-DSA as an (optional) signature that maybe is never even used at all. It&#= 39;s just an insurance. When I hear people say "we don't need this= we can just make a ZK proof of the seed phrase" - I'm pretty sure= such a ZK proof is much larger than SLH-DSA anyways and would require a to= tal halt of the Bitcoin network and be way less efficient. With 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/45c53988-f011-4bc5-b58b-7656dcf5d080n%40googlegroups.com.
------=_Part_61897_1452974830.1772112267546-- ------=_Part_61896_2071111466.1772112267546--