From: Jonas Nick <jonasd.nick@gmail.com>
To: bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] Re: Hash-Based Signatures for Bitcoin's Post-Quantum Future
Date: Wed, 10 Dec 2025 15:55:31 +0000 [thread overview]
Message-ID: <27070789-50f0-4d2d-a107-c90be445db14@gmail.com> (raw)
In-Reply-To: <018ee35e-af3d-49d8-a8f2-5c478e681efan@googlegroups.com>
Thanks for all the feedback.
Trying to remain consistent with widely deployed, standardized variants of
SLH-DSA is a reasonable design consideration. But in that context it seems
noteworthy that using optimized schemes, instead of just tweaking parameters,
leads to way more than just a 4% reduction in signature size. The WOTS+C +
PORS+FP variant is 16% to 18% smaller than vanilla, size-optimized SPHINCS+ (for
2^40 signatures max) according to our scripts [0].
Another consideration is that in the scenario you [conduition] mention where
Bitcoin would adopt a lattice-based signature scheme and a hash-based signature
scheme, the lattice-based scheme may not be ML-DSA. Maximizing the functionality
benefits of lattice-based sigs may require a custom signature scheme that
supports public key derivation, multi/threshold signatures, aggregate
signatures, silent payments, etc. If the lattice-based signature scheme is
custom, there is little reason why the hash-based signature scheme should not be
custom as well.
More generally, one of my main motivations for working on this project was
whether there exist variants of hash-based signature schemes that are more
suitable for the "advanced" constructions we care about (HD wallets,
multi-signatures, ...). After doing this project with Mike (who has done
research on hash-based signatures for quite a few years), it seems like the
answer is basically no. We discuss some of the approaches in the paper, but it's
of course possible we're missing something. However, in that sense, the paper is
also a negative result.
I cannot follow the conclusion that 99% of people would use ML-DSA. Signature
size is pretty much the same as for parameter-optimized SPHINCS+. Without
lattice-based signature aggregation or silent payments, it seems like the main
benefit is verification time. Since you have probably the best collection of
numbers for perfomance of SLH-DSA, I'd be interested in the performance numbers
of ML-DSA you use for comparison with SLH-DSA.
[0] https://github.com/BlockstreamResearch/SPHINCS-Parameters/blob/main/costs.sage
--
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/27070789-50f0-4d2d-a107-c90be445db14%40gmail.com.
next prev parent reply other threads:[~2025-12-10 16:19 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-08 20:28 [bitcoindev] " 'Mikhail Kudinov' via Bitcoin Development Mailing List
2025-12-08 21:50 ` Greg Maxwell
2025-12-09 5:08 ` 'conduition' via Bitcoin Development Mailing List
2025-12-10 0:41 ` Olaoluwa Osuntokun
2025-12-09 8:06 ` [bitcoindev] " Boris Nagaev
2025-12-09 22:48 ` 'Mikhail Kudinov' via Bitcoin Development Mailing List
2025-12-09 23:06 ` 'Mikhail Kudinov' via Bitcoin Development Mailing List
2025-12-10 0:01 ` 'Mikhail Kudinov' via Bitcoin Development Mailing List
2025-12-10 0:14 ` 'conduition' via Bitcoin Development Mailing List
2025-12-10 15:55 ` Jonas Nick [this message]
2025-12-10 0:53 ` Olaoluwa Osuntokun
2025-12-16 7:25 ` Jonas Nick
2026-01-19 1:12 ` 'conduition' via Bitcoin Development Mailing List
2025-12-18 18:45 ` Erik Aronesty
2025-12-19 8:36 ` Jonas Nick
2025-12-20 1:14 ` Erik Aronesty
2025-12-24 15:02 ` david torrealba
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=27070789-50f0-4d2d-a107-c90be445db14@gmail.com \
--to=jonasd.nick@gmail.com \
--cc=bitcoindev@googlegroups.com \
/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