From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 20 May 2026 03:04:07 -0700 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 1wPdmY-0004dJ-Tg for bitcoindev@gnusha.org; Wed, 20 May 2026 03:04:07 -0700 Received: by mail-ot1-f55.google.com with SMTP id 46e09a7af769-7e5681f8f12sf7054859a34.1 for ; Wed, 20 May 2026 03:04:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1779271441; x=1779876241; 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=ds3Au+Ij1LBmkTAYnBkI22WOA6I8vuqFPDddDptc0l0=; b=Oi+oqUXvET/GzYbqYR8edvsa5CCC+a325aihf5HMP5HiE3NIyoMNO2iO2mJwEOnhRe dn3Ppc0xl/IxlCKi6tmwAtk9FT/Xzy3vOtsf24unki23IZQx2cwI/vORu3E2PzzW1WMF o9wZJiHUaMZ/lyXfUhfxMxZ/Bn5frwoNP0eKYmIZynrHKaHkcxNoyOSfRAWvd3r1jOjA Z/6zAJ8ttBpcFMIZVJSHY8Mgdyx0TVxF5wCeG7ZfU5WijGnZYTMJQZqMgD3bsZ7Z0vQq iZxeiWKbclWIDh8Vps8Am/aH5XBOiWIK/JvGNPBOZ6G4+EZbKQ400lV/8K5Xu7Wfg6L2 SOuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779271441; x=1779876241; 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=ds3Au+Ij1LBmkTAYnBkI22WOA6I8vuqFPDddDptc0l0=; b=S62EtHnj3UwRqfrvTnS1zhY83DGwOH0+eBB4/xmjBSlrADhlwo1QofcX9pXRiXE+RI xWDR/h6T9adN1z/+JN4oFetRsokfaa2Jmrum6s6Iz4hG2FvgcRDeoTP+8D/utUYt8WHU FOTd1kVF0iG7Rs8GkSZ9xZ2FrMhPMUuxocOgTb0eNZdMAO3LCubMRF/w/yOptd7YCC0Y v9oBRlSYMOnY4BcQ+ZgoyANygaVUsO/2bNbraHqQdvi4OwaEtCeHFl3TMJ0OWWV+2b2w Lt2Dg1ozlXNY0p+xin7puYXFtAFt3WdSgnEtDtcWIRLnGDZ/y+vkZdn0UdC1z+D8Sa/+ W6iQ== X-Forwarded-Encrypted: i=1; AFNElJ+WHw0KmtnwAxNj3LrQ5JO4dczIimwpCGuTMNQADf7P14XdJajEiom1szV+qWlACmppxbAoWdK16MeP@gnusha.org X-Gm-Message-State: AOJu0YxBxcwVg0lNiIVRQq6o3Jtys7nQoVV1z4RtaKRo/rtXhX8Qjjxc ZPMlFV6+UBgboczYotfR3Y294rnZa4YwvgaS8rTeR9HlofvY99c5eDBt X-Received: by 2002:a05:6820:3103:b0:69b:5486:e85 with SMTP id 006d021491bc7-69c9bfd479emr14417004eaf.36.1779271440580; Wed, 20 May 2026 03:04:00 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AUV6zMMunUVDVkDRICTrqPz1PWHONdyAbeR2mitXD6QpP5QNgg==" Received: by 2002:a05:6870:d111:b0:42f:e65d:71bb with SMTP id 586e51a60fabf-43a01ebc86bls973529fac.1.-pod-delta-03-us; Wed, 20 May 2026 03:03:54 -0700 (PDT) X-Received: by 2002:a05:6808:16a1:b0:46a:66a4:957a with SMTP id 5614622812f47-482e58d9459mr8725812b6e.7.1779271434469; Wed, 20 May 2026 03:03:54 -0700 (PDT) Received: by 2002:a05:690c:6202:b0:7ba:f1b3:9504 with SMTP id 00721157ae682-7c6993cf1f6ms7b3; Wed, 20 May 2026 02:56:43 -0700 (PDT) X-Received: by 2002:a05:690c:61c8:b0:7c7:4ea8:542c with SMTP id 00721157ae682-7c958bd3e0emr152112817b3.2.1779271002864; Wed, 20 May 2026 02:56:42 -0700 (PDT) Date: Wed, 20 May 2026 02:56:42 -0700 (PDT) From: "'Mikhail Kudinov' via Bitcoin Development Mailing List" To: Bitcoin Development Mailing List Message-Id: In-Reply-To: References: Subject: Re: [bitcoindev] PQC: Lattice-based signatures MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1615132_39707432.1779271002156" 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_1615132_39707432.1779271002156 Content-Type: multipart/alternative; boundary="----=_Part_1615133_1691793598.1779271002156" ------=_Part_1615133_1691793598.1779271002156 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The floating-point arithmetic of Falcon can be solved with integer=20 simulation. This makes the algorithms less efficient, but still more=20 efficient than SLH-DSA. Best, Mike On Wednesday, May 20, 2026 at 5:27:40=E2=80=AFAM UTC+2 conduition wrote: > Hey Nikita, thanks for broaching the idea. > > I can't speak for Blockstream, but as to the spirit of your question - Wh= y=20 > people are looking at hash-based sigs more than lattices - I can think of= =20 > four major reasons: > > 1. Conservatism. Hash based signatures are incredibly conservative. They= =20 > rely on strictly weaker assumptions than what we already depend on for=20 > other things. No other family of signatures can claim this property, and= =20 > for something as inflexible-yet-sensitive as Bitcoin, conservativism is= =20 > appealing. > > 2. Simplicity. Hash-based signatures are easier to grasp, simpler to prov= e=20 > secure, and easier to implement compared to almost anything else (even=20 > simpler than ECC). We Bitcoiners tend to clutch our pearls in fear of=20 > trusting flawed assumptions... but in reality most vulnerabilities are no= t=20 > cryptographic in nature: Most are implementation failures. Hash-based sig= s=20 > are harder (but not impossible) to screw up. An experienced engineer can= =20 > implement FIPS-205 (SPHINCS) in a weekend, or less with AI tools. This=20 > simplicity also makes hash-based sigs easier to pitch during consensus=20 > debates: It's harder to fear something once you understand it. > > 3. Efficiency. Hash-based sigs are surprisingly fast to verify [0]. Their= =20 > cost-per-byte is way lower than Schnorr. If you can bite the statefulness= =20 > bullet, hash-based sigs can even be compact (and still fast). There remai= ns=20 > some hope we might be able to use them as a daily driver if CRQCs appear= =20 > faster than anticipated. This efficiency comes at a price of course, but= =20 > that price is paid by the signer implementation while verifiers remain=20 > slim, quick, and secure. > > 4. Future-proofing. Because of their conservatism, hash-based sigs stand = a=20 > better chance of remaining secure over a long time-frame, so it seems mor= e=20 > likely we could rely on them to fulfill a long-term fallback role. We wil= l=20 > likely someday need to deploy a new cryptosystem to replace ECC as a dail= y=20 > driver if ECDLP is broken, whether classically or by a CRQC. When/if this= =20 > happens, we'll be REALLY glad we added hash-based sigs first, because the= n=20 > we'll have something to use if the novel scheme's assumptions (or more=20 > likely, implementation) are broken. > > This is not to say we shouldn't be researching lattices. Or isogenies, or= =20 > anything else for that matter. We need to know what's possible, and to=20 > educate the community about the options we have. I'm glad to see=20 > Blockstream funding this important work. I view hash-based sigs as the=20 > first episode of a decades-long saga, but unfortunately we lack enough=20 > knowledge to know what should come next. Maybe that is lattices? maybe=20 > something else. With time, effort, and (hopefully) funding, we shall find= =20 > out. > > If I had to pen a wishlist of stuff I'd like to see from lattice crypto= =20 > research, this would be it: > > - [ ] compact keys and sigs. Ideally, less than a kilobyte witness size= =20 > total, but I'd be happy with at least a twofold improvement over what=20 > stateless hash-based sigs can offer. > - [ ] rerandomization e.g. BIP32 unhardened derivation. This has been don= e=20 > [1], but AFAIK it is impossible without massively expanding the sizes of= =20 > keys and/or signatures. > - [ ] a multisignature scheme, or a threshold protocol with a DKG. Again,= =20 > never seen this without massive keys and sigs, but I see no reason why it= =20 > should be impossible. > - [ ] integer-only arithmetic. Falcon keys and sigs are smaller than=20 > ML-DSA, but it comes at the expense of complex floating point arithmetic= =20 > headaches. It'd be nice if we could do away with that. > - [ ] signature aggregation. This is a more general wish of any PQ scheme= ,=20 > and if someone can do it, even with somewhat large sigs or poor=20 > performance, it might make the whole scheme way more palatable, in tandem= =20 > with a CISA proposal. > > Also see this relevant delvingbitcoin thread [1] for more sources. > > regards, > conduition > > [0]: https://conduition.io/code/fast-slh-dsa-verification/ > [1]:=20 > https://delvingbitcoin.org/t/post-quantum-hd-wallets-silent-payments-key-= aggregation-and-threshold-signatures/1854/ > > On Tuesday, May 19th, 2026 at 9:06 PM, Nikita Karetnikov < > nik...@karetnikov.org> wrote: > > > Dear list, > >=20 > > > I hate to contribute to the recent flood of PQC posts, but I think it= =E2=80=99s=20 > an important issue that=E2=80=99s worth discussing. > >=20 > > > In particular, what I usually see is various competing proposals withou= t=20 > a clear winner. > >=20 > > > So I=E2=80=99d like to bring everyone=E2=80=99s attention to this new p= ost from=20 > Blockstream: > >=20 > https://blog.blockstream.com/schnorr-but-with-vectors-lattice-based-signa= tures-explained/ > >=20 > > > This post is interesting because unlike a lot of PQC discussions, it=20 > actually includes a comparison table of various approaches, where lattice= s=20 > seem to come out ahead. > >=20 > > > This raises a few questions. > >=20 > > > Since lattices are not a new topic in cryptography, why has Blockstream= =20 > focused their efforts on hash-based approaches so far? > > Are hashes seen as a more conservative choice? > >=20 > > > Given the problems with hashes outlined in the post, are lattices=20 > actually the current most likely candidate for a PQC implementation? > > If so, should the community effort be focused on lattices instead of=20 > other proposals? > > Or is the comparison table not telling the whole story? > >=20 > > > I=E2=80=99d like to hear your thoughts on the topic. > >=20 > > > Thanks, > > Nikita > >=20 > > > -- > > You received this message because you are subscribed to the Google=20 > Groups "Bitcoin Development Mailing List" group. > > To unsubscribe from this group and stop receiving emails from it, send= =20 > an email to bitcoindev+...@googlegroups.com. > > To view this discussion visit=20 > https://groups.google.com/d/msgid/bitcoindev/ffa56d63-32c6-4fc3-a150-4fe6= 2ac2e00b%40app.fastmail.com > . > >=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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= eeefdd9a-bb4b-43b7-b547-90d865e31a32n%40googlegroups.com. ------=_Part_1615133_1691793598.1779271002156 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The floating-point arithmetic of Falcon can be solved with integer si= mulation. This makes the algorithms less efficient, but still more efficien= t than SLH-DSA.

Best,
Mike

On Wednesday, May 20, 2026 at = 5:27:40=E2=80=AFAM UTC+2 conduition wrote:
Hey Nikita, thanks for broaching the idea.

I can't speak for Blockstream, but as to the spirit of your questio= n - Why people are looking at hash-based sigs more than lattices - I can th= ink of four major reasons:

1. Conservatism. Hash based signatures are incredibly conservative. The= y rely on strictly weaker assumptions than what we already depend on for ot= her things. No other family of signatures can claim this property, and for = something as inflexible-yet-sensitive as Bitcoin, conservativism is appeali= ng.

2. Simplicity. Hash-based signatures are easier to grasp, simpler to pr= ove secure, and easier to implement compared to almost anything else (even = simpler than ECC). We Bitcoiners tend to clutch our pearls in fear of trust= ing flawed assumptions... but in reality most vulnerabilities are not crypt= ographic in nature: Most are implementation failures. Hash-based sigs are h= arder (but not impossible) to screw up. An experienced engineer can impleme= nt FIPS-205 (SPHINCS) in a weekend, or less with AI tools. This simplicity = also makes hash-based sigs easier to pitch during consensus debates: It'= ;s harder to fear something once you understand it.

3. Efficiency. Hash-based sigs are surprisingly fast to verify [0]. The= ir cost-per-byte is way lower than Schnorr. If you can bite the statefulnes= s bullet, hash-based sigs can even be compact (and still fast). There remai= ns some hope we might be able to use them as a daily driver if CRQCs appear= faster than anticipated. This efficiency comes at a price of course, but t= hat price is paid by the signer implementation while verifiers remain slim,= quick, and secure.

4. Future-proofing. Because of their conservatism, hash-based sigs stan= d a better chance of remaining secure over a long time-frame, so it seems m= ore likely we could rely on them to fulfill a long-term fallback role. We w= ill likely someday need to deploy a new cryptosystem to replace ECC as a da= ily driver if ECDLP is broken, whether classically or by a CRQC. When/if th= is happens, we'll be REALLY glad we added hash-based sigs first, becaus= e then we'll have something to use if the novel scheme's assumption= s (or more likely, implementation) are broken.

This is not to say we shouldn't be researching lattices. Or isogeni= es, or anything else for that matter. We need to know what's possible, = and to educate the community about the options we have. I'm glad to see= Blockstream funding this important work. I view hash-based sigs as the fir= st episode of a decades-long saga, but unfortunately we lack enough knowled= ge to know what should come next. Maybe that is lattices? maybe something e= lse. With time, effort, and (hopefully) funding, we shall find out.

If I had to pen a wishlist of stuff I'd like to see from lattice cr= ypto research, this would be it:

- [ ] compact keys and sigs. Ideally, less than a kilobyte witness size= total, but I'd be happy with at least a twofold improvement over what = stateless hash-based sigs can offer.
- [ ] rerandomization e.g. BIP32 unhardened derivation. This has been d= one [1], but AFAIK it is impossible without massively expanding the sizes o= f keys and/or signatures.
- [ ] a multisignature scheme, or a threshold protocol with a DKG. Agai= n, never seen this without massive keys and sigs, but I see no reason why i= t should be impossible.
- [ ] integer-only arithmetic. Falcon keys and sigs are smaller than ML= -DSA, but it comes at the expense of complex floating point arithmetic head= aches. It'd be nice if we could do away with that.
- [ ] signature aggregation. This is a more general wish of any PQ sche= me, and if someone can do it, even with somewhat large sigs or poor perform= ance, it might make the whole scheme way more palatable, in tandem with a C= ISA proposal.

Also see this relevant delvingbitcoin thread [1] for more sources.

regards,
conduition

[0]: https://conduition.io/code/fast-slh-dsa-verification/
[1]: https://d= elvingbitcoin.org/t/post-quantum-hd-wallets-silent-payments-key-aggregation= -and-threshold-signatures/1854/

On Tuesday, May 19th, 2026 at 9:06 PM, Nikita Karetnikov <nik...@karetnikov.org> wrote:

> Dear list,
>=20

> I hate to contribute to the recent flood of PQC posts, but I think= it=E2=80=99s an important issue that=E2=80=99s worth discussing.
>=20

> In particular, what I usually see is various competing proposals w= ithout a clear winner.
>=20

> So I=E2=80=99d like to bring everyone=E2=80=99s attention to this = new post from Blockstream:
> https://blog.blockstream.com/schnorr-but-with-vectors-lattice= -based-signatures-explained/
>=20

> This post is interesting because unlike a lot of PQC discussions, = it actually includes a comparison table of various approaches, where lattic= es seem to come out ahead.
>=20

> This raises a few questions.
>=20

> Since lattices are not a new topic in cryptography, why has Blocks= tream focused their efforts on hash-based approaches so far?
> Are hashes seen as a more conservative choice?
>=20

> Given the problems with hashes outlined in the post, are lattices = actually the current most likely candidate for a PQC implementation?
> If so, should the community effort be focused on lattices instead = of other proposals?
> Or is the comparison table not telling the whole story?
>=20

> I=E2=80=99d like to hear your thoughts on the topic.
>=20

> Thanks,
> Nikita
>=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+...@= googlegroups.com.
> To view this discussion visit https:/= /groups.google.com/d/msgid/bitcoindev/ffa56d63-32c6-4fc3-a150-4fe62ac2e00b%= 40app.fastmail.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/bitcoind= ev/eeefdd9a-bb4b-43b7-b547-90d865e31a32n%40googlegroups.com.
------=_Part_1615133_1691793598.1779271002156-- ------=_Part_1615132_39707432.1779271002156--