From: Ethan Heilman <eth3rs@gmail.com>
To: Jonas Nick <jonasd.nick@gmail.com>
Cc: 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 11:44:01 -0500 [thread overview]
Message-ID: <CAEM=y+U_PV7dA5Azr7D4Rnr40QaHKUrxdLmx0zPPjYoE-HZ=Hw@mail.gmail.com> (raw)
In-Reply-To: <ea3a12db-e3fd-44b2-a22c-b960ed7ec6d3@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 8505 bytes --]
Appreciate your feedback on this proposal, Jonas
> 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.
I want to introduce some new terminology here:
Everyday signature algorithms: These are the signature algorithms users
employ for daily transactions.
Backup signature algorithms: These are signature algorithms used to migrate
from a broken everyday signature algorithm to new everyday signature
algorithm.
I agree that for the everyday signatures we need something much smaller
than SLH_DSA's 8kb signature. If we expect everyday signature algorithms to
weaken at a rate requiring replacement every 40 years, backup signatures
will represent a very small fraction of Bitcoin signatures, making their
size less important. Even then, if a break in a everyday signature
algorithm is not unexpected, we can use everyday signatures to make the
transition to the new everyday signature algorithm.
The most likely use for backup signatures is for someone who stored their
BTC in an output for 50 years, didn't move their coins when the everyday
signature algorithm was weakened, and then didn't move their coins when it
was completely broken. Say someone who put their coins in a safety deposit
box, got sick, died and their estate now wants to safely move the coins.
They would use the backup signature to move to a new output because there
is no other safe option.
> Those costs are therefore a more binding design constraint
than ecosystem support, which can be built up over time through focused
effort.
I agree with you here, as long as we constrain ourselves to everyday
signature algorithms. Backup signatures should optimize for security and
standardness.
> If Bitcoin disables Taproot key path spends before Q-day, then doing
this via Taproot instead of BIP 360 would be preferable.
I worry about making the transition to quantum-safe outputs depend on a
contentious debate over a confiscatory soft fork. Uncertainty over whether
the soft fork would be released and if released would be activated means
that wallets and custodians are unlikely to have invested the resources
into upgrading to support script only P2TR.
The benefit of BIP 360's P2MR (Pay-to-Merkle-Root) + SLH_DSA is that it
avoids this controversy by being opt-in and non-confiscatory. This also
means that BIP 360 + SLH_DSA is likely to activated early, allowing
wallets and custodians ample time to build support after activation.
> 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).
Let's call this P2TRD (Pay-to-Tap-Root-Disablable). BIP 360 evolved from
this P2TRD idea, to minimize the following hazards in P2TRD.
1. P2TRD requires a soft fork that depends on accurately predicting Q-day
or when EC Schnorr is classically broken. We must not only predict Q-day
but also convince the community that the prediction is correct. If we mess
up the timing, Bitcoin is significantly harmed. This means that people will
constantly be yelling that we are messing up the timing. It will make
quantum FUD worse not better.
2. P2TRD (Pay-to-Tap-Root-Disablable) to be non-confiscatory users must
create a script spend that replicates their key spend, But users and
wallets are likely to screw this up and not create script spends. The is no
way to see if a wallet is actually creating the script spend on the
blockchain.
3. To be safe from long-exposure attacks P2TRD can't use the same public
key for the script spend as the key spend. Since wallets will prefer the
key spend to the script spend, a user might not realize if they lost the
keying material for their script spend until after activation.
Hazard 2 and 3 make harzard 1 worse by making the Q-day soft-fork to
disable key spends in P2TRD more controversial. Imagine a giant custodian
finds out all their coins are burned after the soft fork activates, they
might bribe miners to unactivate the soft fork to give a chance to move the
coins. That probably won't happen but why take the risk? Signaling a
willingness to take unnecessary risks could also harm Bitcoin's credibility.
Additionally, by only having script path spends in BIP 360, wallets who
want to claim to use BIP 360 support must actually build script spend
support. Users will know that their script spends work because they are
actively using them.
BIP 360 +SLH_DSA solves problem 1 by never allowing key path spends in BIP
360 outputs. This allows us to reach quantum safety without having to
predict Q-Day. This also allows Bitcoin to demonstrate it is quantum safe,
rather than the hopes of quantum-safety depend on an uncertain future soft
fork. This settles the safety issue early, removing the risk of a Q-day
soft fork disaster and calming fears about such an event.
On Tue, Feb 10, 2026 at 4:11 AM Jonas Nick <jonasd.nick@gmail.com> wrote:
> 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
> .
>
--
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/CAEM%3Dy%2BU_PV7dA5Azr7D4Rnr40QaHKUrxdLmx0zPPjYoE-HZ%3DHw%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 9573 bytes --]
next prev parent reply other threads:[~2026-02-10 20:49 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
2026-02-10 16:44 ` Ethan Heilman [this message]
[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='CAEM=y+U_PV7dA5Azr7D4Rnr40QaHKUrxdLmx0zPPjYoE-HZ=Hw@mail.gmail.com' \
--to=eth3rs@gmail.com \
--cc=bitcoindev@googlegroups.com \
--cc=jonasd.nick@gmail.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