From: "'conduition' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
To: Nikita Karetnikov <nikita@karetnikov.org>
Cc: bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] PQC: Lattice-based signatures
Date: Wed, 20 May 2026 03:18:35 +0000 [thread overview]
Message-ID: <lnp3AdRhvhMvjRwRBdZXH07ZNc8qDoBDyhpB7fGH_twBfIXs1wUfXli-c0g7zuNMPhmN64DFMkb2v9CPlCprSiMfRozIM1oykxTliSx_Qc4=@proton.me> (raw)
In-Reply-To: <ffa56d63-32c6-4fc3-a150-4fe62ac2e00b@app.fastmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 6179 bytes --]
Hey Nikita, thanks for broaching the idea.
I can't speak for Blockstream, but as to the spirit of your question - Why people are looking at hash-based sigs more than lattices - I can think of four major reasons:
1. Conservatism. Hash based signatures are incredibly conservative. They rely on strictly weaker assumptions than what we already depend on for other things. No other family of signatures can claim this property, and for something as inflexible-yet-sensitive as Bitcoin, conservativism is appealing.
2. Simplicity. Hash-based signatures are easier to grasp, simpler to prove secure, and easier to implement compared to almost anything else (even simpler than ECC). We Bitcoiners tend to clutch our pearls in fear of trusting flawed assumptions... but in reality most vulnerabilities are not cryptographic in nature: Most are implementation failures. Hash-based sigs are harder (but not impossible) to screw up. An experienced engineer can implement 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]. Their cost-per-byte is way lower than Schnorr. If you can bite the statefulness bullet, hash-based sigs can even be compact (and still fast). There remains 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 that price is paid by the signer implementation while verifiers remain slim, quick, and secure.
4. Future-proofing. Because of their conservatism, hash-based sigs stand a better chance of remaining secure over a long time-frame, so it seems more likely we could rely on them to fulfill a long-term fallback role. We will likely someday need to deploy a new cryptosystem to replace ECC as a daily driver if ECDLP is broken, whether classically or by a CRQC. When/if this happens, we'll be REALLY glad we added hash-based sigs first, because then we'll have something to use if the novel scheme's assumptions (or more likely, implementation) are broken.
This is not to say we shouldn't be researching lattices. Or isogenies, 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 first episode of a decades-long saga, but unfortunately we lack enough knowledge to know what should come next. Maybe that is lattices? maybe something else. 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 crypto 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 done [1], but AFAIK it is impossible without massively expanding the sizes of keys and/or signatures.
- [ ] a multisignature scheme, or a threshold protocol with a DKG. Again, never seen this without massive keys and sigs, but I see no reason why it 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 headaches. It'd be nice if we could do away with that.
- [ ] signature aggregation. This is a more general wish of any PQ scheme, and if someone can do it, even with somewhat large sigs or poor performance, it might make the whole scheme way more palatable, in tandem 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]: 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 <nikita@karetnikov.org> wrote:
> Dear list,
>
> I hate to contribute to the recent flood of PQC posts, but I think it’s an important issue that’s worth discussing.
>
> In particular, what I usually see is various competing proposals without a clear winner.
>
> So I’d like to bring everyone’s attention to this new post from Blockstream:
> https://blog.blockstream.com/schnorr-but-with-vectors-lattice-based-signatures-explained/
>
> This post is interesting because unlike a lot of PQC discussions, it actually includes a comparison table of various approaches, where lattices seem to come out ahead.
>
> This raises a few questions.
>
> Since lattices are not a new topic in cryptography, why has Blockstream 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’d 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+unsubscribe@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/ffa56d63-32c6-4fc3-a150-4fe62ac2e00b%40app.fastmail.com.
>
--
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+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/lnp3AdRhvhMvjRwRBdZXH07ZNc8qDoBDyhpB7fGH_twBfIXs1wUfXli-c0g7zuNMPhmN64DFMkb2v9CPlCprSiMfRozIM1oykxTliSx_Qc4%3D%40proton.me.
[-- Attachment #1.2: publickey - conduition@proton.me - 0x474891AD.asc --]
[-- Type: application/pgp-keys, Size: 649 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 343 bytes --]
next prev parent reply other threads:[~2026-05-20 3:27 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-19 19:33 [bitcoindev] PQC: Lattice-based signatures Nikita Karetnikov
2026-05-20 3:18 ` 'conduition' via Bitcoin Development Mailing List [this message]
2026-05-20 9:56 ` 'Mikhail Kudinov' via Bitcoin Development Mailing List
2026-05-20 10:35 ` Alex
2026-05-20 17:58 ` Isabel Foxen Duke
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='lnp3AdRhvhMvjRwRBdZXH07ZNc8qDoBDyhpB7fGH_twBfIXs1wUfXli-c0g7zuNMPhmN64DFMkb2v9CPlCprSiMfRozIM1oykxTliSx_Qc4=@proton.me' \
--to=bitcoindev@googlegroups.com \
--cc=conduition@proton.me \
--cc=nikita@karetnikov.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox