From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 22 May 2026 08:25:49 -0700 Received: from mail-oo1-f55.google.com ([209.85.161.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 1wQRky-00015a-5e for bitcoindev@gnusha.org; Fri, 22 May 2026 08:25:49 -0700 Received: by mail-oo1-f55.google.com with SMTP id 006d021491bc7-69d0183aeedsf7530815eaf.2 for ; Fri, 22 May 2026 08:25:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1779463542; x=1780068342; 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=dU6L27oYci+hb4BJNrWQqHCvWdXHm5iOJuAwtt98Lss=; b=HZqp21tDTqH6aXYMHH649ijzu6BJYH/nJoeSFvZhYhJsR3PVlVUHE5y/aAhKm5vh+W Hj29q9+OG9MP/WUEVtTkqcOjD/pOxvF3x/r9gxx+yos3m2qhjUgz3/+zZ9xL+cEQq7Ks QE1XJy0u83yemHWS8896bkj+Sw0ns4k9pEDNYdD2R3RIjdvkGqm5G0NwOA719H5M/P4t i+tl32+7/obFTz/MBx+bmCvPD2piol0hcbRu9vuoxv4jnfCSM86cKsZF5nsVrbeV4JET 1JWC/CznLhbWbvJMTMmBvpychuKcDpT3wV9ARKUgVXQ1BwoBUEy5QXVMzOEhUAooThMB noSw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779463542; x=1780068342; 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=dU6L27oYci+hb4BJNrWQqHCvWdXHm5iOJuAwtt98Lss=; b=sVuM9eZWEoJy6XLqOiCp0NIiI84EnxLuGh66TTIB+3DY3aTJQ951wqmTkvj9fDj+me uFWgZH8bYIwQBOwIdxhMc9ByUxoO9OhYNQlfcsER2zAfB/mPDi9XLOZEx4hdrK7KPYJe oDgxV0D2uCG2r7uh9rhBGWyv8SYojDbYSUFrv73UClzGTthrd85brXLgSZx83Rgj1/u3 2Ec6isikjuvwwjyTGA1dxHkaUcghk9407QaP0u4T/awQ6WulFkBHyikfTSs96bhbLlpv 3qo9PuzORwMM8aojrBQWfbxu2pbcGLDL3mNZmF3R7g4F/kau1bZ7XjrncSM8Mz+7gdrm rWZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779463542; x=1780068342; 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=dU6L27oYci+hb4BJNrWQqHCvWdXHm5iOJuAwtt98Lss=; b=tOYPeRV4SL5TmsRdRbz/zwHuDXEGYS89aimmBmOVypuaOnl5fKNvSH0NQKY0uCDkN7 7+hlX186972qxMKQ9RV9ZmuSgyGq/toZlSyKCUeVN/ZoDj8SPOCSZXm9iJC3nSPXB+w0 moOUdGoaoliQSFdkEoS/3gzN9jYl7g7/G2P1/oaObiSU0tAOcdIkTDymCjN2eox1PVBD FlQFbrkDCTBrvRjt/rqfeZ3hrG1ixWf/Mmvxe+cGxemsILFDfPA6Mbs/yndeFMTcVNTT 7W1wUCeZPwnljrzMh8LGdV+n9Vb0jHAYqld2OHbXwknmznmEfB9uQUeQsVshnzuWozdh 3wmg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AFNElJ9/ZyHkGkNvhcgmB3pe6czqG1qKlZ3P/0Z3OisVodEiEv6xQ5yE756JyIDRsamVb0Bb/RXbMquXV1Xt@gnusha.org X-Gm-Message-State: AOJu0Yz6sPIuPcOdpiS5oXlJLJf6cKE7mLb6v02QB56kMDOD3cTY22kF T0Zc9IhUUzy+ZLGOndq68W+QNLPbyXiBfvt8G2n8c9+/491+C/S8/8Js X-Received: by 2002:a4a:e883:0:b0:69d:513e:1a41 with SMTP id 006d021491bc7-69d7ec7bdbcmr1655260eaf.50.1779463541652; Fri, 22 May 2026 08:25:41 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AUV6zMOFXO0F8OOP4RWjZ2JxsAmWlFB/VNysMJFnJ0wSBMJPkA==" Received: by 2002:a05:6870:f22a:b0:43b:6f92:1c26 with SMTP id 586e51a60fabf-43b6f92c577ls448794fac.0.-pod-prod-09-us; Fri, 22 May 2026 08:25:35 -0700 (PDT) X-Received: by 2002:a05:6808:c1fa:b0:46a:d8b7:1101 with SMTP id 5614622812f47-4854a4cb0f2mr2178389b6e.41.1779463535659; Fri, 22 May 2026 08:25:35 -0700 (PDT) Received: by 2002:a05:690c:4b0c:b0:7ba:f5aa:4ab8 with SMTP id 00721157ae682-7d363b0b166ms7b3; Fri, 22 May 2026 08:22:39 -0700 (PDT) X-Received: by 2002:a05:690c:6a84:b0:7bd:5579:185a with SMTP id 00721157ae682-7d3356dfab6mr49074507b3.25.1779463358977; Fri, 22 May 2026 08:22:38 -0700 (PDT) Date: Fri, 22 May 2026 08:22:38 -0700 (PDT) From: Isabel Foxen Duke To: Bitcoin Development Mailing List Message-Id: <3975ff59-50f0-4001-bcfb-f1f444873d22n@googlegroups.com> In-Reply-To: <673BCz5V_RyCwtNI8IxXeDdauWVmQm9MTvtZ97_2ADXzWZNT9bLJsTx1fli-PEb1-cNIi4nCCS-BIsDP1GBMaldfMSWGBHDKl7bFZWf7T6U=@proton.me> References: <42faeb16-5d01-41ba-a192-e05936b84248n@googlegroups.com> <673BCz5V_RyCwtNI8IxXeDdauWVmQm9MTvtZ97_2ADXzWZNT9bLJsTx1fli-PEb1-cNIi4nCCS-BIsDP1GBMaldfMSWGBHDKl7bFZWf7T6U=@proton.me> Subject: Re: [bitcoindev] PQC: Lattice-based signatures MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_122986_1011115523.1779463358398" 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_122986_1011115523.1779463358398 Content-Type: multipart/alternative; boundary="----=_Part_122987_319210187.1779463358398" ------=_Part_122987_319210187.1779463358398 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Conduition, So glad you enjoyed the interview=20 ! I'm thrilled Dan= is=20 speaking on quantum-issues more publicly these days :) Noted about threshold signatures and other features potentially being only= =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 something= =20 like SHRINCS *before* a lattice-based signature =E2=80=94 if we're ultimate= ly=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 the= =20 > promise of the algebraic structure in lattices hasn't materialized into= =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 signature= s=20 > would preclude the deployment of lattice crypto later. It doesn't. If we= =20 > deploy a more cutting-edge cryptosystem like HAWK or SQIsign, it will be= =20 > once we have a suitably flexible and compact schemes ready to build atop= =20 > it, and when that happens we will still be glad to have hash-based crypto= =20 > as a backstop in case the cutting-edge assumptions (or implementations) a= re=20 > 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 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= =20 > "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an= =20 > email to bitcoindev+...@googlegroups.com. > > To view this discussion visit=20 > https://groups.google.com/d/msgid/bitcoindev/42faeb16-5d01-41ba-a192-e059= 36b84248n%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/= 3975ff59-50f0-4001-bcfb-f1f444873d22n%40googlegroups.com. ------=_Part_122987_319210187.1779463358398 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Conduition,

So glad you enjoyed the interview! I'm thri= lled Dan is speaking on quantum-issues more publicly these days :)

Noted about threshold si= gnatures and other features potentially being only theoretical and not trul= y practical with Lattice based signatures. I will bring this up with Dan an= d see if he has any comment here - or if he has updates that may affect thi= nking on this.=C2=A0=C2=A0

I'm curious to get your thoughts o= n the following:=C2=A0 it sounds like Dan is advocating for a hybrid scheme= and I'm wondering if this would render the strategy of implementing differ= ent signatures at different times less practical? In other words, does it s= till make sense to implement something like SHRINCS before a lattice= -based signature =E2=80=94 if we're ultimately hoping to implement a single= hybrid scheme as Dan proposes here?=C2=A0

thanks for all your hard work on this=C2=A0

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 seei= ng Dan dodge your question about the mysterious "restrictions" go= ogle was under (hello NSA).

Dan is right that lattice-based crypto offers the promise of= algebraic structure, whereas hash-based crypto offers none. Having open re= search avenues towards goals like threshold signatures is a great thing.=C2= =A0Yet the promise of the algebraic structure in lattices hasn't= materialized into anything usable. At least, there are no schemes - yet - = which tick the boxes we need. At best we have hope for future develo= pments. Lattice threshold and key-rerandomization schemes will likely impro= ve from where they are now, but until proven otherwise we should make choices about consen= sus based on what we have, not what we hope=C2=A0we will have someda= y.
<= span style=3D"font-family:Arial,sans-serif;font-size:14px">
Also, in the interview Dan act= ed as though deploying hash-based signatures would preclude the deployment = of lattice crypto later. It doesn't.=C2=A0If we deploy a more cu= tting-edge cryptosystem like HAWK or SQIsign, it will be once we have a sui= tably flexible and compact schemes ready to build atop it, and when that ha= ppens we will still be glad to have hash-based crypto as a backstop in case= the cutting-edge assumptions (or implementations) are busted.

regards,
conduition
On Wednesday, May 20th, 2026 at 3:47 PM, Isabel Foxen Duke <isabe...@gmail.c= om> 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/3975ff59-50f0-4001-bcfb-f1f444873d22n%40googlegroups.com.
------=_Part_122987_319210187.1779463358398-- ------=_Part_122986_1011115523.1779463358398--