From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 20 May 2026 04:52:07 -0700 Received: from mail-oa1-f56.google.com ([209.85.160.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 1wPfT3-0005Ux-Fz for bitcoindev@gnusha.org; Wed, 20 May 2026 04:52:07 -0700 Received: by mail-oa1-f56.google.com with SMTP id 586e51a60fabf-4346755f7dcsf8165794fac.3 for ; Wed, 20 May 2026 04:52:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1779277915; x=1779882715; 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=/aXXrTUnavhiItnwsv00QrwHjHjtTafFHC+jjLnxWDk=; b=PS5TbnVv57nNHJ1ZoQAIfTBp8rvHQCM4iPgJe35/XGVxCTGofeCc6S5VYbrJDVeS8i yIbQpghuHClQP2hw6WR+i+u+RwYE6MPTd1oX+TB7h8CGZNFr/9SBKCu0rFTRzLI0E+mb GjUMeqoYAN7/TY+n4uCUrTmj+b8BjH6/aKPLuD8N0Pl0E5BH573KKe3hY+PiUHNcQ3V9 vaSY8+K9mWZ0l3G/60Qc4xj8sLH71dd58QAVSXRRl8KG+za1dQnwRwLHVBwncHl4937x gC8iWaFxtMBjQtwl1W2l6hBpvGsn5VdSxQGziYQaFVOYcy2bV456cntFVl79b4gb1J8Y NrrQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779277915; x=1779882715; 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=/aXXrTUnavhiItnwsv00QrwHjHjtTafFHC+jjLnxWDk=; b=R5C47kj/gPBLTAm7osELEtmT24VvIPN1EVFaUc+2qpR8ddKBmeBSyWf9J+vCPTFMuX WVQVE3BKsr4rrB3u+OIIB39OdljNcqQjua8XZu3R264Vo8jOy8lpsGJmTBm2awgc4dGu 1G4mkbILwmATkEmPfoLWdgUWijR72bnK4pv4Y1BNDewvObP3I9TNzGHt6O3AuTcQWcDg KWAeC4iEjYvQTjNnzTsTrGqLZ/iwXkuGR77u3kWXgwZt5gOlF9LgJ52iLEa5BUYZJpz0 jCyW8l1p9MUWH6f778QNIisNmcM66uOjIVFC03w9vmG4Y5MEVau7MOfjizntljPv0MDt AeNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779277915; x=1779882715; 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=/aXXrTUnavhiItnwsv00QrwHjHjtTafFHC+jjLnxWDk=; b=rTYiltZGugKie8s0l8ej0JX7as3skdKIq/g+P3+dAC/cICClwUDasUaHcwD4IhFrlT kNzcQFRzi2VsM2Y0ltyQrsLpTFt73TEfX+h7lGtCXNCHZN3/HLkmPUgRFm+h3RirT/Ms ttdFkgo+Nvi6rZ+0l9kvl/NQZSJ1mBrYnZ4n3EpCgAtiuoIrj6vR6cQ3U9mlizhLfaUa 6Vtd8elRNqmRCsjr2pasHP5PxJGQA+J3IHewyq6SSDVtXHENi+1XtGua7RDz9SMBhRaJ f86MPzfFL+Noo/+WhBsDfOscWRUz29o8VOVT5oziRWOYXXPmlj31noyAkAVUF9L7zkZp 1G+Q== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AFNElJ/1+Lz1y+Mw7cUuj9cMBR7G7mepWVx/Kti096dLIMKntZQFvCoYZrpTTtqRWsFX2/x+qg5p3OethHfm@gnusha.org X-Gm-Message-State: AOJu0YxHUQStf6RFeZH4QvgAG2stitexHWpebM8+vI06Aa2TS57ETmpa IA6LyYTYEo7pexq13fxCuvdZMq+zNjnwopbpRGvaAUjMEeXbEPJO3f/f X-Received: by 2002:a05:687c:20c8:b0:423:7f5:1a6 with SMTP id 586e51a60fabf-43a2de221b7mr15488082fac.30.1779277915269; Wed, 20 May 2026 04:51:55 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AUV6zMNBaRy8JYesSl49jygpazMa6ndjn89WebUFtbqRJVPcLw==" Received: by 2002:a05:6870:1606:b0:439:b6fe:4488 with SMTP id 586e51a60fabf-43a01ebc7fels7173538fac.2.-pod-prod-05-us; Wed, 20 May 2026 04:51:49 -0700 (PDT) X-Received: by 2002:a05:6808:148e:b0:482:462e:6a8b with SMTP id 5614622812f47-482e572be3cmr15429420b6e.28.1779277909449; Wed, 20 May 2026 04:51:49 -0700 (PDT) Received: by 2002:a05:690c:4507:b0:7b3:13f7:5f3a with SMTP id 00721157ae682-7c698ddb9c3ms7b3; Wed, 20 May 2026 03:35:52 -0700 (PDT) X-Received: by 2002:a05:690c:e041:b0:7b3:edc7:9bb8 with SMTP id 00721157ae682-7c955b970femr219918777b3.0.1779273351852; Wed, 20 May 2026 03:35:51 -0700 (PDT) Date: Wed, 20 May 2026 03:35:51 -0700 (PDT) From: Alex To: Bitcoin Development Mailing List Message-Id: <38c3ad3e-2358-49c9-be92-ae6d34ac45bbn@googlegroups.com> In-Reply-To: References: Subject: Re: [bitcoindev] PQC: Lattice-based signatures MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1620878_1973998259.1779273351236" 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_1620878_1973998259.1779273351236 Content-Type: multipart/alternative; boundary="----=_Part_1620879_2136842331.1779273351236" ------=_Part_1620879_2136842331.1779273351236 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Hash based signatures are incredibly conservative. Yes exactly. Hash based signatures like SHRINCS (324 byte signatures) are= =20 basically abstractions above the hash function (SHA256) which is already a= =20 security assumption (it already must protect block integrity and Merkle=20 trees). This means, if SHA256 is weakened and needs replacing, technically= =20 you could introduce SHA3 without needing to change anything above it (like= =20 SHRINCS). So hash based signatures are incredibly "forwards compatible"=20 abstractions. This is not the case for new signature algorithms which otherwise would be= =20 ideal (like SQIsign). And since Bitcoin is mainly battling conservative=20 forces, pushing for a conservative fix (hash based signatures) is far more= =20 likely to reach consensus (in my estimation). onsdag 20 maj 2026 kl. 12:04:00 UTC+2 skrev Mikhail Kudinov: > > 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.=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/= 38c3ad3e-2358-49c9-be92-ae6d34ac45bbn%40googlegroups.com. ------=_Part_1620879_2136842331.1779273351236 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable >=C2=A0 Hash based signatures are incredibly conservative.

Yes exactly. = Hash based signatures like SHRINCS (324 byte signatures) are basically abst= ractions above the hash function (SHA256) which is already a security assum= ption (it already must protect block integrity and Merkle trees). This mean= s, if SHA256 is weakened and needs replacing, technically you could introdu= ce SHA3 without needing to change anything above it (like SHRINCS). So hash= based signatures are incredibly "forwards compatible" abstractions.
This is not the case for new signature algorithms which othe= rwise would be ideal (like SQIsign). And since Bitcoin is mainly battling c= onservative forces, pushing for a conservative fix (hash based signatures) = is far more likely to reach consensus (in my estimation).
onsdag 20 maj 2026 = kl. 12:04:00 UTC+2 skrev Mikhail Kudinov:

The floating-point arithmetic of Falcon ca= n be solved with integer simulation. This makes the algorithms less efficie= nt, but still more 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 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/38c3ad3e-2358-49c9-be92-ae6d34ac45bbn%40googlegroups.com.
------=_Part_1620879_2136842331.1779273351236-- ------=_Part_1620878_1973998259.1779273351236--