From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 20 May 2026 13:47:20 -0700 Received: from mail-oa1-f57.google.com ([209.85.160.57]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wPnp1-0001eY-2k for bitcoindev@gnusha.org; Wed, 20 May 2026 13:47:19 -0700 Received: by mail-oa1-f57.google.com with SMTP id 586e51a60fabf-4398773e510sf6958296fac.3 for ; Wed, 20 May 2026 13:47:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1779310033; x=1779914833; 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=YxLL6DNjdUE0tARxcQDSxpfNaQ6M8SLpCi50XML9p1A=; b=I+s9HlY3iv9WaM+UrL+LwCGuEnklor4bBjrTlwNW49jqYc0xk8DtX+hyF98uCF7fib U3fuRM1P8RMVlOuf3Qqgw7pAnADFxRsCs+1Uil8bmzGddActhtgp2oHIQsZuRsrvJOR0 8bFE+KhtG6yz7SNrKunRg3/LrnenOY5yiz816GVOrFmYdqLaeD3uNDotvi1cuYTFxksB eAwhYigoXvuhTSYsdezS2ACKJ1+bCn2y+700MdBd7rNSoGdz3zeFsR1kaVsWT2Q3zAVt 3WJO9rdNdd0SjvZwBHzI86qMqR5DMlwtd2X7Lhp0CmiYemxR1hEQxokSPTNmkaA3Er2Z laEg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779310033; x=1779914833; 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=YxLL6DNjdUE0tARxcQDSxpfNaQ6M8SLpCi50XML9p1A=; b=YvHXltNWOoj5sVANYE1/h5mFXQPnH3KNhTLWLhhdGK2KuT2CCq3yPz1PR/HGLkQb21 QYtUtJdVoaYQKPFXRoUs8LjXrGKV6+QCvm2t9ped+nVNgrAqzIlauuB57hqSvtxNnGK9 ilmzXRGsVZ0FUPAtEBlJQFJHz8XoibhH1Gn+gBJWkOyGH3n6LNKXOtA5eSLWol3RiiYq bme/SwgKOlatWBqhlOaGwldrTf8Xvd5gRW1DByXmMn8BkCYDDTlCm2DbzziN6OzGODm2 P1OU3RtWl26ho9YsoDxKm5Pz7xpv0Z5qM6JHkft/JQ4cH0YqUYK+U6d254wyDefOF7aQ ASog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779310033; x=1779914833; 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=YxLL6DNjdUE0tARxcQDSxpfNaQ6M8SLpCi50XML9p1A=; b=MQzKzTyq+g7QD/+VCbB/j13G74ZQ4AOl1sROr1mTmlD0NYjBT94ITk30Et0BD+I6Ox NyozoTPzdLs/yv5iCi0RqR16xxTEhRfG49UH6YwBL1lDWo5vgJl7bwOnX5kHVBNRBWC5 A2JJ50qHnM6QKWD09lIHAcymZEidjV+06iWbwv0YVV3rhMgvmGBzbBxhqJdvc2j9+REV 8DryaX9j8t6n9B4WqYs4LoPJgqzGzXq7UteuRcPpvR8j9Jra7zjFq/OL7qZgLOQnF/bD 97Q3sskqGCPD9yxKIPIYuv0u9JrkJVLkJVpjp2/IMVtsoW3VQN7c25MKAD414u3AlQ3C mLew== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AFNElJ9cZwZYAolzb2A8xmcPfyvmzb7US14UUy2qhuOSTfWR2TzXup3R4GsAyrOKDnHBT6p/1IW+0IhUtbLl@gnusha.org X-Gm-Message-State: AOJu0YygxpIOv/gzA2yziNRSLK5eUIp1KACjif0tv0+oV6X9Upowq+bH zRJNQEsbcs+CHNCA//1f8OGx7kgO3vT1jNNtIe35HZZ1ZWjnkbXChsPd X-Received: by 2002:a05:6870:b41a:b0:430:29c3:9d15 with SMTP id 586e51a60fabf-43b2e77836dmr153815fac.1.1779310032980; Wed, 20 May 2026 13:47:12 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AUV6zMNWLGDv/gwYENGmBEvHdpko3xJ05wxaicDNqR58AcNwkg==" Received: by 2002:a05:6870:2b07:b0:439:f2e3:b9c5 with SMTP id 586e51a60fabf-43a01f9acf3ls3736779fac.2.-pod-prod-04-us; Wed, 20 May 2026 13:47:08 -0700 (PDT) X-Received: by 2002:a05:6808:1307:b0:467:2509:c20a with SMTP id 5614622812f47-482e596eefemr19667985b6e.47.1779310028276; Wed, 20 May 2026 13:47:08 -0700 (PDT) Received: by 2002:a05:690c:6202:b0:7ba:f1b3:9504 with SMTP id 00721157ae682-7c6993cf1f6ms7b3; Wed, 20 May 2026 10:58:25 -0700 (PDT) X-Received: by 2002:a05:690c:89:b0:7cf:d242:d963 with SMTP id 00721157ae682-7cfd242e3d0mr77691097b3.37.1779299904839; Wed, 20 May 2026 10:58:24 -0700 (PDT) Date: Wed, 20 May 2026 10:58:24 -0700 (PDT) From: Isabel Foxen Duke To: Bitcoin Development Mailing List Message-Id: <42faeb16-5d01-41ba-a192-e05936b84248n@googlegroups.com> In-Reply-To: References: Subject: Re: [bitcoindev] PQC: Lattice-based signatures MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1658222_132525510.1779299904207" X-Original-Sender: isabel.duke@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_1658222_132525510.1779299904207 Content-Type: multipart/alternative; boundary="----=_Part_1658223_789377875.1779299904207" ------=_Part_1658223_789377875.1779299904207 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable FWIW =E2=80=94 "I would actually like to push for lattice-based signatures..." says Dan=20 Boneh in new interview=20 out this morn= ing=20 (1:11:00) He primarily cites algebraic structure as allowing greater functionality -= =20 and is concerned that features like threshold signature schemes will be=20 much harder to implement with hash-based signatures.=20 -Isabel Foxen Duke On Tuesday, May 19, 2026 at 8:27:40=E2=80=AFPM UTC-7 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/= 42faeb16-5d01-41ba-a192-e05936b84248n%40googlegroups.com. ------=_Part_1658223_789377875.1779299904207 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable FWIW =E2=80=94

"I would actually like to push for lattice-based = signatures..." says Dan Boneh in new interview=C2=A0out this morning (= 1:11:00)

He primarily cites algebraic structure as allowing grea= ter functionality - and is concerned that features like threshold signature= schemes will be much harder to implement with hash-based signatures.=C2=A0=

-Isabel Foxen Duke

On Tuesday, May 19, 2026 at 8:27:40=E2=80= =AFPM UTC-7 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/42faeb16-5d01-41ba-a192-e05936b84248n%40googlegroups.com.
------=_Part_1658223_789377875.1779299904207-- ------=_Part_1658222_132525510.1779299904207--