From: Jonas Nick <jonasd.nick@gmail.com>
To: bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms
Date: Tue, 10 Feb 2026 08:53:07 +0000 [thread overview]
Message-ID: <ea3a12db-e3fd-44b2-a22c-b960ed7ec6d3@gmail.com> (raw)
In-Reply-To: <CAEM=y+WTqe8=uqChu2vN3HruiJCvFcDMNP+JA0AwyOkaR=z0Cw@mail.gmail.com>
Hi Ethan,
Thanks for the thoughts. A few comments on the specifics follow.
> I prefer SLH_DSA because it is likely to be well supported outside of Bitcoin
> and Bitcoin can benefit from this ecosystem of support in the form of HSMs,
> hardware acceleration and software liberties.
I agree that reusing an already standardized scheme like SLH-DSA has the real
benefit of building on an existing ecosystem and allowing for faster deployment.
The downside is that SLH-DSA is less efficient for Bitcoin than alternative
hash-based signatures.
If this is not intended to be a short-term solution, efficiency considerations
(e.g., ~50% smaller signatures) likely outweigh the benefits of an established
ecosystem. While the Bitcoin space does have the ability to standardize new
efficient schemes and invest in software libraries and custom HSM support, the
verification resource constraints of the entire Bitcoin network are much harder
to influence. Those costs are therefore a more binding design constraint than
ecosystem support, which can be built up over time through focused effort.
> Q: Couldn’t you do this without BIP 360 by using Taproot instead and then
> disabling the taproot key spend path?
> A: Yes, however this would be confiscatory, since Taproot allows key spend
> path only outputs.
If Bitcoin disables Taproot key path spends before Q-day, then doing this via
Taproot instead of BIP 360 would be preferable. It would allow users to benefit
from Taproot's efficiency and privacy properties until key path spends are
disabled.
There's also an alternative that Matt Corallo mentioned to me recently which I
haven't seen discussed on the mailing list. We could define a new SegWit version
that is a copy of Taproot. The new version number simply signals that the owner
consents to a future deactivation of key path spends. Unlike BIP 360, this
approach would still require actually disabling the key path before Q-day, but
it is not confiscatory and allows using Taproot's benefits until then (with a
privacy hit from having two versions of Taproot in parallel).
--
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/ea3a12db-e3fd-44b2-a22c-b960ed7ec6d3%40gmail.com.
next prev parent reply other threads:[~2026-02-10 9:11 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-09 14:20 Ethan Heilman
2026-02-10 8:53 ` Jonas Nick [this message]
2026-02-10 16:44 ` Ethan Heilman
[not found] ` <CAJowKg+WJLAJoMhyhVfkC9OSdks5jBieDWty9ce-Qju-84URFA@mail.gmail.com>
2026-02-10 23:13 ` Ethan Heilman
2026-02-11 0:19 ` Erik Aronesty
2026-02-11 2:40 ` Ethan Heilman
2026-02-11 7:25 ` Erik Aronesty
2026-02-11 16:37 ` Ethan Heilman
2026-02-17 4:13 ` 'conduition' via Bitcoin Development Mailing List
2026-02-17 7:39 ` 'conduition' via Bitcoin Development Mailing List
2026-02-19 14:35 ` Garlo Nicon
2026-02-20 1:41 ` Alex
2026-02-20 18:48 ` Erik Aronesty
2026-02-23 14:00 ` 'conduition' via Bitcoin Development Mailing List
2026-02-23 19:08 ` Erik Aronesty
2026-02-23 21:42 ` Ethan Heilman
2026-02-24 0:12 ` Alex
2026-02-25 10:43 ` Javier Mateos
2026-02-26 13:24 ` 'Mikhail Kudinov' via Bitcoin Development Mailing List
2026-02-26 15:51 ` Matt Corallo
2026-02-27 15:18 ` 'Mikhail Kudinov' via Bitcoin Development Mailing List
2026-02-27 19:31 ` 'conduition' via Bitcoin Development Mailing List
2026-03-01 12:24 ` 'Mikhail Kudinov' via Bitcoin Development Mailing List
2026-03-01 21:28 ` Alex
2026-02-11 18:53 ` Matt Corallo
2026-02-11 22:57 ` Ethan Heilman
2026-02-12 14:55 ` Matt Corallo
2026-02-12 15:35 ` Alex
2026-02-12 19:20 ` Matt Corallo
2026-02-12 18:08 ` Ethan Heilman
2026-02-12 19:13 ` Matt Corallo
2026-02-12 20:35 ` Ethan Heilman
2026-02-12 20:43 ` Matt Corallo
2026-02-12 15:13 ` Alex
2026-02-12 19:16 ` Matt Corallo
2026-02-12 15:36 ` waxwing/ AdamISZ
2026-02-12 19:35 ` Matt Corallo
2026-02-12 19:43 ` Matt Corallo
2026-02-14 12:39 ` waxwing/ AdamISZ
2026-02-15 12:12 ` Matt Corallo
2026-02-10 21:51 ` 'Brandon Black' via Bitcoin Development Mailing List
2026-02-10 22:19 ` Ethan Heilman
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=ea3a12db-e3fd-44b2-a22c-b960ed7ec6d3@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