From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 22 May 2026 06:46:21 -0700 Received: from mail-oa1-f58.google.com ([209.85.160.58]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wQQCi-0008Gk-0z for bitcoindev@gnusha.org; Fri, 22 May 2026 06:46:20 -0700 Received: by mail-oa1-f58.google.com with SMTP id 586e51a60fabf-43b73cd2c76sf263885fac.2 for ; Fri, 22 May 2026 06:46:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1779457574; x=1780062374; 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=SekkIrVQJlzh/OicnsgIXxOYi1V3if63S9K1S1zzzaU=; b=UmYwanpphWrmiz1iE+pR081vyD+Ba01ahK685OqXF/o1tXs3RLCV26GiGJvfQ6+ZNc 4AvjxpbSu6z0FHCbF4UvijiB3sPAsmu35jsHixnT4srPXvJ1xmrI1BZ8aH6RGegNKYNw AfJ4RHABbupGEfcgYRWIhi9NltGCiX07snnPnkWr/Bt+LSOmPSIxO9DToHYt5jwVuWe0 Y9t58JEAKQQNUwHLkzhqzzZDBcy0ZIkIIlHHlhbTTavGY90IKtbBm0AFsCExsgPvU/BO HEm7gTdKu0ryk3fsxrDUvK81FDOorbQii+jjG3apBNyjx+qZ7VTmfIfFhJsPkpwAaLZ+ ZOUw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779457574; x=1780062374; 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=SekkIrVQJlzh/OicnsgIXxOYi1V3if63S9K1S1zzzaU=; b=kPSEZx/aRu9QSFmvgFb6MNWcXhNWzBeaO+sHAm5zguIhD3yUPnvGsJwQHOOm8HElOg K83LuSLzq9898ICTq8hlxXANAHo9flD516lO02FuHIsUJvpmgymcFbA+RZvmkWfN3sCi PD+SibaMY+hSsSJlT9FcrVnBlOpQIley8rUwOZi/i8mMCIN1u7lL0MZzoJIoeAKVPvy5 nXjAJq5ONbXG4E+HZX5SdQ5WPVauLs9daQvhMYRLqvlJiEI9HOtOS/6N8SC2g5fORoHB rpXHP6mZy8WBnZYHE+mhlHwMYb1FljzRTtT68kEiWyfQilPK4bJnQbKF1RvIOAas8E07 hWdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779457574; x=1780062374; 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=SekkIrVQJlzh/OicnsgIXxOYi1V3if63S9K1S1zzzaU=; b=iKxwtH2/6ipyKEdq4KJX9ciYwNn+RO3yaHd1x9f7s/qbhB/lTRbYxRWZV9/in0eLpk 1X3phEeFoOHsk2C/8u+kMvsVDinee/PsHhdVpSqzWVeb3PJRrKhWkg+CwPBTFwT4nUbv UDkNEmw1gTVYf6yWGjzKmVTsL13nLq52Ny8birZmoLpYZCbpbIhNolS3feXmCjeTnAa2 05FPkkkmDbK4/tFnLvSNIrLFsros67fQxiabdxpTwq0tk3l4f8Vqww/rDtW8IG6wGMV5 Aalmz3yWWp/TnEyfLEv2eutkkg9zo2TQO/YkNKpvwVi95UTaiV+F29IW3FXQRZdtHUn6 4K1g== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AFNElJ88V1q8u4G0NZb/in5Mb9SxBlqZlgVyMAKt5jc0TydPDNfysU11wRF/0nsV4ymxBFvMLzt/GnaYHRbU@gnusha.org X-Gm-Message-State: AOJu0YxsNQSktJQKpWSr3k8Y523iH9amQLUKyBTgV7KYL4/7R8MLYGHJ knBLaQxS6tuAibPY/gl8/r4n7M2Qs5UFuLN151v7pt4EVVLEF0yI7nfZ X-Received: by 2002:a05:6871:7c02:b0:422:ff63:9a6 with SMTP id 586e51a60fabf-43b5af45719mr2097376fac.34.1779457573755; Fri, 22 May 2026 06:46:13 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AUV6zMPbIMvMK3QqTr5nwCUlJDKIycs9xw5A9mspfM3SQ0+rbw==" Received: by 2002:a05:6870:1606:b0:439:b6fe:4488 with SMTP id 586e51a60fabf-43a01ebc7fels9184211fac.2.-pod-prod-05-us; Fri, 22 May 2026 06:46:08 -0700 (PDT) X-Received: by 2002:a05:6808:4fe6:b0:485:29d7:70a8 with SMTP id 5614622812f47-4854a3af9femr2076064b6e.41.1779457567939; Fri, 22 May 2026 06:46:07 -0700 (PDT) Received: by 2002:a05:690c:3612:b0:7b3:13f7:5f3a with SMTP id 00721157ae682-7d368c2044ems7b3; Thu, 21 May 2026 13:15:39 -0700 (PDT) X-Received: by 2002:a05:690c:3692:b0:7bd:5af9:f0a1 with SMTP id 00721157ae682-7d33a25b62fmr9423547b3.25.1779394538766; Thu, 21 May 2026 13:15:38 -0700 (PDT) Date: Thu, 21 May 2026 13:15:38 -0700 (PDT) From: Voltairine To: Bitcoin Development Mailing List Message-Id: In-Reply-To: <42faeb16-5d01-41ba-a192-e05936b84248n@googlegroups.com> References: <42faeb16-5d01-41ba-a192-e05936b84248n@googlegroups.com> Subject: Re: [bitcoindev] PQC: Lattice-based signatures MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_4472_1313276774.1779394538151" X-Original-Sender: decleyrevoltairine7@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_4472_1313276774.1779394538151 Content-Type: multipart/alternative; boundary="----=_Part_4473_300503958.1779394538151" ------=_Part_4473_300503958.1779394538151 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Emily, Many would agree that lattice-based schemes are preferable in nearly every= =20 way to the rather impractical hash-based schemes. Still, the algebraic=20 structure of modules over polynomial rings falls well short of offering the= =20 functionalities bitcoin users would most wish to see retained. Perhaps you= =20 could say more about the particular advantages you perceive these=20 structures bringing to bitcoin?=20 cordially, V On Wednesday, May 20, 2026 at 2:47:13=E2=80=AFPM UTC-6 Isabel Foxen Duke wr= ote: > FWIW =E2=80=94 > > "I would actually like to push for lattice-based signatures..." says Dan= =20 > Boneh in new interview=20 > out this=20 > morning (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.=20 >> >> I can't speak for Blockstream, but as to the spirit of your question -= =20 >> Why people are looking at hash-based sigs more than lattices - I can thi= nk=20 >> of four major reasons:=20 >> >> 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.=20 >> >> 2. Simplicity. Hash-based signatures are easier to grasp, simpler to=20 >> prove secure, and easier to implement compared to almost anything else= =20 >> (even simpler than ECC). We Bitcoiners tend to clutch our pearls in fear= of=20 >> trusting flawed assumptions... but in reality most vulnerabilities are n= ot=20 >> cryptographic in nature: Most are implementation failures. Hash-based si= gs=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.=20 >> >> 3. Efficiency. Hash-based sigs are surprisingly fast to verify [0]. Thei= r=20 >> cost-per-byte is way lower than Schnorr. If you can bite the statefulnes= s=20 >> bullet, hash-based sigs can even be compact (and still fast). There rema= ins=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.=20 >> >> 4. Future-proofing. Because of their conservatism, hash-based sigs stand= =20 >> a better chance of remaining secure over a long time-frame, so it seems= =20 >> more likely we could rely on them to fulfill a long-term fallback role. = We=20 >> will likely someday need to deploy a new cryptosystem to replace ECC as = a=20 >> daily driver if ECDLP is broken, whether classically or by a CRQC. When/= if=20 >> this happens, we'll be REALLY glad we added hash-based sigs first, becau= se=20 >> then we'll have something to use if the novel scheme's assumptions (or m= ore=20 >> likely, implementation) are broken.=20 >> >> This is not to say we shouldn't be researching lattices. Or isogenies, o= r=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 fin= d=20 >> out.=20 >> >> If I had to pen a wishlist of stuff I'd like to see from lattice crypto= =20 >> research, this would be it:=20 >> >> - [ ] 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.=20 >> - [ ] rerandomization e.g. BIP32 unhardened derivation. This has been=20 >> done [1], but AFAIK it is impossible without massively expanding the siz= es=20 >> of keys and/or signatures.=20 >> - [ ] 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 i= t=20 >> should be impossible.=20 >> - [ ] 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.=20 >> - [ ] signature aggregation. This is a more general wish of any PQ=20 >> scheme, 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 tande= m=20 >> with a CISA proposal.=20 >> >> Also see this relevant delvingbitcoin thread [1] for more sources.=20 >> >> regards,=20 >> conduition=20 >> >> [0]: https://conduition.io/code/fast-slh-dsa-verification/=20 >> [1]:=20 >> https://delvingbitcoin.org/t/post-quantum-hd-wallets-silent-payments-key= -aggregation-and-threshold-signatures/1854/=20 >> >> On Tuesday, May 19th, 2026 at 9:06 PM, Nikita Karetnikov < >> nik...@karetnikov.org> wrote:=20 >> >> > Dear list,=20 >> >=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 >> >=20 >> >> > In particular, what I usually see is various competing proposals=20 >> without a clear winner.=20 >> >=20 >> >> > So I=E2=80=99d like to bring everyone=E2=80=99s attention to this new = post from=20 >> Blockstream:=20 >> >=20 >> https://blog.blockstream.com/schnorr-but-with-vectors-lattice-based-sign= atures-explained/=20 >> >=20 >> >> > This post is interesting because unlike a lot of PQC discussions, it= =20 >> actually includes a comparison table of various approaches, where lattic= es=20 >> seem to come out ahead.=20 >> >=20 >> >> > This raises a few questions.=20 >> >=20 >> >> > Since lattices are not a new topic in cryptography, why has Blockstrea= m=20 >> focused their efforts on hash-based approaches so far?=20 >> > Are hashes seen as a more conservative choice?=20 >> >=20 >> >> > Given the problems with hashes outlined in the post, are lattices=20 >> actually the current most likely candidate for a PQC implementation?=20 >> > If so, should the community effort be focused on lattices instead of= =20 >> other proposals?=20 >> > Or is the comparison table not telling the whole story?=20 >> >=20 >> >> > I=E2=80=99d like to hear your thoughts on the topic.=20 >> >=20 >> >> > Thanks,=20 >> > Nikita=20 >> >=20 >> >> > --=20 >> > You received this message because you are subscribed to the Google=20 >> Groups "Bitcoin Development Mailing List" group.=20 >> > To unsubscribe from this group and stop receiving emails from it, send= =20 >> an email to bitcoindev+...@googlegroups.com.=20 >> > To view this discussion visit=20 >> https://groups.google.com/d/msgid/bitcoindev/ffa56d63-32c6-4fc3-a150-4fe= 62ac2e00b%40app.fastmail.com.=20 >> >> >=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/= b3988d19-b1b8-49ed-82c5-1447f37bf473n%40googlegroups.com. ------=_Part_4473_300503958.1779394538151 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Emily,

Many would agree that lattice-bas= ed schemes are preferable in nearly every way to the rather impractical has= h-based schemes. Still, the algebraic structure of modules over polynomial = rings falls well short of offering the functionalities bitcoin users would = most wish to see retained. Perhaps you could say more about the particular = advantages you perceive these structures bringing to bitcoin?=C2=A0

cordially,
V
On Wednesday, May 20, 2026 at 2:47:13=E2=80=AFPM UTC-6 Isab= el Foxen Duke wrote:
FWIW =E2=80=94

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

He primarily cites a= lgebraic structure as allowing greater functionality - and is concerned tha= t features like threshold signature schemes will be much harder to implemen= t 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/b3988d19-b1b8-49ed-82c5-1447f37bf473n%40googlegroups.com.
------=_Part_4473_300503958.1779394538151-- ------=_Part_4472_1313276774.1779394538151--