From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 23 May 2026 06:49:29 -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 1wQmjI-0007dx-09 for bitcoindev@gnusha.org; Sat, 23 May 2026 06:49:29 -0700 Received: by mail-ot1-f55.google.com with SMTP id 46e09a7af769-7e60b15b7dbsf3007171a34.1 for ; Sat, 23 May 2026 06:49:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1779544162; x=1780148962; 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=ya9lZLsg2d3+iCZGf0d7GfNwh4i7nvUz8F1nnYtDHm0=; b=eAdJ/cAwtVk0Tz9tnSlYovDr3Ph/LrV0jGZYA+JWNJXO3Ilsp5IE9EaKplVojwzKBL 6BDr0QbXJ15AwiWWTR8lxl4wmyD7EW/E2zLc35NEYUwhuBUOGcyMi3VwD4/n36VQSYUy HThIs9e15VMoPSow7aXmxJvrxfT/6dstN7KT+FDru4JnubfgNzkMfUvMMBBoUUGhTYHr ewjoz+iqPlt7iEuMODGCI34ieB7Ci+BhVKIoFM83lgloVbwe6WBxvGWQ66TQY0zM+OCr S+q+uQthIogDcgsa7BNZJGTobCfleCNgMAM7zxmkEcKIG+wUcVGg56LuIfV0ce5rI5c0 ThIw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779544162; x=1780148962; 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=ya9lZLsg2d3+iCZGf0d7GfNwh4i7nvUz8F1nnYtDHm0=; b=rOy5IKFrBzm7dNYpeYi60q/7UEVOY1RCAyqU6Bbzbik4BffFYhd469nXaan89Y8e2r kz8lKAcbTSTt3TXjAuc/ss1O3s24q6Ax2C/04L9qCtbSGWisAzo3oC7Kf+6B36j2G2GV N5pP6Wq13T1jk+BKSNNWPrh1segJc+5tDY1D+wa0747JqubcXmcg2LZbBH2LsHovN1bW cu2XE5Fs426UBIWihgwA/vgiZ0cW1uuLTlLldYbtOFpKxpA7myAzVKxjCtT1Ofm6FIsn +DcFs9qJL64rl2c8QXZJ2sz8GmdXv4sngzDEq0zE6/LVCn9zwEAR+GUWfm0ZH+ppzsIT UHeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779544162; x=1780148962; 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=ya9lZLsg2d3+iCZGf0d7GfNwh4i7nvUz8F1nnYtDHm0=; b=LmMEVZvgBS3+hSuHGr5RwxVUs/Trpu802Vm17U9FiScsCq783PH6IAD/Zd95gj2uPI wehHEVO/xJrhjMd6dJFoCqXJv2n9COB5y724lt2iFQDdEIGYZs5olTIVQbKlqCx4KArn +Oo7dj+iOdVkISqMum27KGJzjkzx9ZXwrM3j//+iKfApHLKUwLzEVjp764Pab7iHTJh4 Fvq9vgn5e9DixbaOb+yo6YVkNlHA3z74rumLfn/wyJ5E/Nyw12pVu7vvGErA92zf8h9o a4l/Ay4EVUtDpSZwoG1K8ElF85UpOXvKI34K3biBz6tg0LB+Aa/BXsgNdeOX85nnL5ON WorA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AFNElJ9Q5KWaFNa0QZo/e6/8JhHxvgFtMtao80Gzgw2UnialJjLYoc97Ps0tBfbZBWTu7Ehf1kbt0m79z1qt@gnusha.org X-Gm-Message-State: AOJu0YyJIGXx5zw8kquNWS9CahCKtrJ5y3Vj8IhwslifLOe1at3eugwM NZhWcAViiPoyvHxiZy+8arZ/15eRwSXsSFPzs4ITC6owxe48XsEiiu7j X-Received: by 2002:a05:6820:1ca9:b0:69d:7b21:14bc with SMTP id 006d021491bc7-69d7fa8fd95mr3401501eaf.5.1779544161553; Sat, 23 May 2026 06:49:21 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AUV6zMPMl+ALw00o/ZpZYfMR56DofMtxadju8hXCRDi3RT+p8A==" Received: by 2002:a05:6820:1c8d:b0:696:924d:2958 with SMTP id 006d021491bc7-69d707468cdls1555098eaf.2.-pod-prod-06-us; Sat, 23 May 2026 06:49:15 -0700 (PDT) X-Received: by 2002:a05:6808:c1fb:b0:479:f526:a148 with SMTP id 5614622812f47-4854a29e67emr5279711b6e.25.1779544154860; Sat, 23 May 2026 06:49:14 -0700 (PDT) Received: by 2002:a05:690c:3612:b0:7b3:13f7:5f3a with SMTP id 00721157ae682-7d368c2044ems7b3; Sat, 23 May 2026 06:48:04 -0700 (PDT) X-Received: by 2002:a05:690c:660c:b0:7d1:dd7b:b71f with SMTP id 00721157ae682-7d3379ab714mr87472967b3.29.1779544083452; Sat, 23 May 2026 06:48:03 -0700 (PDT) Date: Sat, 23 May 2026 06:48:02 -0700 (PDT) From: Isabel Foxen Duke To: Bitcoin Development Mailing List Message-Id: In-Reply-To: <3975ff59-50f0-4001-bcfb-f1f444873d22n@googlegroups.com> References: <42faeb16-5d01-41ba-a192-e05936b84248n@googlegroups.com> <673BCz5V_RyCwtNI8IxXeDdauWVmQm9MTvtZ97_2ADXzWZNT9bLJsTx1fli-PEb1-cNIi4nCCS-BIsDP1GBMaldfMSWGBHDKl7bFZWf7T6U=@proton.me> <3975ff59-50f0-4001-bcfb-f1f444873d22n@googlegroups.com> Subject: Re: [bitcoindev] PQC: Lattice-based signatures MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_236048_611341273.1779544082798" 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_236048_611341273.1779544082798 Content-Type: multipart/alternative; boundary="----=_Part_236049_272819468.1779544082798" ------=_Part_236049_272819468.1779544082798 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Conduition,=20 Nevermind on the hybrid scheme question -- Jonas explained in this thread= =20 that hybr= id=20 scheme is likely something that would happen on the wallet level (not=20 consensus/opcode level), so this is now clarified on my end - thanks again= =20 for all your help! x Isabel On Friday, May 22, 2026 at 8:25:41=E2=80=AFAM UTC-7 Isabel Foxen Duke wrote= : > Hi Conduition, > > So glad you enjoyed the interview=20 > ! I'm thrilled D= an=20 > is speaking on quantum-issues more publicly these days :) > > Noted about threshold signatures and other features potentially being onl= y=20 > theoretical and not truly practical with Lattice based signatures. I will= =20 > bring this up with Dan and see if he has any comment here - or if he has= =20 > updates that may affect thinking on this. =20 > > I'm curious to get your thoughts on the following: it sounds like Dan is= =20 > advocating for a hybrid scheme and I'm wondering if this would render the= =20 > strategy of implementing different signatures at different times less=20 > practical? In other words, does it still make sense to implement somethin= g=20 > like SHRINCS *before* a lattice-based signature =E2=80=94 if we're ultima= tely=20 > hoping to implement a single hybrid scheme as Dan proposes here=20 > ?=20 > > thanks for all your hard work on this=20 > > Warmly, > Isabel Foxen Duke > > On Thursday, May 21, 2026 at 12:29:21=E2=80=AFPM UTC-7 conduition wrote: > >> Hey Isabel, I watched the interview, very cool stuff. I loved seeing Dan= =20 >> dodge your question about the mysterious "restrictions" google was under= =20 >> (hello NSA).=20 >> >> Dan is right that lattice-based crypto offers the *promise* of algebraic= =20 >> structure, whereas hash-based crypto offers none. Having open research= =20 >> avenues towards goals like threshold signatures is a great thing. Yet=20 >> the promise of the algebraic structure in lattices hasn't materialized i= nto=20 >> anything usable. At least, there are no schemes - yet - which tick the= =20 >> boxes we need. At best we have *hope *for future developments. Lattice= =20 >> threshold and key-rerandomization schemes will likely improve from where= =20 >> they are now, but until proven otherwise we should make choices about=20 >> consensus based on what we have, not what we *hope* we will have someday= . >> >> Also, in the interview Dan acted as though deploying hash-based=20 >> signatures would preclude the deployment of lattice crypto later. It=20 >> doesn't. If we deploy a more cutting-edge cryptosystem like HAWK or=20 >> SQIsign, it will be once we have a suitably flexible and compact schemes= =20 >> ready to build atop it, and when that happens we will still be glad to h= ave=20 >> hash-based crypto as a backstop in case the cutting-edge assumptions (or= =20 >> implementations) are busted. >> >> regards, >> conduition >> On Wednesday, May 20th, 2026 at 3:47 PM, Isabel Foxen Duke < >> isabe...@gmail.com> wrote: >> >> 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 b= e=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 th= ink=20 >>> of four major reasons:=20 >>> >>> 1. Conservatism. Hash based signatures are incredibly conservative. The= y=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, an= d=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 fea= r of=20 >>> trusting flawed assumptions... but in reality most vulnerabilities are = not=20 >>> cryptographic in nature: Most are implementation failures. Hash-based s= igs=20 >>> are harder (but not impossible) to screw up. An experienced engineer ca= n=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].=20 >>> Their cost-per-byte is way lower than Schnorr. If you can bite the=20 >>> statefulness bullet, hash-based sigs can even be compact (and still fas= t).=20 >>> There remains some hope we might be able to use them as a daily driver = if=20 >>> CRQCs appear faster than anticipated. This efficiency comes at a price = of=20 >>> course, but that price is paid by the signer implementation while verif= iers=20 >>> remain slim, quick, and secure.=20 >>> >>> 4. Future-proofing. Because of their conservatism, hash-based sigs stan= d=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, beca= use=20 >>> then we'll have something to use if the novel scheme's assumptions (or = more=20 >>> likely, implementation) are broken.=20 >>> >>> This is not to say we shouldn't be researching lattices. Or isogenies,= =20 >>> or 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 fi= nd=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 si= zes=20 >>> of keys and/or signatures.=20 >>> - [ ] a multisignature scheme, or a threshold protocol with a DKG.=20 >>> Again, never seen this without massive keys and sigs, but I see no reas= on=20 >>> why it 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 arithmeti= c=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 tand= em=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-ke= y-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=20 >>> it=E2=80=99s 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-sig= natures-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 latti= ces=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=20 >>> Blockstream 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, sen= d=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-4f= e62ac2e00b%40app.fastmail.com.=20 >>> >>> >=20 >>> >> --=20 >> You received this message because you are subscribed to the Google Group= s=20 >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n=20 >> email to bitcoindev+...@googlegroups.com. >> >> To view this discussion visit=20 >> https://groups.google.com/d/msgid/bitcoindev/42faeb16-5d01-41ba-a192-e05= 936b84248n%40googlegroups.com >> . >> >> >> --=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/= ce98d232-4f6b-456b-ac3e-a1df12fa91ecn%40googlegroups.com. ------=_Part_236049_272819468.1779544082798 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Conduition,=C2=A0

Nevermind on the hybrid scheme question -- = Jonas explained in this thread that hybrid scheme is likely something = that would happen on the wallet level (not consensus/opcode level), so this= is now clarified on my end - thanks again for all your help!

x = Isabel



On Friday, May 22, 2026 at 8:25:41=E2=80=AFAM UTC-7 Is= abel Foxen Duke wrote:
Hi Conduition,

So glad you enjoyed the interview! I'm thrilled Dan is speaking on quantum-issues more= publicly these days :)
Noted about threshold signatures and other features potentially being only= theoretical and not truly practical with Lattice based signatures. I will = bring this up with Dan and see if he has any comment here - or if he has up= dates that may affect thinking on this.=C2=A0=C2=A0

I'm curiou= s to get your thoughts on the following:=C2=A0 it sounds like Dan is advoca= ting for a hybrid scheme and I'm wondering if this would render the str= ategy of implementing different signatures at different times less practica= l? In other words, does it still make sense to implement something like SHR= INCS before a lattice-based signature =E2=80=94 if we're ultimat= ely hoping to implement a single hybrid scheme as Dan proposes here?=C2=A0

thanks for al= l your hard work on this=C2=A0

Warmly,
I= sabel Foxen Duke

On Thursday, May 21, 2026 at 12:29:21=E2=80=AFPM UTC-7 con= duition wrote:
Hey Isabel, I watched t= he interview, very cool stuff. I loved seeing Dan dodge your question about= the mysterious "restrictions" google was under (hello NSA).

Dan is right that lattic= e-based crypto offers the promise of algebraic structure, whereas ha= sh-based crypto offers none. Having open research avenues towards goals lik= e threshold signatures is a great thing.=C2=A0Yet the promise of the= algebraic structure in lattices hasn't materialized into anything usab= le. At least, there are no schemes - yet - which tick the boxes we need. At= best we have hope for future developments. Lattice threshold and ke= y-rerandomization schemes will likely improve from where they are now, but = until proven ot= herwise we should make choices about consensus based on what we have, not w= hat we hope=C2=A0we will have someday.

Also, in the interview Dan acted as though deploying hash-base= d signatures would preclude the deployment of lattice crypto later. It does= n't.=C2=A0If we deploy a more cutting-edge cryptosystem like HAW= K or SQIsign, it will be once we have a suitably flexible and compact schem= es ready to build atop it, and when that happens we will still be glad to h= ave hash-based crypto as a backstop in case the cutting-edge assumptions (o= r implementations) are busted.

regards,
conduition
On Wednesday, May 20th, 2026 at 3:47 PM, Isabel Foxen Duke <isabe...@gmail.com> wrote:
FWIW =E2=80=94

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

H= e primarily cites algebraic structure as allowing greater functionality - a= nd is concerned that features like threshold signature schemes will be much= harder to implement with hash-based signatures.

-Isabel Foxen Duke=

O= n Tuesday, May 19, 2026 at 8:27:40=E2=80=AFPM UTC-7 conduition wrote:
Hey Nikita, thanks for broa= ching 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://delvingbitcoin.org/t/pos= t-quantum-hd-wallets-silent-payments-key-aggregation-and-threshold-signatur= es/1854/

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

> Dear list,
>

> 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.
>

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

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

> 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.
>

> This raises a few questions.
>

> 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?
>

> 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?
>

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

> Thanks,
> Nikita
>

> --
> 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/ms= gid/bitcoindev/ffa56d63-32c6-4fc3-a150-4fe62ac2e00b%40app.fastmail.com.
>

--
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 bitcoindev+...@googlegroups.com.

--
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/ce98d232-4f6b-456b-ac3e-a1df12fa91ecn%40googlegroups.com.
------=_Part_236049_272819468.1779544082798-- ------=_Part_236048_611341273.1779544082798--