* [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms
@ 2026-02-09 14:20 Ethan Heilman
2026-02-10 8:53 ` Jonas Nick
2026-02-10 21:51 ` 'Brandon Black' via Bitcoin Development Mailing List
0 siblings, 2 replies; 42+ messages in thread
From: Ethan Heilman @ 2026-02-09 14:20 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 9006 bytes --]
Howdy list, I want to share my thoughts on increasing the security of
Bitcoin to long term threats such as quantum and classical breaks in
Bitcoin’s signature algorithms by adding algorithm agility mechanisms to
Bitcoin. To quote RFC 7696: Guidelines for Cryptographic Algorithm Agility
<https://datatracker.ietf.org/doc/html/rfc7696>:
“Protocol designers need to assume that advances in computing power or
advances in cryptoanalytic techniques will eventually make any algorithm
obsolete. For this reason, protocols need mechanisms to migrate from one
algorithm suite to another over time.
Algorithm agility is achieved when a protocol can easily migrate from one
algorithm suite to another more desirable one, over time.”
I propose introducing a very secure post-quantum signature algorithm to be
used alongside the current algorithms. This signature algorithm can be very
expensive in txn fees and block space since it is for emergency migrations
only. This enables Bitcoin holders to cheaply and easily create outputs
that “failsafe” even against an unexpected break in a signature algorithm.
Motivation
====
Bitcoin should enable a person to self-custody coins for at least one human
lifetime, ~75 years. Someone should be able to bury an HD Seed in a coffee
can and then dig it up in 75 years and spend those coins. No store of value
can promise complete safety on long timescales, but the trust we build by
demonstrating that Bitcoin is serious about mitigating long-term low
probability risks. Trust and credibility is built when the risk we defended
against never happens.
The main risk I will be considering here is the loss of the ability to
authenticate ownership of coins resulting from a break in a digital
signature algorithm used by Bitcoin. Such risks are extremely unlikely in
the short term (1 to 5 years), but become more likely on 5 to 75 year
timescales. Most of the focus in the wider cryptocurrency world has been on
mitigating the quantum threat, but I take a less narrow view of the
problem. We should consider not just Quantum attacks on Bitcoin’s signature
algorithms and also classical breaks that do not require a quantum
computer. One particular area of concern to me is an unexpected
breakthrough in Mathematics driven by AI approaches.
To address these risks we propose the following design for protecting
holders even against an unexpected break in Bitcoin’s signature algorithms
quantum or otherwise.
Design
====
Assume that Bitcoin supported two digital signature algorithms: DSA1 and
DSA2. Each signature scheme would have its own CHECKSIG opcode,
CHECKSIG_DSA1 and CHECKSIG_DSA2.
Using BIP 360, we could have a leaf script for CHECKSIG_DSA1 and a leaf
script for CHECKSIG_DSA2.
Leaf1: DSA1_PUBKEY, CHECKSIG_DSA1
Leaf2: DSA2_PUBKEY, CHECKSIG_DSA2
If DSA1 was broken, users could simply switch to spending the output with
DSA2 signatures by using leaf2. An attacker that could break DSA1, wouldn’t
be able to learn the public key for DSA1, and thus wouldn’t be able to
spend DSA1, despite DSA1 being vulnerable.
This approach makes the assumption that the user has not leaked their
public key to an attacker or reused their public keys. As a user wishing to
hold Bitcoin in an output over long periods of time generate a fresh set of
public keys for that output.
Our approach does not defend against the case where DSA1 and DSA2 are
broken at the same time. For this reason, DSA1 and DSA2 should use
different cryptographic assumptions. Additionally DSA2 should use a
signature scheme that trades off efficiency for additional security and
robustness. This way, we can get the best of both worlds, DSA1 can be used
for everyday signatures and if DSA1 is broken, DSA2 can be used to migrate
to a new signature scheme, say DSA3. Even if DSA3, chosen in haste to
replace DSA1, is also found to be weak, holders are still protected. This
is because DSA2 is unbroken, allowing us to replace DSA3 with DSA4.
DSA1 - Efficient, low cost to use, should support nice-to-have features
such as aggregation.
DSA2 - Expensive, extreme levels of security, only used to transition to
new signature schemes.
A person with an HD seed buried in a coffee can for 75 years is still safe
even if they don’t transition from DSA1 to DSA3 and since DSA2 is still
safe. When they dig it up, they can use DSA2 to move the output to
DSA3+DSA2.
Given this framework, let’s think about DSA1 and DSA2 with concrete
algorithms:
- DSA1 is Schnorr, the currently supported Schnorr signature algorithmin
Bitcoin.
- DSA2 is SLH-DSA (SPHINCS+ SLH-DSA-SHA2-128s). SLH-DSA is a hash based
signature algorithm. Hash based signatures are the most likely secure long
term.
If we merged BIP 360 and support for a SLH-DSA CHECKSIG opcode, holders
could hedge against a classical or quantum attack against Schnorr, while
still using Schnorr.
Our approach mitigates the main drawback of the size of SLH-DSA signatures,
their size. SLH-DSA signatures are 8 KB in size, while [0] explores methods
for reducing the size of these signatures to 3 KB, 3 KB is still huge.
Because SLH-DSA signatures would not have any additional discount, they
would be very expensive in transaction fees, and only economically
worthwhile to migrate from Schnorr to a new signature scheme. In all other
cases the addition of SLH-DSA would exist as unused leaf scripts in the
output, which increases the witness by 32 bytes.
An additional benefit to this approach of using BIP 360 and SLH-DSA would
be to buy time for non-hash based PQ signature schemes to mature. We are
seeing rapid advances in research on post-quantum signature schemes and
waiting a little long might buy us a lot. SLH-DSA would provide an
effective hedge against this risk, while delaying the decision of what PQ
signature scheme should replace Schnorr in the event of Schnorr's security
being weakened.
Q & A
====
Q: Could these signatures be abused to store JPEGs on the blockchain?
A: No because they would have no additional discount. This means they would
have no advantage for JPEGs over what is currently possible.
Q: Why not use XMSS or Lamport signatures instead of SLH_DSA?
A: 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. That said, it is
reasonable to consider stateful hash based signature schemes like XMSS,
Winternitz, or Lamport signatures as the fallback signature, especially if
size becomes a concern.
Q: What non-consensus critical changes would be needed to support this?
A; We’d need to create new wallet standards to provide alternatives to
BIP32 xpubs. Wallet would have to write code to generate SLH-DSA keys and
create a script tree per signature alg. Wallets would also have to put into
place mechanisms to warn for and prevent public key reuse.
Q: What consensus critical changes would be needed to support this?
A: We’d need to merge something like BIP 360 and then a new CHECKSIG opcode
for SLH_DSA.
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. People holding key spend path-only Taproot outputs would
have the coins in those outputs destroyed. BIP 360, in essence is Taproot,
without the key spend path. BIP 360 provides the same functionality as
disabling Taproot key spend paths, but rather than being confiscatory, it
is opt in.
Q: Are you proposing this now because you think that the Bitcoin signature
algorithms are under threat?
A: No, I am confident in the Bitcoin signature algorithms and I know of no
immediate threats. This effort is motivated by longtermism and thinking
about how to enable Bitcoin to be safe on timescales of decades or
centuries.
[0]: Mikhail Kudinov, Jonas Nick, Hash-based Signature Schemes for Bitcoin
(2025) https://eprint.iacr.org/2025/2203
I want to acknowledge conduition’s feedback and suggestions on this email,
including the sentence about xpubs. The ideas above resulted from
conversations between myself, Hunter and Isabel. Similar ideas have been
suggested on the list before. I make no claims of originality, I am
organizing these ideas and my thoughts on them into a concrete design. All
errors are my own.
Thanks,
Ethan
--
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%2BWTqe8%3DuqChu2vN3HruiJCvFcDMNP%2BJA0AwyOkaR%3Dz0Cw%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 33811 bytes --]
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms
2026-02-09 14:20 [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms Ethan Heilman
@ 2026-02-10 8:53 ` Jonas Nick
2026-02-10 16:44 ` Ethan Heilman
2026-02-10 21:51 ` 'Brandon Black' via Bitcoin Development Mailing List
1 sibling, 1 reply; 42+ messages in thread
From: Jonas Nick @ 2026-02-10 8:53 UTC (permalink / raw)
To: bitcoindev
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.
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms
2026-02-10 8:53 ` Jonas Nick
@ 2026-02-10 16:44 ` Ethan Heilman
[not found] ` <CAJowKg+WJLAJoMhyhVfkC9OSdks5jBieDWty9ce-Qju-84URFA@mail.gmail.com>
2026-02-11 18:53 ` Matt Corallo
0 siblings, 2 replies; 42+ messages in thread
From: Ethan Heilman @ 2026-02-10 16:44 UTC (permalink / raw)
To: Jonas Nick; +Cc: bitcoindev
[-- 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 --]
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms
2026-02-09 14:20 [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms Ethan Heilman
2026-02-10 8:53 ` Jonas Nick
@ 2026-02-10 21:51 ` 'Brandon Black' via Bitcoin Development Mailing List
2026-02-10 22:19 ` Ethan Heilman
1 sibling, 1 reply; 42+ messages in thread
From: 'Brandon Black' via Bitcoin Development Mailing List @ 2026-02-10 21:51 UTC (permalink / raw)
To: Ethan Heilman; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 10212 bytes --]
Thanks for posting this.
What are your thoughts on the alternative mechanism of deploying GSR or similar in BIP360 and then letting folks build their own DSA2 which can then change over time without additional forks. Most of these would never be spent from anyway, and this seems like a dominant approach for DSA2.
Sipa pointed out to me on an Optech podcast that this approach is inappropriate for DSA1/3 because there are strictly need a vetted ecosystem for regular spends, lightning, aggregation, etc.
Best,
--Brandon, sent by an Android
Feb 9, 2026 07:40:47 Ethan Heilman <eth3rs@gmail.com>:
> Howdy list, I want to share my thoughts on increasing the security of Bitcoin to long term threats such as quantum and classical breaks in Bitcoin’s signature algorithms by adding algorithm agility mechanisms to Bitcoin. To quote _RFC 7696: Guidelines for Cryptographic Algorithm Agility[https://datatracker.ietf.org/doc/html/rfc7696]_:
>
> “Protocol designers need to assume that advances in computing power or advances in cryptoanalytic techniques will eventually make any algorithm obsolete. For this reason, protocols need mechanisms to migrate from one algorithm suite to another over time.
>
> Algorithm agility is achieved when a protocol can easily migrate from one algorithm suite to another more desirable one, over time.”
>
> I propose introducing a very secure post-quantum signature algorithm to be used alongside the current algorithms. This signature algorithm can be very expensive in txn fees and block space since it is for emergency migrations only. This enables Bitcoin holders to cheaply and easily create outputs that “failsafe” even against an unexpected break in a signature algorithm.
>
> Motivation
> ====
>
> Bitcoin should enable a person to self-custody coins for at least one human lifetime, ~75 years. Someone should be able to bury an HD Seed in a coffee can and then dig it up in 75 years and spend those coins. No store of value can promise complete safety on long timescales, but the trust we build by demonstrating that Bitcoin is serious about mitigating long-term low probability risks. Trust and credibility is built when the risk we defended against never happens.
>
> The main risk I will be considering here is the loss of the ability to authenticate ownership of coins resulting from a break in a digital signature algorithm used by Bitcoin. Such risks are extremely unlikely in the short term (1 to 5 years), but become more likely on 5 to 75 year timescales. Most of the focus in the wider cryptocurrency world has been on mitigating the quantum threat, but I take a less narrow view of the problem. We should consider not just Quantum attacks on Bitcoin’s signature algorithms and also classical breaks that do not require a quantum computer. One particular area of concern to me is an unexpected breakthrough in Mathematics driven by AI approaches.
> To address these risks we propose the following design for protecting holders even against an unexpected break in Bitcoin’s signature algorithms quantum or otherwise.
> Design
> ====
> Assume that Bitcoin supported two digital signature algorithms: DSA1 and DSA2. Each signature scheme would have its own CHECKSIG opcode, CHECKSIG_DSA1 and CHECKSIG_DSA2.
>
> Using BIP 360, we could have a leaf script for CHECKSIG_DSA1 and a leaf script for CHECKSIG_DSA2.
>
> Leaf1: DSA1_PUBKEY, CHECKSIG_DSA1
> Leaf2: DSA2_PUBKEY, CHECKSIG_DSA2
>
> If DSA1 was broken, users could simply switch to spending the output with DSA2 signatures by using leaf2. An attacker that could break DSA1, wouldn’t be able to learn the public key for DSA1, and thus wouldn’t be able to spend DSA1, despite DSA1 being vulnerable.
>
> This approach makes the assumption that the user has not leaked their public key to an attacker or reused their public keys. As a user wishing to hold Bitcoin in an output over long periods of time generate a fresh set of public keys for that output.
>
> Our approach does not defend against the case where DSA1 and DSA2 are broken at the same time. For this reason, DSA1 and DSA2 should use different cryptographic assumptions. Additionally DSA2 should use a signature scheme that trades off efficiency for additional security and robustness. This way, we can get the best of both worlds, DSA1 can be used for everyday signatures and if DSA1 is broken, DSA2 can be used to migrate to a new signature scheme, say DSA3. Even if DSA3, chosen in haste to replace DSA1, is also found to be weak, holders are still protected. This is because DSA2 is unbroken, allowing us to replace DSA3 with DSA4.
>
> DSA1 - Efficient, low cost to use, should support nice-to-have features such as aggregation.
> DSA2 - Expensive, extreme levels of security, only used to transition to new signature schemes.
>
> A person with an HD seed buried in a coffee can for 75 years is still safe even if they don’t transition from DSA1 to DSA3 and since DSA2 is still safe. When they dig it up, they can use DSA2 to move the output to DSA3+DSA2.
>
> Given this framework, let’s think about DSA1 and DSA2 with concrete algorithms:
>
> - DSA1 is Schnorr, the currently supported Schnorr signature algorithmin Bitcoin.
> - DSA2 is SLH-DSA (SPHINCS+ SLH-DSA-SHA2-128s). SLH-DSA is a hash based signature algorithm. Hash based signatures are the most likely secure long term.
>
> If we merged BIP 360 and support for a SLH-DSA CHECKSIG opcode, holders could hedge against a classical or quantum attack against Schnorr, while still using Schnorr.
>
> Our approach mitigates the main drawback of the size of SLH-DSA signatures, their size. SLH-DSA signatures are 8 KB in size, while [0] explores methods for reducing the size of these signatures to 3 KB, 3 KB is still huge. Because SLH-DSA signatures would not have any additional discount, they would be very expensive in transaction fees, and only economically worthwhile to migrate from Schnorr to a new signature scheme. In all other cases the addition of SLH-DSA would exist as unused leaf scripts in the output, which increases the witness by 32 bytes.
>
> An additional benefit to this approach of using BIP 360 and SLH-DSA would be to buy time for non-hash based PQ signature schemes to mature. We are seeing rapid advances in research on post-quantum signature schemes and waiting a little long might buy us a lot. SLH-DSA would provide an effective hedge against this risk, while delaying the decision of what PQ signature scheme should replace Schnorr in the event of Schnorr's security being weakened.
>
> Q & A
> ====
>
> Q: Could these signatures be abused to store JPEGs on the blockchain?
> A: No because they would have no additional discount. This means they would have no advantage for JPEGs over what is currently possible.
>
> Q: Why not use XMSS or Lamport signatures instead of SLH_DSA?
> A: 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. That said, it is reasonable to consider stateful hash based signature schemes like XMSS, Winternitz, or Lamport signatures as the fallback signature, especially if size becomes a concern.
>
> Q: What non-consensus critical changes would be needed to support this?
> A; We’d need to create new wallet standards to provide alternatives to BIP32 xpubs. Wallet would have to write code to generate SLH-DSA keys and create a script tree per signature alg. Wallets would also have to put into place mechanisms to warn for and prevent public key reuse.
>
> Q: What consensus critical changes would be needed to support this?
> A: We’d need to merge something like BIP 360 and then a new CHECKSIG opcode for SLH_DSA.
>
> 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. People holding key spend path-only Taproot outputs would have the coins in those outputs destroyed. BIP 360, in essence is Taproot, without the key spend path. BIP 360 provides the same functionality as disabling Taproot key spend paths, but rather than being confiscatory, it is opt in.
>
> Q: Are you proposing this now because you think that the Bitcoin signature algorithms are under threat?
> A: No, I am confident in the Bitcoin signature algorithms and I know of no immediate threats. This effort is motivated by longtermism and thinking about how to enable Bitcoin to be safe on timescales of decades or centuries.
>
> [0]: Mikhail Kudinov, Jonas Nick, Hash-based Signature Schemes for Bitcoin (2025) _https://eprint.iacr.org/2025/2203_
>
> I want to acknowledge conduition’s feedback and suggestions on this email, including the sentence about xpubs. The ideas above resulted from conversations between myself, Hunter and Isabel. Similar ideas have been suggested on the list before. I make no claims of originality, I am organizing these ideas and my thoughts on them into a concrete design. All errors are my own.
>
> Thanks,
> Ethan
>
> --
> 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%2BWTqe8%3DuqChu2vN3HruiJCvFcDMNP%2BJA0AwyOkaR%3Dz0Cw%40mail.gmail.com[https://groups.google.com/d/msgid/bitcoindev/CAEM%3Dy%2BWTqe8%3DuqChu2vN3HruiJCvFcDMNP%2BJA0AwyOkaR%3Dz0Cw%40mail.gmail.com?utm_medium=email&utm_source=footer].
--
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/af3369ef-7390-4695-ad6e-899a6ac8b700%40reardencode.com.
[-- Attachment #2: Type: text/html, Size: 36107 bytes --]
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms
2026-02-10 21:51 ` 'Brandon Black' via Bitcoin Development Mailing List
@ 2026-02-10 22:19 ` Ethan Heilman
0 siblings, 0 replies; 42+ messages in thread
From: Ethan Heilman @ 2026-02-10 22:19 UTC (permalink / raw)
To: Brandon Black; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 11732 bytes --]
I have no objection to GSR based post quantum signatures and this approach
is compatible with the proposal outlined above. I really like the idea that
we could transition from algorithm to algorithm without having to soft fork.
Even for DSA2, we would probably want a vetted ecosystem. Imagine you are
hired to recover coins inherited by an estate. DSA1 is broken, so to safely
spend the coins you need to use DSA2. If you can reconstruct the spend
script for DSA2 using only the HD seed, you are going to have a good day.
If you have to guess the particular signature algorithm used from a large
set of variants, you might not be able to recover the coins.
My goal is to have a standardized way for wallets to transition to new
algorithms. If this was done with GSR, you'd still want a BIP for a new
signature algorithm (DSA2, DSA3, DSA4, ...), you spend all the time on
security reviews and getting buy in from wallets and custodians.
My main concern with GSR, and the reason it isn't included in the proposal,
is if there is consensus to activate it.
On Tue, Feb 10, 2026 at 4:51 PM Brandon Black <freedom@reardencode.com>
wrote:
> Thanks for posting this.
>
> What are your thoughts on the alternative mechanism of deploying GSR or
> similar in BIP360 and then letting folks build their own DSA2 which can
> then change over time without additional forks. Most of these would never
> be spent from anyway, and this seems like a dominant approach for DSA2.
>
> Sipa pointed out to me on an Optech podcast that this approach is
> inappropriate for DSA1/3 because there are strictly need a vetted ecosystem
> for regular spends, lightning, aggregation, etc.
>
> Best,
> --Brandon, sent by an Android
>
> Feb 9, 2026 07:40:47 Ethan Heilman <eth3rs@gmail.com>:
>
> Howdy list, I want to share my thoughts on increasing the security of
> Bitcoin to long term threats such as quantum and classical breaks in
> Bitcoin’s signature algorithms by adding algorithm agility mechanisms to
> Bitcoin. To quote RFC 7696: Guidelines for Cryptographic Algorithm Agility
> <https://datatracker.ietf.org/doc/html/rfc7696>:
>
> “Protocol designers need to assume that advances in computing power or
> advances in cryptoanalytic techniques will eventually make any algorithm
> obsolete. For this reason, protocols need mechanisms to migrate from one
> algorithm suite to another over time.
>
>
> Algorithm agility is achieved when a protocol can easily migrate from one
> algorithm suite to another more desirable one, over time.”
>
>
> I propose introducing a very secure post-quantum signature algorithm to be
> used alongside the current algorithms. This signature algorithm can be very
> expensive in txn fees and block space since it is for emergency migrations
> only. This enables Bitcoin holders to cheaply and easily create outputs
> that “failsafe” even against an unexpected break in a signature algorithm.
>
> Motivation
> ====
>
>
>
> Bitcoin should enable a person to self-custody coins for at least one
> human lifetime, ~75 years. Someone should be able to bury an HD Seed in a
> coffee can and then dig it up in 75 years and spend those coins. No store
> of value can promise complete safety on long timescales, but the trust we
> build by demonstrating that Bitcoin is serious about mitigating long-term
> low probability risks. Trust and credibility is built when the risk we
> defended against never happens.
>
> The main risk I will be considering here is the loss of the ability to
> authenticate ownership of coins resulting from a break in a digital
> signature algorithm used by Bitcoin. Such risks are extremely unlikely in
> the short term (1 to 5 years), but become more likely on 5 to 75 year
> timescales. Most of the focus in the wider cryptocurrency world has been on
> mitigating the quantum threat, but I take a less narrow view of the
> problem. We should consider not just Quantum attacks on Bitcoin’s signature
> algorithms and also classical breaks that do not require a quantum
> computer. One particular area of concern to me is an unexpected
> breakthrough in Mathematics driven by AI approaches.
> To address these risks we propose the following design for protecting
> holders even against an unexpected break in Bitcoin’s signature algorithms
> quantum or otherwise.
> Design
> ====
>
> Assume that Bitcoin supported two digital signature algorithms: DSA1 and
> DSA2. Each signature scheme would have its own CHECKSIG opcode,
> CHECKSIG_DSA1 and CHECKSIG_DSA2.
>
> Using BIP 360, we could have a leaf script for CHECKSIG_DSA1 and a leaf
> script for CHECKSIG_DSA2.
>
> Leaf1: DSA1_PUBKEY, CHECKSIG_DSA1
> Leaf2: DSA2_PUBKEY, CHECKSIG_DSA2
>
> If DSA1 was broken, users could simply switch to spending the output with
> DSA2 signatures by using leaf2. An attacker that could break DSA1, wouldn’t
> be able to learn the public key for DSA1, and thus wouldn’t be able to
> spend DSA1, despite DSA1 being vulnerable.
>
> This approach makes the assumption that the user has not leaked their
> public key to an attacker or reused their public keys. As a user wishing to
> hold Bitcoin in an output over long periods of time generate a fresh set of
> public keys for that output.
>
>
> Our approach does not defend against the case where DSA1 and DSA2 are
> broken at the same time. For this reason, DSA1 and DSA2 should use
> different cryptographic assumptions. Additionally DSA2 should use a
> signature scheme that trades off efficiency for additional security and
> robustness. This way, we can get the best of both worlds, DSA1 can be used
> for everyday signatures and if DSA1 is broken, DSA2 can be used to migrate
> to a new signature scheme, say DSA3. Even if DSA3, chosen in haste to
> replace DSA1, is also found to be weak, holders are still protected. This
> is because DSA2 is unbroken, allowing us to replace DSA3 with DSA4.
>
> DSA1 - Efficient, low cost to use, should support nice-to-have features
> such as aggregation.
>
> DSA2 - Expensive, extreme levels of security, only used to transition to
> new signature schemes.
>
>
> A person with an HD seed buried in a coffee can for 75 years is still safe
> even if they don’t transition from DSA1 to DSA3 and since DSA2 is still
> safe. When they dig it up, they can use DSA2 to move the output to
> DSA3+DSA2.
>
> Given this framework, let’s think about DSA1 and DSA2 with concrete
> algorithms:
>
> - DSA1 is Schnorr, the currently supported Schnorr signature algorithmin
> Bitcoin.
>
> - DSA2 is SLH-DSA (SPHINCS+ SLH-DSA-SHA2-128s). SLH-DSA is a hash based
> signature algorithm. Hash based signatures are the most likely secure long
> term.
>
> If we merged BIP 360 and support for a SLH-DSA CHECKSIG opcode, holders
> could hedge against a classical or quantum attack against Schnorr, while
> still using Schnorr.
>
> Our approach mitigates the main drawback of the size of SLH-DSA
> signatures, their size. SLH-DSA signatures are 8 KB in size, while [0]
> explores methods for reducing the size of these signatures to 3 KB, 3 KB is
> still huge. Because SLH-DSA signatures would not have any additional
> discount, they would be very expensive in transaction fees, and only
> economically worthwhile to migrate from Schnorr to a new signature scheme.
> In all other cases the addition of SLH-DSA would exist as unused leaf
> scripts in the output, which increases the witness by 32 bytes.
>
> An additional benefit to this approach of using BIP 360 and SLH-DSA would
> be to buy time for non-hash based PQ signature schemes to mature. We are
> seeing rapid advances in research on post-quantum signature schemes and
> waiting a little long might buy us a lot. SLH-DSA would provide an
> effective hedge against this risk, while delaying the decision of what PQ
> signature scheme should replace Schnorr in the event of Schnorr's security
> being weakened.
>
> Q & A
> ====
>
> Q: Could these signatures be abused to store JPEGs on the blockchain?
> A: No because they would have no additional discount. This means they
> would have no advantage for JPEGs over what is currently possible.
>
> Q: Why not use XMSS or Lamport signatures instead of SLH_DSA?
> A: 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. That said, it is
> reasonable to consider stateful hash based signature schemes like XMSS,
> Winternitz, or Lamport signatures as the fallback signature, especially if
> size becomes a concern.
>
> Q: What non-consensus critical changes would be needed to support this?
> A; We’d need to create new wallet standards to provide alternatives to
> BIP32 xpubs. Wallet would have to write code to generate SLH-DSA keys and
> create a script tree per signature alg. Wallets would also have to put into
> place mechanisms to warn for and prevent public key reuse.
>
> Q: What consensus critical changes would be needed to support this?
> A: We’d need to merge something like BIP 360 and then a new CHECKSIG
> opcode for SLH_DSA.
>
>
> 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. People holding key spend path-only Taproot outputs would
> have the coins in those outputs destroyed. BIP 360, in essence is Taproot,
> without the key spend path. BIP 360 provides the same functionality as
> disabling Taproot key spend paths, but rather than being confiscatory, it
> is opt in.
>
> Q: Are you proposing this now because you think that the Bitcoin signature
> algorithms are under threat?
> A: No, I am confident in the Bitcoin signature algorithms and I know of no
> immediate threats. This effort is motivated by longtermism and thinking
> about how to enable Bitcoin to be safe on timescales of decades or
> centuries.
>
> [0]: Mikhail Kudinov, Jonas Nick, Hash-based Signature Schemes for Bitcoin
> (2025) https://eprint.iacr.org/2025/2203
>
> I want to acknowledge conduition’s feedback and suggestions on this email,
> including the sentence about xpubs. The ideas above resulted from
> conversations between myself, Hunter and Isabel. Similar ideas have been
> suggested on the list before. I make no claims of originality, I am
> organizing these ideas and my thoughts on them into a concrete design. All
> errors are my own.
>
> Thanks,
> Ethan
>
> --
> 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%2BWTqe8%3DuqChu2vN3HruiJCvFcDMNP%2BJA0AwyOkaR%3Dz0Cw%40mail.gmail.com
> <https://groups.google.com/d/msgid/bitcoindev/CAEM%3Dy%2BWTqe8%3DuqChu2vN3HruiJCvFcDMNP%2BJA0AwyOkaR%3Dz0Cw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>
>
>
--
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%2BUS1-QRgAXStAZ2tsJiPBeQtm7%3D_q7LrQdDHR%3DVAci%2BvA%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 37518 bytes --]
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms
[not found] ` <CAJowKg+WJLAJoMhyhVfkC9OSdks5jBieDWty9ce-Qju-84URFA@mail.gmail.com>
@ 2026-02-10 23:13 ` Ethan Heilman
2026-02-11 0:19 ` Erik Aronesty
0 siblings, 1 reply; 42+ messages in thread
From: Ethan Heilman @ 2026-02-10 23:13 UTC (permalink / raw)
To: Erik Aronesty; +Cc: Jonas Nick, bitcoindev
[-- Attachment #1: Type: text/plain, Size: 11533 bytes --]
> or we can just allow on-chain covenants (txhash) that can trivially
make secret-reveal scheme paths secure without signatures
You'd still need BIP 360 P2MR (or P2TRD) since OP_TXHASH needs tapscript,
and the only available tapscript supporting output type, P2TR, isn't
quantum safe.
I'm going to assume:
- you mean to use this commit-reveal for migrating between signature
algorithms, not for everyday use,
- TXHASH is being used because you are waiting for the commitment to be
confirmed on-chain rather than lifeboat's out-of-band commitment system
The main disadvantages of using commit-reveal in this manner are:
Once you post your commit-txn, but before it confirms, other parties can
post competing commit-txns that double spend your output. If one of
malicious transactions confirm, you must now wait for a timelock to expire
and then try to post your transaction. They can block you again. Each time
they burn some of you coins in fees. Miners get the fees, so they might be
incentivized to do this. Thus, we must trust miners not to do this.
Lifeboat doesn't have this issue since it uses out-of-band commitments, but
out-of-band commitments have their own issues.
Miners are now trusted more, since reorgs can steal funds.
I prefer SLH_DSA over commit-reveal as it preserves Bitcoin's trust
assumptions and user expectations. I see commit-reveal as valuable for the
case where our signature algorithms weaken rapidly and we don't have time
to push through a more complex solution.
On Tue, Feb 10, 2026 at 5:06 PM Erik Aronesty <erik@q32.com> wrote:
> or we can just allow on-chain covenants (txhash) that can trivially make
> secret-reveal scheme paths secure without signatures
>
> adding a flag that opts-in to path disablement on "q day" is nice because
> 99% chance it will never be needed, but is a good safety valve
>
>
>
> On Tue, Feb 10, 2026 at 12:49 PM Ethan Heilman <eth3rs@gmail.com> wrote:
>
>> 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
>> <https://groups.google.com/d/msgid/bitcoindev/CAEM%3Dy%2BU_PV7dA5Azr7D4Rnr40QaHKUrxdLmx0zPPjYoE-HZ%3DHw%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>
--
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%2BWdPbjVH24Bhb9pJGFoHe0k7%3DJRwG9VU49%2B7ZeCip0Csg%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 12911 bytes --]
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms
2026-02-10 23:13 ` Ethan Heilman
@ 2026-02-11 0:19 ` Erik Aronesty
2026-02-11 2:40 ` Ethan Heilman
2026-02-17 4:13 ` 'conduition' via Bitcoin Development Mailing List
0 siblings, 2 replies; 42+ messages in thread
From: Erik Aronesty @ 2026-02-11 0:19 UTC (permalink / raw)
To: Ethan Heilman; +Cc: Jonas Nick, bitcoindev
[-- Attachment #1: Type: text/plain, Size: 2342 bytes --]
>
>
>
> You'd still need BIP 360 P2MR (or P2TRD) since OP_TXHASH needs tapscript,
> and the only available tapscript supporting output type, P2TR, isn't
> quantum safe.
>
false, covenant based multistep secret-reveal spending paths don't rely on
signatures at all
>
> I'm going to assume:
> - you mean to use this commit-reveal for migrating between signature
> algorithms, not for everyday use,
>
it can be used if "q day" happens. otherwise ignored.
> - TXHASH is being used because you are waiting for the commitment to be
> confirmed on-chain rather than lifeboat's out-of-band commitment system
>
it's used so you can commit to a spending constraint without committing to
the final "as yet to be determined" quantum-safe destination:
https://delvingbitcoin.org/t/a-quantum-resistance-script-only-using-op-ctv-op-txhash-and-no-new-signatures/2168
> Once you post your commit-txn, but before it confirms, other parties can
> post competing commit-txns that double spend your output. If one of
> malicious transactions confirm, you must now wait for a timelock to expire
> and then try to post your transaction.
>
agreed. they have to spend resources to attack your private key and the
only thing they can do is "grief" using a timing attack with the results,
rather than steal outright. a massive incentive difference.
> They can block you again. Each time they burn some of you coins in fees.
> Miners get the fees, so they might be incentivized to do this. Thus, we
> must trust miners not to do this. Lifeboat doesn't have this issue since it
> uses out-of-band commitments, but out-of-band commitments have their own
> issues.
>
each time you use the reset-path, they have to re-attack a new key. very
expensive just to grief a small amount of fees spread across all miners.
sounds like science-fiction levels of compute.
plus.... TX_HASH is simple and generally useful and there is no guarantee
that q-day will even come
--
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/CAJowKgL5okUA%3DDHSyUJfzdb6p_z5a6H_hN6NuhZo6R9ZYbJFUQ%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 3880 bytes --]
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms
2026-02-11 0:19 ` Erik Aronesty
@ 2026-02-11 2:40 ` Ethan Heilman
2026-02-11 7:25 ` Erik Aronesty
2026-02-17 4:13 ` 'conduition' via Bitcoin Development Mailing List
1 sibling, 1 reply; 42+ messages in thread
From: Ethan Heilman @ 2026-02-11 2:40 UTC (permalink / raw)
To: Erik Aronesty; +Cc: Jonas Nick, bitcoindev
[-- Attachment #1: Type: text/plain, Size: 3980 bytes --]
>> You'd still need BIP 360 P2MR (or P2TRD) since OP_TXHASH needs
tapscript
> false, covenant based multistep secret-reveal spending paths don't rely
on signatures at all
P2TR has a public key baked into it via the key spend path. This key path
spend bypasses any covenant or script constraints. The attacker does not
need to see a value spend to break the key path spend. This means a quantum
attacker can break the nums point in key spend path of the initial output
and the AnchorPublishTx output and then just taking all the coins [0].
> agreed. they have to spend resources to attack your private key and the
only thing they can do is "grief" using a timing attack with the results,
rather than steal outright. a massive incentive difference.
Ok, so a core assumption you are making here is that a CRQC isn't powerful
enough for recovering signing keys to be effectively free. This is likely
to be true at the early stages of CRQC, but this assumption may not hold
forever. If ECC is mathematically broken via a classical attack this
assumption might not hold at all. I'm attempting to address both quantum
and classical breaks.
> TX_HASH is simple and generally useful and there is no guarantee that
q-day will even come
TX_HASH is great!
[0]: As originally noted here:
https://delvingbitcoin.org/t/a-quantum-resistance-script-only-using-op-ctv-op-txhash-and-no-new-signatures/2168/4
On Tue, Feb 10, 2026 at 7:19 PM Erik Aronesty <erik@q32.com> wrote:
>
>>
>> You'd still need BIP 360 P2MR (or P2TRD) since OP_TXHASH needs
>> tapscript, and the only available tapscript supporting output type, P2TR,
>> isn't quantum safe.
>>
>
> false, covenant based multistep secret-reveal spending paths don't rely on
> signatures at all
>
>
>>
>> I'm going to assume:
>> - you mean to use this commit-reveal for migrating between signature
>> algorithms, not for everyday use,
>>
>
> it can be used if "q day" happens. otherwise ignored.
>
>
>> - TXHASH is being used because you are waiting for the commitment to be
>> confirmed on-chain rather than lifeboat's out-of-band commitment system
>>
>
> it's used so you can commit to a spending constraint without committing to
> the final "as yet to be determined" quantum-safe destination:
> https://delvingbitcoin.org/t/a-quantum-resistance-script-only-using-op-ctv-op-txhash-and-no-new-signatures/2168
>
>
>
>> Once you post your commit-txn, but before it confirms, other parties can
>> post competing commit-txns that double spend your output. If one of
>> malicious transactions confirm, you must now wait for a timelock to expire
>> and then try to post your transaction.
>>
>
> agreed. they have to spend resources to attack your private key and the
> only thing they can do is "grief" using a timing attack with the results,
> rather than steal outright. a massive incentive difference.
>
>
>> They can block you again. Each time they burn some of you coins in fees.
>> Miners get the fees, so they might be incentivized to do this. Thus, we
>> must trust miners not to do this. Lifeboat doesn't have this issue since it
>> uses out-of-band commitments, but out-of-band commitments have their own
>> issues.
>>
>
> each time you use the reset-path, they have to re-attack a new key. very
> expensive just to grief a small amount of fees spread across all miners.
> sounds like science-fiction levels of compute.
>
>
> plus.... TX_HASH is simple and generally useful and there is no guarantee
> that q-day will even come
>
--
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%2BUKMTfAi_PT04Bpr%2BvjB3CwLck0etwvaM8nzWazqf-1ig%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 5945 bytes --]
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms
2026-02-11 2:40 ` Ethan Heilman
@ 2026-02-11 7:25 ` Erik Aronesty
2026-02-11 16:37 ` Ethan Heilman
0 siblings, 1 reply; 42+ messages in thread
From: Erik Aronesty @ 2026-02-11 7:25 UTC (permalink / raw)
To: Ethan Heilman; +Cc: Jonas Nick, bitcoindev
[-- Attachment #1: Type: text/plain, Size: 4271 bytes --]
i see so a minimal change to taproot would be a new version: “script spend
only” or similar.
On Tue, Feb 10, 2026 at 6:41 PM Ethan Heilman <eth3rs@gmail.com> wrote:
> >> You'd still need BIP 360 P2MR (or P2TRD) since OP_TXHASH needs
> tapscript
> > false, covenant based multistep secret-reveal spending paths don't rely
> on signatures at all
>
> P2TR has a public key baked into it via the key spend path. This key path
> spend bypasses any covenant or script constraints. The attacker does not
> need to see a value spend to break the key path spend. This means a quantum
> attacker can break the nums point in key spend path of the initial output
> and the AnchorPublishTx output and then just taking all the coins [0].
>
> > agreed. they have to spend resources to attack your private key and the
> only thing they can do is "grief" using a timing attack with the results,
> rather than steal outright. a massive incentive difference.
>
> Ok, so a core assumption you are making here is that a CRQC isn't powerful
> enough for recovering signing keys to be effectively free. This is likely
> to be true at the early stages of CRQC, but this assumption may not hold
> forever. If ECC is mathematically broken via a classical attack this
> assumption might not hold at all. I'm attempting to address both quantum
> and classical breaks.
>
> > TX_HASH is simple and generally useful and there is no guarantee that
> q-day will even come
>
> TX_HASH is great!
>
> [0]: As originally noted here:
> https://delvingbitcoin.org/t/a-quantum-resistance-script-only-using-op-ctv-op-txhash-and-no-new-signatures/2168/4
>
> On Tue, Feb 10, 2026 at 7:19 PM Erik Aronesty <erik@q32.com> wrote:
>
>>
>>>
>>> You'd still need BIP 360 P2MR (or P2TRD) since OP_TXHASH needs
>>> tapscript, and the only available tapscript supporting output type, P2TR,
>>> isn't quantum safe.
>>>
>>
>> false, covenant based multistep secret-reveal spending paths don't rely
>> on signatures at all
>>
>>
>>>
>>> I'm going to assume:
>>> - you mean to use this commit-reveal for migrating between signature
>>> algorithms, not for everyday use,
>>>
>>
>> it can be used if "q day" happens. otherwise ignored.
>>
>>
>>> - TXHASH is being used because you are waiting for the commitment to be
>>> confirmed on-chain rather than lifeboat's out-of-band commitment system
>>>
>>
>> it's used so you can commit to a spending constraint without committing
>> to the final "as yet to be determined" quantum-safe destination:
>> https://delvingbitcoin.org/t/a-quantum-resistance-script-only-using-op-ctv-op-txhash-and-no-new-signatures/2168
>>
>>
>>
>>> Once you post your commit-txn, but before it confirms, other parties can
>>> post competing commit-txns that double spend your output. If one of
>>> malicious transactions confirm, you must now wait for a timelock to expire
>>> and then try to post your transaction.
>>>
>>
>> agreed. they have to spend resources to attack your private key and the
>> only thing they can do is "grief" using a timing attack with the results,
>> rather than steal outright. a massive incentive difference.
>>
>>
>>> They can block you again. Each time they burn some of you coins in fees.
>>> Miners get the fees, so they might be incentivized to do this. Thus, we
>>> must trust miners not to do this. Lifeboat doesn't have this issue since it
>>> uses out-of-band commitments, but out-of-band commitments have their own
>>> issues.
>>>
>>
>> each time you use the reset-path, they have to re-attack a new key. very
>> expensive just to grief a small amount of fees spread across all miners.
>> sounds like science-fiction levels of compute.
>>
>>
>> plus.... TX_HASH is simple and generally useful and there is no guarantee
>> that q-day will even come
>>
>
--
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/CAJowKg%2BruUmiwxJLppALCuGSRO0v%2BJg0m2TeMrmzgKQYj-pQBg%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 6423 bytes --]
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms
2026-02-11 7:25 ` Erik Aronesty
@ 2026-02-11 16:37 ` Ethan Heilman
0 siblings, 0 replies; 42+ messages in thread
From: Ethan Heilman @ 2026-02-11 16:37 UTC (permalink / raw)
To: Erik Aronesty; +Cc: Jonas Nick, bitcoindev
[-- Attachment #1: Type: text/plain, Size: 5536 bytes --]
> i see so a minimal change to taproot would be a new version: “script
spend only” or similar.
BIP 360's P2MR (Pay-to-Merkle-Root) is P2TR but script spend only via a
simple and minimal change.
Thanks for working on commit-reveal -- also thanks to Tadge for lifeboat, I
think this line of research is worthwhile and helpful. Correct me if you
disagree, I think of commit-reveal as useful for the following case: Q-day
happens AND we have P2MR AND OP_TXHASH, but not OP_SLH_CHECKSIG,
commit-reveal might be the best option to migrate to a PQ signature scheme.
I am pursuing the P2MR + OP_SLH_CHECKSIG approach this approach is the
least disruptive to how people use Bitcoin today and would be simpler for
wallets to support (SLH only requires signing a single transaction vs. two
transactions and having to handle griefing/reset).
In both cases we want BIP 360's P2MR. I'd also like OP_TXHASH and
OP_SLH_CHECKSIG as well.
I'm using OP_SLH_CHECKSIG as a placeholder here, if you like
OP_SHRINCS_CHECKSIG better, you could also do P2MR + OP_SHRINCS_CHECKSIG
On Wed, Feb 11, 2026 at 2:25 AM Erik Aronesty <erik@q32.com> wrote:
> i see so a minimal change to taproot would be a new version: “script spend
> only” or similar.
>
> On Tue, Feb 10, 2026 at 6:41 PM Ethan Heilman <eth3rs@gmail.com> wrote:
>
>> >> You'd still need BIP 360 P2MR (or P2TRD) since OP_TXHASH needs
>> tapscript
>> > false, covenant based multistep secret-reveal spending paths don't
>> rely on signatures at all
>>
>> P2TR has a public key baked into it via the key spend path. This key path
>> spend bypasses any covenant or script constraints. The attacker does not
>> need to see a value spend to break the key path spend. This means a quantum
>> attacker can break the nums point in key spend path of the initial output
>> and the AnchorPublishTx output and then just taking all the coins [0].
>>
>> > agreed. they have to spend resources to attack your private key and
>> the only thing they can do is "grief" using a timing attack with the
>> results, rather than steal outright. a massive incentive difference.
>>
>> Ok, so a core assumption you are making here is that a CRQC isn't
>> powerful enough for recovering signing keys to be effectively free. This is
>> likely to be true at the early stages of CRQC, but this assumption may not
>> hold forever. If ECC is mathematically broken via a classical attack this
>> assumption might not hold at all. I'm attempting to address both quantum
>> and classical breaks.
>>
>> > TX_HASH is simple and generally useful and there is no guarantee that
>> q-day will even come
>>
>> TX_HASH is great!
>>
>> [0]: As originally noted here:
>> https://delvingbitcoin.org/t/a-quantum-resistance-script-only-using-op-ctv-op-txhash-and-no-new-signatures/2168/4
>>
>> On Tue, Feb 10, 2026 at 7:19 PM Erik Aronesty <erik@q32.com> wrote:
>>
>>>
>>>>
>>>> You'd still need BIP 360 P2MR (or P2TRD) since OP_TXHASH needs
>>>> tapscript, and the only available tapscript supporting output type, P2TR,
>>>> isn't quantum safe.
>>>>
>>>
>>> false, covenant based multistep secret-reveal spending paths don't rely
>>> on signatures at all
>>>
>>>
>>>>
>>>> I'm going to assume:
>>>> - you mean to use this commit-reveal for migrating between signature
>>>> algorithms, not for everyday use,
>>>>
>>>
>>> it can be used if "q day" happens. otherwise ignored.
>>>
>>>
>>>> - TXHASH is being used because you are waiting for the commitment to be
>>>> confirmed on-chain rather than lifeboat's out-of-band commitment system
>>>>
>>>
>>> it's used so you can commit to a spending constraint without committing
>>> to the final "as yet to be determined" quantum-safe destination:
>>> https://delvingbitcoin.org/t/a-quantum-resistance-script-only-using-op-ctv-op-txhash-and-no-new-signatures/2168
>>>
>>>
>>>
>>>> Once you post your commit-txn, but before it confirms, other parties
>>>> can post competing commit-txns that double spend your output. If one of
>>>> malicious transactions confirm, you must now wait for a timelock to expire
>>>> and then try to post your transaction.
>>>>
>>>
>>> agreed. they have to spend resources to attack your private key and the
>>> only thing they can do is "grief" using a timing attack with the results,
>>> rather than steal outright. a massive incentive difference.
>>>
>>>
>>>> They can block you again. Each time they burn some of you coins in
>>>> fees. Miners get the fees, so they might be incentivized to do this. Thus,
>>>> we must trust miners not to do this. Lifeboat doesn't have this issue since
>>>> it uses out-of-band commitments, but out-of-band commitments have their own
>>>> issues.
>>>>
>>>
>>> each time you use the reset-path, they have to re-attack a new key.
>>> very expensive just to grief a small amount of fees spread across all
>>> miners. sounds like science-fiction levels of compute.
>>>
>>>
>>> plus.... TX_HASH is simple and generally useful and there is no
>>> guarantee that q-day will even come
>>>
>>
--
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%2BUNum_%3D1Me0Q%3DfBc7oS6s4i_GwZEw1Ad60S_efHOVnqMw%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 7976 bytes --]
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms
2026-02-10 16:44 ` Ethan Heilman
[not found] ` <CAJowKg+WJLAJoMhyhVfkC9OSdks5jBieDWty9ce-Qju-84URFA@mail.gmail.com>
@ 2026-02-11 18:53 ` Matt Corallo
2026-02-11 22:57 ` Ethan Heilman
2026-02-12 15:36 ` waxwing/ AdamISZ
1 sibling, 2 replies; 42+ messages in thread
From: Matt Corallo @ 2026-02-11 18:53 UTC (permalink / raw)
To: Ethan Heilman, Jonas Nick; +Cc: bitcoindev
On 2/10/26 11:44 AM, Ethan Heilman wrote:
> > 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.
For what its worth I do not see a scenario where a decision ultimately made by the market will pick
the fork side with materially, say 5-10x higher, supply, over the side with lower supply...supply
and demand is king, especially with the "confiscatory" nature is basically nil as ~all wallets today
use seedphrases, which could still be spent with a ZK proof-of-seedphrase :).
> 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.
The drawback being that it will see zero relevant adoption until its way too late.
The only entities that would reasonably adopt something like this are large custodians, who aren't
worth worrying about as they'll easily migrate all their coins over the course of a few days or
weeks in an emergency scenario, and highly specialty wallets. The point of any PQ soft fork today is
if it can actually drive wallets to start making progress on PQ deployment. A new address type that
is 10x more expensive to transact with is going to see ~zero adoption in "consumer wallets" until
its urgent, at which point its obviously way, way too late.
Hell, *any* PQ soft fork is going to see limited adoption in "consumer wallets" until its urgent,
hence why I think the community will be basically forced to disable insecure spend paths and only
allow spends via ZK proof-of-seedphrase. But at least something that doesn't also 10x transaction
costs might reasonably be adopted by default by wallets that don't use seedphrases like Bitcoin Core.
> > 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.
No it doesn't - it requires a soft fork when the risk is imminent, but it happening somewhat before
that time is okay too.
> 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.
I mean people can create invalid addresses today in plenty of ways. How is this unique?
> 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.
It would almost certainly just be a key derived from the seedphrase via another hash function, so
there's no real risk of this.
Matt
--
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/22073a56-1cbf-4ba9-a2ea-46c621d4619c%40mattcorallo.com.
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms
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:13 ` Alex
2026-02-12 15:36 ` waxwing/ AdamISZ
1 sibling, 2 replies; 42+ messages in thread
From: Ethan Heilman @ 2026-02-11 22:57 UTC (permalink / raw)
To: Matt Corallo; +Cc: Jonas Nick, bitcoindev
[-- Attachment #1: Type: text/plain, Size: 8582 bytes --]
> For what its worth I do not see a scenario where a decision ultimately
made by the market will pick the fork side with materially, say 5-10x
higher, supply, over the side with lower supply...
Completely agree, the incentives favor lower supply. I wouldn't want to
count on it happening and even if it does happen the freeze fork might not
freeze P2TR. According to the 2025 chaincode report [0] P2TR represents
only 0.75% of total supply.
> ~all wallets today use seedphrases, which could still be spent with a ZK
proof-of-seedphrase :).
I'm all for putting ZKPs in consensus, but it seems unlikely to me that it
will happen. It is better to make Bitcoin safe than promise safety that
requires a future hardfork. This is especially true since as you point out
lower supply is incentivized, so a soft fork that freezes coins would be
fighting an uphill battle.
> Hell, *any* PQ soft fork is going to see limited adoption in "consumer
wallets" until its urgent, hence why I think the community will be
basically forced to disable insecure spend paths and only
allow spends via ZK proof-of-seedphrase. But at least something that
doesn't also 10x transaction costs might reasonably be adopted by default
by wallets that don't use seedphrases like Bitcoin Core.
I disagree. If we get P2MR and SLH_DSA/SHRINCS the wallets can use
quantum-safe outputs (Schnorr OR PQ) with Schnorr as the default spend. The
wallets can market themselves as quantum safe. The cost in transaction fees
to a user is small, a 1 input P2MR transaction would only be 37 bytes
larger when compared with a 1 input P2TR transaction. Those 37 bytes are in
the witness, so the real cost is ~10 vbytes.
Yes, if Q-day happens, time passes and then quantum computers become
powerful enough to perform short-exposure attacks, anyone needing to move
their coins to an output have to pay fees for an additional 8,000 bytes
(SLH_DSA) or 324 bytes (SHRINCs). This is still better than a PQ ZKP proof
of the seed which would be between 20,000 to 120,000 bytes and more likely
to have a security flaw than SLH_DSA.
If efficient quantum signatures or compression techniques are developed, we
can and should adopt them. If they are efficient enough, they can become
the default. This proposal is designed to keep funds safe in the
intermediate period while better techniques are developed to cover the tail
risk where Q-day happens before the technology we need to completely ready.
> No it doesn't - it requires a soft fork when the risk is imminent, but
it happening somewhat before that time is okay too.
We might wait too long and misjudge the risk and Q-day happens before the
soft fork activates? What happens if freeze fork is activated but then 3
years pass and it looks like a CRQC isn't going to happen after all? Now
people who had their coins frozen are pushing to undo the soft fork.
This approach carries too much risk from uncertainty and it was "the plan"
it signles that Bitcoin leaving things up to chance that don't have to be
left to chance.
Enabling people to opt in as early as possible enables the prudent to
protect themselves for very little effort and cost. Those people know their
coins are safe and can still use their coin as they did before.
> I mean people can create invalid addresses today in plenty of ways. How
is this unique?
P2TRD would be an address, which looks exactly like a 100% valid address
and which can be spend from like a valid address and hwoever at some future
time, it may or may not, become frozen.
[0]: https://chaincode.com/bitcoin-post-quantum.pdf
On Wed, Feb 11, 2026 at 1:53 PM Matt Corallo <lf-lists@mattcorallo.com>
wrote:
>
>
> On 2/10/26 11:44 AM, Ethan Heilman wrote:
> > > 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.
>
> For what its worth I do not see a scenario where a decision ultimately
> made by the market will pick
> the fork side with materially, say 5-10x higher, supply, over the side
> with lower supply...supply
> and demand is king, especially with the "confiscatory" nature is basically
> nil as ~all wallets today
> use seedphrases, which could still be spent with a ZK proof-of-seedphrase
> :).
>
> > 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.
>
> The drawback being that it will see zero relevant adoption until its way
> too late.
>
> The only entities that would reasonably adopt something like this are
> large custodians, who aren't
> worth worrying about as they'll easily migrate all their coins over the
> course of a few days or
> weeks in an emergency scenario, and highly specialty wallets. The point of
> any PQ soft fork today is
> if it can actually drive wallets to start making progress on PQ
> deployment. A new address type that
> is 10x more expensive to transact with is going to see ~zero adoption in
> "consumer wallets" until
> its urgent, at which point its obviously way, way too late.
>
> Hell, *any* PQ soft fork is going to see limited adoption in "consumer
> wallets" until its urgent,
> hence why I think the community will be basically forced to disable
> insecure spend paths and only
> allow spends via ZK proof-of-seedphrase. But at least something that
> doesn't also 10x transaction
> costs might reasonably be adopted by default by wallets that don't use
> seedphrases like Bitcoin Core.
>
> > > 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.
>
> No it doesn't - it requires a soft fork when the risk is imminent, but it
> happening somewhat before
> that time is okay too.
>
> > 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.
>
> I mean people can create invalid addresses today in plenty of ways. How is
> this unique?
>
> > 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.
>
> It would almost certainly just be a key derived from the seedphrase via
> another hash function, so
> there's no real risk of this.
>
> Matt
>
--
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%2BWRk6JU2xNdh6YYQE9VmkH1kv-CwBSYBxu0C0WocyKwNQ%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 9599 bytes --]
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms
2026-02-11 22:57 ` Ethan Heilman
@ 2026-02-12 14:55 ` Matt Corallo
2026-02-12 15:35 ` Alex
2026-02-12 18:08 ` Ethan Heilman
2026-02-12 15:13 ` Alex
1 sibling, 2 replies; 42+ messages in thread
From: Matt Corallo @ 2026-02-12 14:55 UTC (permalink / raw)
To: Ethan Heilman; +Cc: Jonas Nick, bitcoindev
On 2/11/26 5:57 PM, Ethan Heilman wrote:
> > For what its worth I do not see a scenario where a decision ultimately made by the market will
> pick the fork side with materially, say 5-10x higher, supply, over the side with lower supply...
>
> Completely agree, the incentives favor lower supply. I wouldn't want to count on it happening and
> even if it does happen the freeze fork might not freeze P2TR. According to the 2025 chaincode report
> [0] P2TR represents only 0.75% of total supply.
I believe we're talking past each other, then. This was a side note - as Jonas mentioned it seems
reasonable that a P2TR-based QC signature validation opcode could come with an on-chain signaling
bit (i.e. a "Taproot V2" that is functionally identical but indicates the presence of a QC signature
script path available).
> > ~all wallets today use seedphrases, which could still be spent with a ZK proof-of-seedphrase :).
>
> I'm all for putting ZKPs in consensus, but it seems unlikely to me that it will happen.
We just agreed that its highly likely that insecure spend paths are disabled. I do not remotely see
how such an action could occur if the result is that a large number of coins are seized. The only
viable approach way for that is to allow seedphrase-based wallets to retain access.
> It is better
> to make Bitcoin safe than promise safety that requires a future hardfork.
There is no hardfork required here.
> This is especially true
> since as you point out lower supply is incentivized, so a soft fork that freezes coins would be
> fighting an uphill battle.
I'm confused by this comment - a soft fork that disables insecure spend paths to avoid them being
stolen is likely going to have a very easy time, not "fight an uphill battle"?
> > Hell, *any* PQ soft fork is going to see limited adoption in "consumer wallets" until its
> urgent, hence why I think the community will be basically forced to disable insecure spend paths and
> only
> allow spends via ZK proof-of-seedphrase. But at least something that doesn't also 10x
> transaction costs might reasonably be adopted by default by wallets that don't use seedphrases like
> Bitcoin Core.
>
> I disagree. If we get P2MR and SLH_DSA/SHRINCS the wallets can use quantum-safe outputs (Schnorr OR
> PQ) with Schnorr as the default spend. The wallets can market themselves as quantum safe.
This flies in the face of the last 15 years of experience with Bitcoin wallets. Yea, it sounds
great, but we've got 15 years of experience showing that wallets only adapt when they go out of
business/stop being maintained and get replaced with new wallets (which often ship with the latest
technology). Worse, many bitcoiners (maybe rightfully, maybe not) entirely write off the quantum
threat - all the more reason they will simply not adopt any changes.
> The cost
> in transaction fees to a user is small, a 1 input P2MR transaction would only be 37 bytes larger
> when compared with a 1 input P2TR transaction. Those 37 bytes are in the witness, so the real cost
> is ~10 vbytes.
Apologies, I had understood the P2MR proposal to only feature PQC-based schemes, rather than also
offering schnorr as an option, leading me to incorrectly conclude it would be drastically more
expensive, rather than marginally so.
Still, I think my point stands - in the face of many bitcoiners writing off the quantum threat,
wallets aren't going to have a lot of incentive to adopt technologies that make things marginally
more expensive.
Worse, there's no real advantage here over just doing in the taproot key path - because of address
reuse a wallet relying on P2MR + schnorr anyway will ~always have its public key revealed so we
might as well continue relying on P2TR to save the 37 witness bytes and get the same result (that
wallets can do something cheap with "just" a key derivation change and explicitly opt in to a future
soft fork which disables the then-insecure spend paths).
> Yes, if Q-day happens, time passes and then quantum computers become powerful enough to perform
> short-exposure attacks, anyone needing to move their coins to an output have to pay fees for an
> additional 8,000 bytes (SLH_DSA) or 324 bytes (SHRINCs). This is still better than a PQ ZKP proof of
> the seed which would be between 20,000 to 120,000 bytes and more likely to have a security flaw than
> SLH_DSA.
Yep, I'm not proposing at all that we do nothing because a ZKP of seedphrase is an option, rather we
should add support for SHRINCS and encourage wallet adoption. But at the same time we should
understand that we're incredibly unlikely to see the kind of adoption in time to avoid the need to
do something like a ZKP of seedphrase when the time comes.
This is also probably the least interesting point of contention, FWIW - this is a decision for a
future bitcoin community, not a decision for us to make today.
> If efficient quantum signatures or compression techniques are developed, we can and should adopt
> them. If they are efficient enough, they can become the default. This proposal is designed to keep
> funds safe in the intermediate period while better techniques are developed to cover the tail risk
> where Q-day happens before the technology we need to completely ready.
Yep, we absolutely agree! I just don't see a reason to do P2MR over just utilizing P2TR (or maybe
P2TRv2).
> > No it doesn't - it requires a soft fork when the risk is imminent, but it happening somewhat
> before that time is okay too.
>
> We might wait too long and misjudge the risk and Q-day happens before the soft fork activates? What
> happens if freeze fork is activated but then 3 years pass and it looks like a CRQC isn't going to
> happen after all? Now people who had their coins frozen are pushing to undo the soft fork.
> This approach carries too much risk from uncertainty and it was "the plan" it signles that Bitcoin
> leaving things up to chance that don't have to be left to chance.
>
> Enabling people to opt in as early as possible enables the prudent to protect themselves for very
> little effort and cost. Those people know their coins are safe and can still use their coin as they
> did before.
We agree. I believe your response is based on a misunderstanding of my argument, hopefully clarified
above.
> > I mean people can create invalid addresses today in plenty of ways. How is this unique?
>
> P2TRD would be an address, which looks exactly like a 100% valid address and which can be spend from
> like a valid address and hwoever at some future time, it may or may not, become frozen.
Sure, but this is still no different than any other P2TR script-path structure - you have to test
things you use, even if you use them rarely, which is the entire point of the P2TR design :).
Matt
--
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/1f0ebca9-2d23-44f9-8e6d-aaea99a832e3%40mattcorallo.com.
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms
2026-02-11 22:57 ` Ethan Heilman
2026-02-12 14:55 ` Matt Corallo
@ 2026-02-12 15:13 ` Alex
2026-02-12 19:16 ` Matt Corallo
1 sibling, 1 reply; 42+ messages in thread
From: Alex @ 2026-02-12 15:13 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 10555 bytes --]
> A new address type that
is 10x more expensive to transact with is going to see ~zero adoption in
"consumer wallets" until
its urgent, at which point its obviously way, way too late.
This is dishonest strawman argumentation that only misrepresents the
proposal incorrectly.
Migrating to a BIP360 wallet does not mean you pay 10x in fees. That is a
made up claim. The proposal clearly states you still continue to use cheap
Schnorr signatures, cheaply as before, while having a backup SLH-DSA script
spend (that you never actually use until Schnorr is fully broken, or never).
You do not pay for scripts that you never use and you only pay the 10x fee
if you want (which you will want when all other signatures are fully
broken). And having a migration ready & settled _before_ Q-day so you know
for sure you can move your funds (at 10x the cost) even after Q-day is an
enormous relief to everyone holding more than peanuts.
This is a forwards compatible migration that has no extra cost until you
freely decide to pay for the extra security (which should be an obvious
decision if ever Schnorr gets entirely broken). SLH-DSA in inefficient but
simple to implement. Having it as an OP-code means you can wait for more
efficient signatures to mature (like SQIsign) and then use SLH-DSA to
migrate to SQIsign.
SLH-DSA would be a stepping stone, a guarantee that you can always move
your funds even after Q-day. It is clearly not meant to be your default
signature (which is explicitly stated in the post).
torsdag 12 februari 2026 kl. 00:14:35 UTC+1 skrev Ethan Heilman:
> > For what its worth I do not see a scenario where a decision ultimately
> made by the market will pick the fork side with materially, say 5-10x
> higher, supply, over the side with lower supply...
>
> Completely agree, the incentives favor lower supply. I wouldn't want to
> count on it happening and even if it does happen the freeze fork might not
> freeze P2TR. According to the 2025 chaincode report [0] P2TR represents
> only 0.75% of total supply.
>
>
> > ~all wallets today use seedphrases, which could still be spent with a
> ZK proof-of-seedphrase :).
>
> I'm all for putting ZKPs in consensus, but it seems unlikely to me that it
> will happen. It is better to make Bitcoin safe than promise safety that
> requires a future hardfork. This is especially true since as you point out
> lower supply is incentivized, so a soft fork that freezes coins would be
> fighting an uphill battle.
>
>
> > Hell, *any* PQ soft fork is going to see limited adoption in
> "consumer wallets" until its urgent, hence why I think the community will
> be basically forced to disable insecure spend paths and only
> allow spends via ZK proof-of-seedphrase. But at least something that
> doesn't also 10x transaction costs might reasonably be adopted by default
> by wallets that don't use seedphrases like Bitcoin Core.
>
> I disagree. If we get P2MR and SLH_DSA/SHRINCS the wallets can use
> quantum-safe outputs (Schnorr OR PQ) with Schnorr as the default spend. The
> wallets can market themselves as quantum safe. The cost in transaction fees
> to a user is small, a 1 input P2MR transaction would only be 37 bytes
> larger when compared with a 1 input P2TR transaction. Those 37 bytes are in
> the witness, so the real cost is ~10 vbytes.
>
> Yes, if Q-day happens, time passes and then quantum computers become
> powerful enough to perform short-exposure attacks, anyone needing to move
> their coins to an output have to pay fees for an additional 8,000 bytes
> (SLH_DSA) or 324 bytes (SHRINCs). This is still better than a PQ ZKP proof
> of the seed which would be between 20,000 to 120,000 bytes and more likely
> to have a security flaw than SLH_DSA.
>
> If efficient quantum signatures or compression techniques are developed,
> we can and should adopt them. If they are efficient enough, they can become
> the default. This proposal is designed to keep funds safe in the
> intermediate period while better techniques are developed to cover the tail
> risk where Q-day happens before the technology we need to completely ready.
>
>
> > No it doesn't - it requires a soft fork when the risk is imminent, but
> it happening somewhat before that time is okay too.
>
> We might wait too long and misjudge the risk and Q-day happens before the
> soft fork activates? What happens if freeze fork is activated but then 3
> years pass and it looks like a CRQC isn't going to happen after all? Now
> people who had their coins frozen are pushing to undo the soft fork.
>
> This approach carries too much risk from uncertainty and it was "the plan"
> it signles that Bitcoin leaving things up to chance that don't have to be
> left to chance.
>
> Enabling people to opt in as early as possible enables the prudent to
> protect themselves for very little effort and cost. Those people know their
> coins are safe and can still use their coin as they did before.
>
>
> > I mean people can create invalid addresses today in plenty of ways. How
> is this unique?
>
> P2TRD would be an address, which looks exactly like a 100% valid address
> and which can be spend from like a valid address and hwoever at some future
> time, it may or may not, become frozen.
>
> [0]: https://chaincode.com/bitcoin-post-quantum.pdf
>
> On Wed, Feb 11, 2026 at 1:53 PM Matt Corallo <lf-l...@mattcorallo.com>
> wrote:
>
>>
>>
>> On 2/10/26 11:44 AM, Ethan Heilman wrote:
>> > > 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.
>>
>> For what its worth I do not see a scenario where a decision ultimately
>> made by the market will pick
>> the fork side with materially, say 5-10x higher, supply, over the side
>> with lower supply...supply
>> and demand is king, especially with the "confiscatory" nature is
>> basically nil as ~all wallets today
>> use seedphrases, which could still be spent with a ZK proof-of-seedphrase
>> :).
>>
>> > 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.
>>
>> The drawback being that it will see zero relevant adoption until its way
>> too late.
>>
>> The only entities that would reasonably adopt something like this are
>> large custodians, who aren't
>> worth worrying about as they'll easily migrate all their coins over the
>> course of a few days or
>> weeks in an emergency scenario, and highly specialty wallets. The point
>> of any PQ soft fork today is
>> if it can actually drive wallets to start making progress on PQ
>> deployment. A new address type that
>> is 10x more expensive to transact with is going to see ~zero adoption in
>> "consumer wallets" until
>> its urgent, at which point its obviously way, way too late.
>>
>> Hell, *any* PQ soft fork is going to see limited adoption in "consumer
>> wallets" until its urgent,
>> hence why I think the community will be basically forced to disable
>> insecure spend paths and only
>> allow spends via ZK proof-of-seedphrase. But at least something that
>> doesn't also 10x transaction
>> costs might reasonably be adopted by default by wallets that don't use
>> seedphrases like Bitcoin Core.
>>
>> > > 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.
>>
>> No it doesn't - it requires a soft fork when the risk is imminent, but it
>> happening somewhat before
>> that time is okay too.
>>
>> > 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.
>>
>> I mean people can create invalid addresses today in plenty of ways. How
>> is this unique?
>>
>> > 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.
>>
>> It would almost certainly just be a key derived from the seedphrase via
>> another hash function, so
>> there's no real risk of this.
>>
>> Matt
>>
>
--
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/9d991f8a-6eaf-4701-9226-9a35abc89b35n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 11869 bytes --]
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms
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
1 sibling, 1 reply; 42+ messages in thread
From: Alex @ 2026-02-12 15:35 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 8679 bytes --]
> wallets aren't going to have a lot of incentive to adopt technologies
that make things marginally
more expensive.
This claim is not rooted in reality. We literally just now saw Trezor
market their Safe 7 as Quantum Ready and they had a major ad campaign
specifically for this. There is major incentive for wallets to "sell" the
quantum threat as a problem to fix, and therefore sell more wallets or
claim compliance to gain market share. The quantum threat is mainstream.
Retail knows about it, talks about it all the time.
> many bitcoiners writing off the quantum threat
Yes because psychologically, the most successful Bitcoiners are those who
never reacted to any FUD and therefore never sold. And so they are
essentially naturally selected by their history of never reacting to FUD.
We've basically evolved the most non-reactant people and so obviously they
are not going to react to the quantum threat because why would they change
their strategy of never reacting if it worked so well so far?
torsdag 12 februari 2026 kl. 16:01:27 UTC+1 skrev Matt Corallo:
>
>
> On 2/11/26 5:57 PM, Ethan Heilman wrote:
> > > For what its worth I do not see a scenario where a decision ultimately
> made by the market will
> > pick the fork side with materially, say 5-10x higher, supply, over the
> side with lower supply...
> >
> > Completely agree, the incentives favor lower supply. I wouldn't want to
> count on it happening and
> > even if it does happen the freeze fork might not freeze P2TR. According
> to the 2025 chaincode report
> > [0] P2TR represents only 0.75% of total supply.
>
> I believe we're talking past each other, then. This was a side note - as
> Jonas mentioned it seems
> reasonable that a P2TR-based QC signature validation opcode could come
> with an on-chain signaling
> bit (i.e. a "Taproot V2" that is functionally identical but indicates the
> presence of a QC signature
> script path available).
>
> > > ~all wallets today use seedphrases, which could still be spent with a
> ZK proof-of-seedphrase :).
> >
> > I'm all for putting ZKPs in consensus, but it seems unlikely to me that
> it will happen.
>
> We just agreed that its highly likely that insecure spend paths are
> disabled. I do not remotely see
> how such an action could occur if the result is that a large number of
> coins are seized. The only
> viable approach way for that is to allow seedphrase-based wallets to
> retain access.
>
> > It is better
> > to make Bitcoin safe than promise safety that requires a future hardfork.
>
> There is no hardfork required here.
>
> > This is especially true
> > since as you point out lower supply is incentivized, so a soft fork that
> freezes coins would be
> > fighting an uphill battle.
>
> I'm confused by this comment - a soft fork that disables insecure spend
> paths to avoid them being
> stolen is likely going to have a very easy time, not "fight an uphill
> battle"?
>
> > > Hell, *any* PQ soft fork is going to see limited adoption in "consumer
> wallets" until its
> > urgent, hence why I think the community will be basically forced to
> disable insecure spend paths and
> > only
> > allow spends via ZK proof-of-seedphrase. But at least something that
> doesn't also 10x
> > transaction costs might reasonably be adopted by default by wallets that
> don't use seedphrases like
> > Bitcoin Core.
> >
> > I disagree. If we get P2MR and SLH_DSA/SHRINCS the wallets can use
> quantum-safe outputs (Schnorr OR
> > PQ) with Schnorr as the default spend. The wallets can market themselves
> as quantum safe.
>
> This flies in the face of the last 15 years of experience with Bitcoin
> wallets. Yea, it sounds
> great, but we've got 15 years of experience showing that wallets only
> adapt when they go out of
> business/stop being maintained and get replaced with new wallets (which
> often ship with the latest
> technology). Worse, many bitcoiners (maybe rightfully, maybe not) entirely
> write off the quantum
> threat - all the more reason they will simply not adopt any changes.
>
> > The cost
> > in transaction fees to a user is small, a 1 input P2MR transaction would
> only be 37 bytes larger
> > when compared with a 1 input P2TR transaction. Those 37 bytes are in the
> witness, so the real cost
> > is ~10 vbytes.
>
> Apologies, I had understood the P2MR proposal to only feature PQC-based
> schemes, rather than also
> offering schnorr as an option, leading me to incorrectly conclude it would
> be drastically more
> expensive, rather than marginally so.
>
> Still, I think my point stands - in the face of many bitcoiners writing
> off the quantum threat,
> wallets aren't going to have a lot of incentive to adopt technologies that
> make things marginally
> more expensive.
>
> Worse, there's no real advantage here over just doing in the taproot key
> path - because of address
> reuse a wallet relying on P2MR + schnorr anyway will ~always have its
> public key revealed so we
> might as well continue relying on P2TR to save the 37 witness bytes and
> get the same result (that
> wallets can do something cheap with "just" a key derivation change and
> explicitly opt in to a future
> soft fork which disables the then-insecure spend paths).
>
> > Yes, if Q-day happens, time passes and then quantum computers become
> powerful enough to perform
> > short-exposure attacks, anyone needing to move their coins to an output
> have to pay fees for an
> > additional 8,000 bytes (SLH_DSA) or 324 bytes (SHRINCs). This is still
> better than a PQ ZKP proof of
> > the seed which would be between 20,000 to 120,000 bytes and more likely
> to have a security flaw than
> > SLH_DSA.
>
> Yep, I'm not proposing at all that we do nothing because a ZKP of
> seedphrase is an option, rather we
> should add support for SHRINCS and encourage wallet adoption. But at the
> same time we should
> understand that we're incredibly unlikely to see the kind of adoption in
> time to avoid the need to
> do something like a ZKP of seedphrase when the time comes.
>
> This is also probably the least interesting point of contention, FWIW -
> this is a decision for a
> future bitcoin community, not a decision for us to make today.
>
> > If efficient quantum signatures or compression techniques are developed,
> we can and should adopt
> > them. If they are efficient enough, they can become the default. This
> proposal is designed to keep
> > funds safe in the intermediate period while better techniques are
> developed to cover the tail risk
> > where Q-day happens before the technology we need to completely ready.
>
> Yep, we absolutely agree! I just don't see a reason to do P2MR over just
> utilizing P2TR (or maybe
> P2TRv2).
>
> > > No it doesn't - it requires a soft fork when the risk is imminent, but
> it happening somewhat
> > before that time is okay too.
> >
> > We might wait too long and misjudge the risk and Q-day happens before
> the soft fork activates? What
> > happens if freeze fork is activated but then 3 years pass and it looks
> like a CRQC isn't going to
> > happen after all? Now people who had their coins frozen are pushing to
> undo the soft fork.
>
> > This approach carries too much risk from uncertainty and it was "the
> plan" it signles that Bitcoin
> > leaving things up to chance that don't have to be left to chance.
> >
> > Enabling people to opt in as early as possible enables the prudent to
> protect themselves for very
> > little effort and cost. Those people know their coins are safe and can
> still use their coin as they
> > did before.
>
> We agree. I believe your response is based on a misunderstanding of my
> argument, hopefully clarified
> above.
>
> > > I mean people can create invalid addresses today in plenty of ways.
> How is this unique?
> >
> > P2TRD would be an address, which looks exactly like a 100% valid address
> and which can be spend from
> > like a valid address and hwoever at some future time, it may or may not,
> become frozen.
>
> Sure, but this is still no different than any other P2TR script-path
> structure - you have to test
> things you use, even if you use them rarely, which is the entire point of
> the P2TR design :).
>
> Matt
>
--
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/dd2fcc40-cedc-48ae-b23d-6029f678c184n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 9707 bytes --]
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms
2026-02-11 18:53 ` Matt Corallo
2026-02-11 22:57 ` Ethan Heilman
@ 2026-02-12 15:36 ` waxwing/ AdamISZ
2026-02-12 19:35 ` Matt Corallo
1 sibling, 1 reply; 42+ messages in thread
From: waxwing/ AdamISZ @ 2026-02-12 15:36 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 8067 bytes --]
> For what its worth I do not see a scenario where a decision ultimately
made by the market will pick
the fork side with materially, say 5-10x higher, supply, over the side with
lower supply...supply
and demand is king, especially with the "confiscatory" nature is basically
nil as ~all wallets today
use seedphrases, which could still be spent with a ZK proof-of-seedphrase
:).
This line of reasoning is wrong imo.
If supply and demand is king, why not just delete supply as much as
possible? No more mining? Arbitrary freezing of various actors' coins (but
with warning! so it's only confiscation in quotes, right?).
Hypothetical: someone proposes a fork which freezes all coins residing at
utxos with addresses containing "234" (insert technical description as
appropriate - you get the idea). It'll be a bit like the rules about
driving into town with various letters in your license plate, though, a bit
more permanent :) The vast majority will benefit economically from the lazy
few who don't notice, since if they pay attention, they can hop out of the
frozen addresses with time to spare, so why doesn't it happen?
Obviously, ridiculous examples, but .. point stands in general:
It's a curious kind of self-referential. The "market" here is really the
set of holders, their *short term* interest is to grab any they can, but
their long term interest is to have their stash keep its value. There is
*nothing* that will destroy bitcoin's value more effectively (certainly not
technical issues like bugs, certainly not an unexpected unlock of a big
amount of coins to be moved in the market) than an event that questions the
"private property promise":
1/ coin inflation schedule is set in stone;
2/ if you can cryptographically validate a transfer, bitcoin will let you
do it, i.e. you can always spend your own money;
3/ if you "locked" a utxo with a certain ruleset in the past, that ruleset
will still be active and let you spend in future, i.e. you can't be locked
out of your own money.
Bitcoin is the only digital asset in the world for which those assertions
are credible; it has never yet violated them, and imo it's the thing that
keeps it unique and important (PoW ties in; it's another aspect of the same
rigid adherence to no controlling entities).
That's why both this idea and Peter Todd's tail emission idea, both high
quality engineering-safety thinking, will not happen, in my opinion.
> ZK proof-of-seedphrase :).
Oh cool, that's a good point. Ethan's counterpoint is good too, that we
would need a consensus rule and that's v. hard, but: my spidey sense is
tingling a bit about whether people might find tricks to avoid it: if you
consider the very clever tricks recently discovered around Glock, ArgoMAC
and so on, they enable gating txs behind ZKP schemes w/o new consensus but
what we're talking about here is way more narrowly defined than the larger
problem they're trying to solve, which might support being optimistic ...).
Cheers,
AdamISZ/waxwing
On Wednesday, February 11, 2026 at 12:55:19 PM UTC-6 Matt Corallo wrote:
>
>
> On 2/10/26 11:44 AM, Ethan Heilman wrote:
> > > 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.
>
> For what its worth I do not see a scenario where a decision ultimately
> made by the market will pick
> the fork side with materially, say 5-10x higher, supply, over the side
> with lower supply...supply
> and demand is king, especially with the "confiscatory" nature is basically
> nil as ~all wallets today
> use seedphrases, which could still be spent with a ZK proof-of-seedphrase
> :).
>
> > 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.
>
> The drawback being that it will see zero relevant adoption until its way
> too late.
>
> The only entities that would reasonably adopt something like this are
> large custodians, who aren't
> worth worrying about as they'll easily migrate all their coins over the
> course of a few days or
> weeks in an emergency scenario, and highly specialty wallets. The point of
> any PQ soft fork today is
> if it can actually drive wallets to start making progress on PQ
> deployment. A new address type that
> is 10x more expensive to transact with is going to see ~zero adoption in
> "consumer wallets" until
> its urgent, at which point its obviously way, way too late.
>
> Hell, *any* PQ soft fork is going to see limited adoption in "consumer
> wallets" until its urgent,
> hence why I think the community will be basically forced to disable
> insecure spend paths and only
> allow spends via ZK proof-of-seedphrase. But at least something that
> doesn't also 10x transaction
> costs might reasonably be adopted by default by wallets that don't use
> seedphrases like Bitcoin Core.
>
> > > 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.
>
> No it doesn't - it requires a soft fork when the risk is imminent, but it
> happening somewhat before
> that time is okay too.
>
> > 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.
>
> I mean people can create invalid addresses today in plenty of ways. How is
> this unique?
>
> > 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.
>
> It would almost certainly just be a key derived from the seedphrase via
> another hash function, so
> there's no real risk of this.
>
> Matt
>
--
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/efa3dd60-84c2-48ea-9fc7-ae5057590cb9n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 8966 bytes --]
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms
2026-02-12 14:55 ` Matt Corallo
2026-02-12 15:35 ` Alex
@ 2026-02-12 18:08 ` Ethan Heilman
2026-02-12 19:13 ` Matt Corallo
1 sibling, 1 reply; 42+ messages in thread
From: Ethan Heilman @ 2026-02-12 18:08 UTC (permalink / raw)
To: Matt Corallo; +Cc: Jonas Nick, bitcoindev
[-- Attachment #1: Type: text/plain, Size: 10605 bytes --]
> Yep, we absolutely agree! I just don't see a reason to do P2MR over just
utilizing P2TR (or maybe P2TRv2).
Here is my P2TRv2/ P2TRD vs P2MR analysis.
Terms:
- P2TRv2-disable-soft-fork - refers to the soft-fork that disables key
spend paths for P2TRv2 outputs, but does not disable key spend paths for
other P2TR outputs.
- Q-day-long - The day at which long exposure attacks start happening.
Set of outcomes for P2TRv2:
Future-A: Q-day-long happens and P2TRv2-disable-soft-fork is NOT
activated. Funds are stolen from P2TRv2 outputs, trust in Bitcoin declines.
Future-B: Q-day-long happens and P2TRv2-disable-soft-fork is activated.
P2TRv2 outputs are protected from quantum attacks.
Set of outcomes for P2MR:
Future-C: Funds in P2MR are safe even if Q-day-long happens unexpectedly.
The risk of Future-A will be priced into the value of Bitcoin. We can
reduce Future-A risk by activating P2TRv2-disable-soft-fork as early as
possible. Activating P2TRv2-disable-soft-fork as early as possible is
equivalent to activating P2MR. Thus, might as well activate P2MR instead.
Do we want to tell holders:
- Move to P2TRv2 and then trust us to activate the P2TRv2-disable-soft-fork
in time
- Or move to P2MR, you'll be safe.
> Still, I think my point stands - in the face of many bitcoiners writing
off the quantum threat, wallets aren't going to have a lot of incentive to
adopt technologies that make things marginally more expensive.
Maybe in 2027, but what about 2028, 2029? If we see steady progress toward
a CRQC the drumbeat will become louder and louder and wallets will want to
tell their users they are quantum-safe and secure against classical attacks
on ECC.
The first parties to move over will likely be big holders willing to pay a
trivial increase in fees for security against existential tail risks.
> I'm confused by this comment - a soft fork that disables insecure spend
paths to avoid them being stolen is likely going to have a very easy time,
not "fight an uphill battle"?
soft-fork-1: Disables insecure key spend paths in P2TR. I don't have an
opinion on the ethics of this, but the incentives are aligned to make this
happen (reduces supply).
soft-fork-2: ZKP proof of seed phase to allow people to safely spend from a
disabled key spend path. The incentives are aligned to oppose this
soft-fork (increases supply).
The incentives support soft-fork-1 happening, but soft-fork-2 not
happening. I don't claim to predict a future here, but the incentive issue
here worries me.
Other questions:
Soft-fork-1 must be designed so that soft-fork-2 is not a hard fork, that
seems doable, has anyone written up a plan for it?
How big is this proposed PQ ZKP proof of seed phase? I've been assuming
~100kb per spend since we have to use PQ ZKPs.
On Thu, Feb 12, 2026 at 9:56 AM Matt Corallo <lf-lists@mattcorallo.com>
wrote:
>
>
> On 2/11/26 5:57 PM, Ethan Heilman wrote:
> > > For what its worth I do not see a scenario where a decision
> ultimately made by the market will
> > pick the fork side with materially, say 5-10x higher, supply, over the
> side with lower supply...
> >
> > Completely agree, the incentives favor lower supply. I wouldn't want to
> count on it happening and
> > even if it does happen the freeze fork might not freeze P2TR. According
> to the 2025 chaincode report
> > [0] P2TR represents only 0.75% of total supply.
>
> I believe we're talking past each other, then. This was a side note - as
> Jonas mentioned it seems
> reasonable that a P2TR-based QC signature validation opcode could come
> with an on-chain signaling
> bit (i.e. a "Taproot V2" that is functionally identical but indicates the
> presence of a QC signature
> script path available).
>
> > > ~all wallets today use seedphrases, which could still be spent with a
> ZK proof-of-seedphrase :).
> >
> > I'm all for putting ZKPs in consensus, but it seems unlikely to me that
> it will happen.
>
> We just agreed that its highly likely that insecure spend paths are
> disabled. I do not remotely see
> how such an action could occur if the result is that a large number of
> coins are seized. The only
> viable approach way for that is to allow seedphrase-based wallets to
> retain access.
>
> > It is better
> > to make Bitcoin safe than promise safety that requires a future hardfork.
>
> There is no hardfork required here.
>
> > This is especially true
> > since as you point out lower supply is incentivized, so a soft fork that
> freezes coins would be
> > fighting an uphill battle.
>
> I'm confused by this comment - a soft fork that disables insecure spend
> paths to avoid them being
> stolen is likely going to have a very easy time, not "fight an uphill
> battle"?
>
> > > Hell, *any* PQ soft fork is going to see limited adoption in
> "consumer wallets" until its
> > urgent, hence why I think the community will be basically forced to
> disable insecure spend paths and
> > only
> > allow spends via ZK proof-of-seedphrase. But at least something that
> doesn't also 10x
> > transaction costs might reasonably be adopted by default by wallets that
> don't use seedphrases like
> > Bitcoin Core.
> >
> > I disagree. If we get P2MR and SLH_DSA/SHRINCS the wallets can use
> quantum-safe outputs (Schnorr OR
> > PQ) with Schnorr as the default spend. The wallets can market themselves
> as quantum safe.
>
> This flies in the face of the last 15 years of experience with Bitcoin
> wallets. Yea, it sounds
> great, but we've got 15 years of experience showing that wallets only
> adapt when they go out of
> business/stop being maintained and get replaced with new wallets (which
> often ship with the latest
> technology). Worse, many bitcoiners (maybe rightfully, maybe not) entirely
> write off the quantum
> threat - all the more reason they will simply not adopt any changes.
>
> > The cost
> > in transaction fees to a user is small, a 1 input P2MR transaction would
> only be 37 bytes larger
> > when compared with a 1 input P2TR transaction. Those 37 bytes are in the
> witness, so the real cost
> > is ~10 vbytes.
>
> Apologies, I had understood the P2MR proposal to only feature PQC-based
> schemes, rather than also
> offering schnorr as an option, leading me to incorrectly conclude it would
> be drastically more
> expensive, rather than marginally so.
>
> Still, I think my point stands - in the face of many bitcoiners writing
> off the quantum threat,
> wallets aren't going to have a lot of incentive to adopt technologies that
> make things marginally
> more expensive.
>
> Worse, there's no real advantage here over just doing in the taproot key
> path - because of address
> reuse a wallet relying on P2MR + schnorr anyway will ~always have its
> public key revealed so we
> might as well continue relying on P2TR to save the 37 witness bytes and
> get the same result (that
> wallets can do something cheap with "just" a key derivation change and
> explicitly opt in to a future
> soft fork which disables the then-insecure spend paths).
>
> > Yes, if Q-day happens, time passes and then quantum computers become
> powerful enough to perform
> > short-exposure attacks, anyone needing to move their coins to an output
> have to pay fees for an
> > additional 8,000 bytes (SLH_DSA) or 324 bytes (SHRINCs). This is still
> better than a PQ ZKP proof of
> > the seed which would be between 20,000 to 120,000 bytes and more likely
> to have a security flaw than
> > SLH_DSA.
>
> Yep, I'm not proposing at all that we do nothing because a ZKP of
> seedphrase is an option, rather we
> should add support for SHRINCS and encourage wallet adoption. But at the
> same time we should
> understand that we're incredibly unlikely to see the kind of adoption in
> time to avoid the need to
> do something like a ZKP of seedphrase when the time comes.
>
> This is also probably the least interesting point of contention, FWIW -
> this is a decision for a
> future bitcoin community, not a decision for us to make today.
>
> > If efficient quantum signatures or compression techniques are developed,
> we can and should adopt
> > them. If they are efficient enough, they can become the default. This
> proposal is designed to keep
> > funds safe in the intermediate period while better techniques are
> developed to cover the tail risk
> > where Q-day happens before the technology we need to completely ready.
>
> Yep, we absolutely agree! I just don't see a reason to do P2MR over just
> utilizing P2TR (or maybe
> P2TRv2).
>
> > > No it doesn't - it requires a soft fork when the risk is imminent,
> but it happening somewhat
> > before that time is okay too.
> >
> > We might wait too long and misjudge the risk and Q-day happens before
> the soft fork activates? What
> > happens if freeze fork is activated but then 3 years pass and it looks
> like a CRQC isn't going to
> > happen after all? Now people who had their coins frozen are pushing to
> undo the soft fork.
>
> > This approach carries too much risk from uncertainty and it was "the
> plan" it signles that Bitcoin
> > leaving things up to chance that don't have to be left to chance.
> >
> > Enabling people to opt in as early as possible enables the prudent to
> protect themselves for very
> > little effort and cost. Those people know their coins are safe and can
> still use their coin as they
> > did before.
>
> We agree. I believe your response is based on a misunderstanding of my
> argument, hopefully clarified
> above.
>
> > > I mean people can create invalid addresses today in plenty of ways.
> How is this unique?
> >
> > P2TRD would be an address, which looks exactly like a 100% valid address
> and which can be spend from
> > like a valid address and hwoever at some future time, it may or may not,
> become frozen.
>
> Sure, but this is still no different than any other P2TR script-path
> structure - you have to test
> things you use, even if you use them rarely, which is the entire point of
> the P2TR design :).
>
> Matt
>
--
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%2BU673Q1U09Z_xrumiBjU9q9xKGnMOE3OC41Qt651g2ROw%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 11761 bytes --]
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms
2026-02-12 18:08 ` Ethan Heilman
@ 2026-02-12 19:13 ` Matt Corallo
2026-02-12 20:35 ` Ethan Heilman
0 siblings, 1 reply; 42+ messages in thread
From: Matt Corallo @ 2026-02-12 19:13 UTC (permalink / raw)
To: Ethan Heilman; +Cc: Jonas Nick, bitcoindev
On 2/12/26 1:08 PM, Ethan Heilman wrote:
> > Yep, we absolutely agree! I just don't see a reason to do P2MR over just utilizing P2TR (or
> maybe P2TRv2).
>
> Here is my P2TRv2/ P2TRD vs P2MR analysis.
>
> Terms:
> - P2TRv2-disable-soft-fork - refers to the soft-fork that disables key spend paths for P2TRv2
> outputs, but does not disable key spend paths for other P2TR outputs.
> - Q-day-long - The day at which long exposure attacks start happening.
>
> Set of outcomes for P2TRv2:
> Future-A: Q-day-long happens and P2TRv2-disable-soft-fork is NOT activated. Funds are stolen from
> P2TRv2 outputs, trust in Bitcoin declines.
> Future-B: Q-day-long happens and P2TRv2-disable-soft-fork is activated. P2TRv2 outputs are protected
> from quantum attacks.
>
> Set of outcomes for P2MR:
> Future-C: Funds in P2MR are safe even if Q-day-long happens unexpectedly.
>
> The risk of Future-A will be priced into the value of Bitcoin. We can reduce Future-A risk by
> activating P2TRv2-disable-soft-fork as early as possible. Activating P2TRv2-disable-soft-fork as
> early as possible is equivalent to activating P2MR. Thus, might as well activate P2MR instead.
>
> Do we want to tell holders:
> - Move to P2TRv2 and then trust us to activate the P2TRv2-disable-soft-fork in time
> - Or move to P2MR, you'll be safe.
No, P2TRv2 and P2MR are totally equivalent here. Because address reuse is rampant, P2MR will *also*
require an equivalent P2MR-disable-soft-fork. The only material difference is the cost, and some
small minority that doesn't do heavy address reuse.
> > Still, I think my point stands - in the face of many bitcoiners writing off the quantum
> threat, wallets aren't going to have a lot of incentive to adopt technologies that make things
> marginally more expensive.
>
> Maybe in 2027, but what about 2028, 2029? If we see steady progress toward a CRQC the drumbeat will
> become louder and louder and wallets will want to tell their users they are quantum-safe and secure
> against classical attacks on ECC.
>
> The first parties to move over will likely be big holders willing to pay a trivial increase in fees
> for security against existential tail risks.
Right, so the first parties to move will be the ones we don't really care about (because they can
just move quickly later anyway) :).
> > I'm confused by this comment - a soft fork that disables insecure spend paths to avoid them
> being stolen is likely going to have a very easy time, not "fight an uphill battle"?
>
> soft-fork-1: Disables insecure key spend paths in P2TR. I don't have an opinion on the ethics of
> this, but the incentives are aligned to make this happen (reduces supply).
> soft-fork-2: ZKP proof of seed phase to allow people to safely spend from a disabled key spend path.
> The incentives are aligned to oppose this soft-fork (increases supply).
>
> The incentives support soft-fork-1 happening, but soft-fork-2 not happening. I don't claim to
> predict a future here, but the incentive issue here worries me.
Fair. Given the ethics questions and the amount of pushback I have to imagine every effort *has* to
be made to allow maximum wallets to retain coin ownership as otherwise the resulting Bitcoin has
less value just because of seizure concerns. This all depends a ton on specifics, though - has it
been 5 years since P2TRv2 was added? 10? 25? When did wallets start migrating in earnest? Did they
even until it was too late?
> Other questions:
>
> Soft-fork-1 must be designed so that soft-fork-2 is not a hard fork, that seems doable, has anyone
> written up a plan for it?
I believe this is largely only possible either with an ethereum-style "difficulty bomb" or simply
doint it all in one go.
> How big is this proposed PQ ZKP proof of seed phase? I've been assuming ~100kb per spend since we
> have to use PQ ZKPs.
Yes, I imagine quite large. Hence good to push migration along first. If migration is limited, I
imagine there will be some desire to provide strong fee-discounts for these ZKPs, maybe also
aggregating them in blocks.
Matt
--
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/ade8d7f0-8793-4971-a5bd-fc60e76f513a%40mattcorallo.com.
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms
2026-02-12 15:13 ` Alex
@ 2026-02-12 19:16 ` Matt Corallo
0 siblings, 0 replies; 42+ messages in thread
From: Matt Corallo @ 2026-02-12 19:16 UTC (permalink / raw)
To: Alex, Bitcoin Development Mailing List
On 2/12/26 10:13 AM, Alex wrote:
> > A new address type that
> is 10x more expensive to transact with is going to see ~zero adoption in "consumer wallets" until
> its urgent, at which point its obviously way, way too late.
>
> This is dishonest strawman argumentation that only misrepresents the proposal incorrectly.
As I mentioned in my email sent at some time prior to your mail (though it may not have hit your
inbox in time, I'm not sure), yes, I had misunderstood the specifics of the P2MR proposal. I
apologize and there was no intent to straw-man here.
As I mention in that email, as well as the one I just sent to ethan, however, I still see zero
reason to prefer it over a P2TR(v2) approach. It seems strictly inferior.
Matt
--
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/ba0502e6-0d9a-480e-95fd-82ce4d424162%40mattcorallo.com.
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms
2026-02-12 15:35 ` Alex
@ 2026-02-12 19:20 ` Matt Corallo
0 siblings, 0 replies; 42+ messages in thread
From: Matt Corallo @ 2026-02-12 19:20 UTC (permalink / raw)
To: Alex, Bitcoin Development Mailing List
On 2/12/26 10:35 AM, Alex wrote:
> > wallets aren't going to have a lot of incentive to adopt technologies that make things marginally
> more expensive.
>
> This claim is not rooted in reality. We literally just now saw Trezor market their Safe 7 as Quantum
> Ready and they had a major ad campaign specifically for this. There is major incentive for wallets
> to "sell" the quantum threat as a problem to fix, and therefore sell more wallets or claim
> compliance to gain market share. The quantum threat is mainstream. Retail knows about it, talks
> about it all the time.
>
> > many bitcoiners writing off the quantum threat
>
> Yes because psychologically, the most successful Bitcoiners are those who never reacted to any FUD
> and therefore never sold. And so they are essentially naturally selected by their history of never
> reacting to FUD. We've basically evolved the most non-reactant people and so obviously they are not
> going to react to the quantum threat because why would they change their strategy of never reacting
> if it worked so well so far?
Well you contradict yourself here :).
Yes, I fully anticipate wallets attempting to market themselves as "quantum secure". I do not
anticipate most "mainstream wallets" will care at all - if I search the app store right now for
"bitcoin wallet" I get bitcoin.com, coinbase, and trust wallet as the top three - all of which have
objective histories of taking 5-10 years to adopt incredibly basic bitcoin technologies and never
adopting best practices or marginally more complicated technologies.
And, indeed, as you point out, a large subset of the bitcoin community is unlikely to care until the
threat is imminent, at which point migration is much too late. It doesn't matter if some set of
people migrate, if a large number haven't its the same net impact.
Matt
--
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/6485599c-e452-4efd-8375-d3b7dba36eee%40mattcorallo.com.
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms
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
0 siblings, 2 replies; 42+ messages in thread
From: Matt Corallo @ 2026-02-12 19:35 UTC (permalink / raw)
To: waxwing/ AdamISZ, Bitcoin Development Mailing List
On 2/12/26 10:36 AM, waxwing/ AdamISZ wrote:
> > For what its worth I do not see a scenario where a decision ultimately made by the market will
pick
> the fork side with materially, say 5-10x higher, supply, over the side with lower supply...supply
> and demand is king, especially with the "confiscatory" nature is basically nil as ~all wallets today
> use seedphrases, which could still be spent with a ZK proof-of-seedphrase :).
>
> This line of reasoning is wrong imo.
>
> If supply and demand is king, why not just delete supply as much as possible? No more mining?
> Arbitrary freezing of various actors' coins (but with warning! so it's only confiscation in quotes,
> right?).
>
> Hypothetical: someone proposes a fork which freezes all coins residing at utxos with addresses
> containing "234" (insert technical description as appropriate - you get the idea). It'll be a bit
> like the rules about driving into town with various letters in your license plate, though, a bit
> more permanent :) The vast majority will benefit economically from the lazy few who don't notice,
> since if they pay attention, they can hop out of the frozen addresses with time to spare, so why
> doesn't it happen?
>
> Obviously, ridiculous examples, but .. point stands in general:
>
> It's a curious kind of self-referential. The "market" here is really the set of holders, their
> *short term* interest is to grab any they can, but their long term interest is to have their stash
> keep its value. There is *nothing* that will destroy bitcoin's value more effectively (certainly not
> technical issues like bugs, certainly not an unexpected unlock of a big amount of coins to be moved
> in the market) than an event that questions the "private property promise":
>
> 1/ coin inflation schedule is set in stone;
> 2/ if you can cryptographically validate a transfer, bitcoin will let you do it, i.e. you can always
> spend your own money;
> 3/ if you "locked" a utxo with a certain ruleset in the past, that ruleset will still be active and
> let you spend in future, i.e. you can't be locked out of your own money.
>
> Bitcoin is the only digital asset in the world for which those assertions are credible; it has never
> yet violated them, and imo it's the thing that keeps it unique and important (PoW ties in; it's
> another aspect of the same rigid adherence to no controlling entities).
>
> That's why both this idea and Peter Todd's tail emission idea, both high quality engineering-safety
> thinking, will not happen, in my opinion.
I obviously agree with you at a high level - the value of Bitcoin derives from its (attempt at)
trustlessness and any attempts to break that will necessarily result in the market rejecting them
precisely because they break the exact thing that gives Bitcoin value.
Its also hard to analyze this because it depends so much on the very exact scenario we're talking
about. There are indeed certainly scenarios I can imagine where I think the market would prefer to
not disable insecure spend paths. But at the risk of using an equally absurd example as yours,
Imagine we discover a breakthrough in refrigeration technology that we've missed for 200 years
tomorrow (or a room temperature superconductor, or...) plus a few other major engineering
breakthroughs and we're now on track to have a CRQC in 2-3 years instead of 15-20, and oh in 6
months we discover that they're not just gonna be buildable soon but pretty easy to build farms and
they'll be able to calculate a private key in seconds. Yes, we can stand on principle and watch as
the CRQCs steal all the bitcoin and sell them to recoup their investment, but the market is
obviously not going to value that because the thing that's left isn't recognizable as Bitcoin - its
just some weird cryptographic scheme where tokens are shifting around all the time and everyone is
stealing from everyone else.
There would certainly be market participants (like you, I guess :p) that try to hold on to the
original Bitcoin and might even invest some money in buying more (from the CRQC-operators). And the
insecure-spend-paths-disabled fork would probably have somewhat less value than the original as a
result. But the original chain would without question have nearly zero value, and the fork might
have some.
Now, this scenario maybe seems exaggerated, but actually I think its equivalent to the most likely
outcome. Not that I think we'll see multiple major 100-year physics breakthroughs soon, but rather
if we see a CRQC in the next 10-20 years, that the state of Bitcoin wallet adoption of PQ spend
paths will be only marginally better than it is today. Sure, maybe 50% of wallets have upgraded, but
that's not enough to have any outcome materially different from the above.
Finally, more philosophically, I disagree that these are somehow equivalent. Yes, in stated
black-and-white principles it violates the "ethics of Bitcoin", but that the *alternative does too*.
Leaving the coins to be stolen by a CRQC almost equally violates the "ethics of Bitcoin" - the
rightful owner of the coins, the one that created the private key and did not leak that private key
to anyone else no longer has the coins! but...
> > ZK proof-of-seedphrase :).
>
> Oh cool, that's a good point. Ethan's counterpoint is good too, that we would need a consensus rule
> and that's v. hard, but: my spidey sense is tingling a bit about whether people might find tricks to
> avoid it: if you consider the very clever tricks recently discovered around Glock, ArgoMAC and so
> on, they enable gating txs behind ZKP schemes w/o new consensus but what we're talking about here is
> way more narrowly defined than the larger problem they're trying to solve, which might support being
> optimistic ...).
I think this makes the philosophical point more stark! Now the options in front of the future
Bitcoin community aren't "burn the coins or let the CRQC-operator steal them" then options in front
of the future Bitcoin community are "burn some of the coins and let a probably-majority of the
rightful owners claim them, or let the CRQC-operator steal all of them". I cannot justify why the
second option is somehow more ethical or more in line with building the best, most trustless money
on the planet.
Matt
--
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/f0a2f902-2813-40f3-91ca-597ddcce1ed0%40mattcorallo.com.
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms
2026-02-12 19:35 ` Matt Corallo
@ 2026-02-12 19:43 ` Matt Corallo
2026-02-14 12:39 ` waxwing/ AdamISZ
1 sibling, 0 replies; 42+ messages in thread
From: Matt Corallo @ 2026-02-12 19:43 UTC (permalink / raw)
To: waxwing/ AdamISZ, Bitcoin Development Mailing List
On 2/12/26 2:35 PM, Matt Corallo wrote:
>
>
> On 2/12/26 10:36 AM, waxwing/ AdamISZ wrote:
> > > For what its worth I do not see a scenario where a decision ultimately made by the market will
> pick
> > the fork side with materially, say 5-10x higher, supply, over the side with lower supply...supply
> > and demand is king, especially with the "confiscatory" nature is basically nil as ~all wallets today
> > use seedphrases, which could still be spent with a ZK proof-of-seedphrase :).
> >
> > This line of reasoning is wrong imo.
> >
> > If supply and demand is king, why not just delete supply as much as possible? No more mining?
> > Arbitrary freezing of various actors' coins (but with warning! so it's only confiscation in quotes,
> > right?).
> >
> > Hypothetical: someone proposes a fork which freezes all coins residing at utxos with addresses
> > containing "234" (insert technical description as appropriate - you get the idea). It'll be a bit
> > like the rules about driving into town with various letters in your license plate, though, a bit
> > more permanent :) The vast majority will benefit economically from the lazy few who don't notice,
> > since if they pay attention, they can hop out of the frozen addresses with time to spare, so why
> > doesn't it happen?
> >
> > Obviously, ridiculous examples, but .. point stands in general:
> >
> > It's a curious kind of self-referential. The "market" here is really the set of holders, their
> > *short term* interest is to grab any they can, but their long term interest is to have their stash
> > keep its value. There is *nothing* that will destroy bitcoin's value more effectively (certainly not
> > technical issues like bugs, certainly not an unexpected unlock of a big amount of coins to be moved
> > in the market) than an event that questions the "private property promise":
> >
> > 1/ coin inflation schedule is set in stone;
> > 2/ if you can cryptographically validate a transfer, bitcoin will let you do it, i.e. you can always
> > spend your own money;
> > 3/ if you "locked" a utxo with a certain ruleset in the past, that ruleset will still be active and
> > let you spend in future, i.e. you can't be locked out of your own money.
> >
> > Bitcoin is the only digital asset in the world for which those assertions are credible; it has never
> > yet violated them, and imo it's the thing that keeps it unique and important (PoW ties in; it's
> > another aspect of the same rigid adherence to no controlling entities).
> >
> > That's why both this idea and Peter Todd's tail emission idea, both high quality engineering-safety
> > thinking, will not happen, in my opinion.
>
> I obviously agree with you at a high level - the value of Bitcoin derives from its (attempt at)
> trustlessness and any attempts to break that will necessarily result in the market rejecting them
> precisely because they break the exact thing that gives Bitcoin value.
>
> Its also hard to analyze this because it depends so much on the very exact scenario we're talking
> about. There are indeed certainly scenarios I can imagine where I think the market would prefer to
> not disable insecure spend paths. But at the risk of using an equally absurd example as yours,
>
> Imagine we discover a breakthrough in refrigeration technology that we've missed for 200 years
> tomorrow (or a room temperature superconductor, or...) plus a few other major engineering
> breakthroughs and we're now on track to have a CRQC in 2-3 years instead of 15-20, and oh in 6
> months we discover that they're not just gonna be buildable soon but pretty easy to build farms and
> they'll be able to calculate a private key in seconds. Yes, we can stand on principle and watch as
> the CRQCs steal all the bitcoin and sell them to recoup their investment, but the market is
> obviously not going to value that because the thing that's left isn't recognizable as Bitcoin - its
> just some weird cryptographic scheme where tokens are shifting around all the time and everyone is
> stealing from everyone else.
>
> There would certainly be market participants (like you, I guess :p) that try to hold on to the
> original Bitcoin and might even invest some money in buying more (from the CRQC-operators). And the
> insecure-spend-paths-disabled fork would probably have somewhat less value than the original as a
> result. But the original chain would without question have nearly zero value, and the fork might
> have some.
>
> Now, this scenario maybe seems exaggerated, but actually I think its equivalent to the most likely
> outcome. Not that I think we'll see multiple major 100-year physics breakthroughs soon, but rather
> if we see a CRQC in the next 10-20 years, that the state of Bitcoin wallet adoption of PQ spend
> paths will be only marginally better than it is today. Sure, maybe 50% of wallets have upgraded, but
> that's not enough to have any outcome materially different from the above.
>
> Finally, more philosophically, I disagree that these are somehow equivalent. Yes, in stated black-
> and-white principles it violates the "ethics of Bitcoin", but that the *alternative does too*.
> Leaving the coins to be stolen by a CRQC almost equally violates the "ethics of Bitcoin" - the
> rightful owner of the coins, the one that created the private key and did not leak that private key
> to anyone else no longer has the coins! but...
>
> > > ZK proof-of-seedphrase :).
> >
> > Oh cool, that's a good point. Ethan's counterpoint is good too, that we would need a consensus rule
> > and that's v. hard, but: my spidey sense is tingling a bit about whether people might find tricks to
> > avoid it: if you consider the very clever tricks recently discovered around Glock, ArgoMAC and so
> > on, they enable gating txs behind ZKP schemes w/o new consensus but what we're talking about here is
> > way more narrowly defined than the larger problem they're trying to solve, which might support being
> > optimistic ...).
>
> I think this makes the philosophical point more stark! Now the options in front of the future
> Bitcoin community aren't "burn the coins or let the CRQC-operator steal them" then options in front
> of the future Bitcoin community are "burn some of the coins and let a probably-majority of the
> rightful owners claim them, or let the CRQC-operator steal all of them". I cannot justify why the
> second option is somehow more ethical or more in line with building the best, most trustless money
> on the planet.
And maybe to clarify this somewhat further, my thinking is the value of bitcoin derives entirely
from this concept of "trustlessness". "property rights" is a somewhat similar concept here, but the
point is that you can own this thing without having to trust someone else to enforce that ownership.
If a CRQC steals that thing that you supposedly own, you didn't own it, and it sure as hell wasn't
trustless! If, on the other hand, at least *some* coin owners get to keep their coins, that's at
least somewhat further up the "trustlessnes" curve than before.
This goes double for the, IMO likely, scenario that the long-tail of non-seedphrase wallets is able
to adopt a P2MR or P2TRv2 PQC design years/decades before a CRQC, but there's quite some straggler
seedphrase-based wallets near that point. This means that ~only coins that haven't been touched in a
decade and didn't take action, are burned, but in exchange a lot of coins from straggler wallets are
saved.
Matt
--
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/8b4e4438-329b-47a7-b31b-e410ab60d024%40mattcorallo.com.
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms
2026-02-12 19:13 ` Matt Corallo
@ 2026-02-12 20:35 ` Ethan Heilman
2026-02-12 20:43 ` Matt Corallo
0 siblings, 1 reply; 42+ messages in thread
From: Ethan Heilman @ 2026-02-12 20:35 UTC (permalink / raw)
To: Matt Corallo; +Cc: Jonas Nick, bitcoindev
[-- Attachment #1: Type: text/plain, Size: 8522 bytes --]
Replying to Waxwing, and Matt in this email
Waxwing:
> If supply and demand is king, why not just delete supply as much as
possible? No more mining?
I agree with you that a soft-fork that simply burns outputs to reduce
supply is unlikely to activate. I do agree with Matt's point given the
specific circumstances here.
Everyone would want soft-fork1. It freezes coins that would otherwise be
stolen with the promise to unfreeze them with a planned PQ ZKP proof of
seed phrase. Even the people whose coins would be frozen would want
soft-fork1 since it protects them. This makes it very likely that if the
threat of quantum theft is credible, soft-fork1 would activate and everyone
would be happy with this result (assuming it activates in time).
Now time passes, and the people whose coins are frozen want soft-fork2.
They feel they have waited long enough, but there is a problem. While
soft-fork1 was trivial to write, soft-fork2 requires a complex PQ ZKP that
will become consensus critical to Bitcoin. This is a complex task requiring
expertise. Will it actually get done? By whom?
Assume soft-fork2 actually gets built. Now it has to get activated.
Blocking a soft-fork is much easier than activating a soft-fork and this
will be a particularly contentious soft-fork.
Some will argue it is unfair that holders who did the right thing and
upgraded to secure outputs will be forced to on the consensus risks of a
dangerous soft-fork simply to unfreeze coins that the original owners
didn't even bother to secure. Others will just stall soft-fork2 by saying
it hasn't been tested enough or there isn't consensus. Making this worse,
miners are unlikely to want to increase supply. Getting miners to activate
soft-fork2 is much harder than soft-fork1.
Soft-fork1 activated because everyone was aligned. Soft-fork2 no longer has
that alignment and is much riskier.
"Aww shucks, we really support unfreezing these coins, but we the miners
just don't think the current iteration is ready for prime time, why don't
you put more work into it and try again in five years." - every five years
until the heat death of the universe.
Matt:
> I believe this is largely only possible either with an ethereum-style
"difficulty bomb" or simply doint it all in one go.
The do it all in one go approach avoids the incentive problem, but how will
this be built? How many cryptographers are willing to invest the years of
effort to create a soft fork that is unlikely to activate, all to protect
holders who can't be bothered to move to a safer output?
The most likely outcome is some kid just writes a simple soft-fork that
freezes all the insecure outputs, and miners activate it because they have
cover to reduce supply/pump the price. I'm not endorsing this course of
action, but it impacts my thinking on building PQ ZKP proof of seed phrase.
I ask myself why spend 5+ years on a PQ ZKP proof of seed phrase soft-fork
just to watch a low effort soft-fork annihilate all that work?
> No, P2TRv2 and P2MR are totally equivalent here. Because address reuse is
rampant, P2MR will *also* require an equivalent P2MR-disable-soft-fork. The
only material difference is the cost, and some small minority that doesn't
do heavy address reuse.
Wallets that encourage Schnorr key reuse with P2MR should be thrown out the
metaphorical airlock. Wallets claiming quantum safety must warn a user if
that user has exposed a Schnorr public key on the blockchain and make it
easy to move to a new address. There is UX work to be done on this problem,
but it is achievable and worthwhile.
On Thu, Feb 12, 2026 at 2:16 PM Matt Corallo <lf-lists@mattcorallo.com>
wrote:
>
>
> On 2/12/26 1:08 PM, Ethan Heilman wrote:
> > > Yep, we absolutely agree! I just don't see a reason to do P2MR over
> just utilizing P2TR (or
> > maybe P2TRv2).
> >
> > Here is my P2TRv2/ P2TRD vs P2MR analysis.
> >
> > Terms:
> > - P2TRv2-disable-soft-fork - refers to the soft-fork that disables key
> spend paths for P2TRv2
> > outputs, but does not disable key spend paths for other P2TR outputs.
> > - Q-day-long - The day at which long exposure attacks start happening.
> >
> > Set of outcomes for P2TRv2:
> > Future-A: Q-day-long happens and P2TRv2-disable-soft-fork is NOT
> activated. Funds are stolen from
> > P2TRv2 outputs, trust in Bitcoin declines.
> > Future-B: Q-day-long happens and P2TRv2-disable-soft-fork is activated.
> P2TRv2 outputs are protected
> > from quantum attacks.
> >
> > Set of outcomes for P2MR:
> > Future-C: Funds in P2MR are safe even if Q-day-long happens unexpectedly.
> >
> > The risk of Future-A will be priced into the value of Bitcoin. We can
> reduce Future-A risk by
> > activating P2TRv2-disable-soft-fork as early as possible. Activating
> P2TRv2-disable-soft-fork as
> > early as possible is equivalent to activating P2MR. Thus, might as well
> activate P2MR instead.
> >
> > Do we want to tell holders:
> > - Move to P2TRv2 and then trust us to activate the
> P2TRv2-disable-soft-fork in time
> > - Or move to P2MR, you'll be safe.
>
> No, P2TRv2 and P2MR are totally equivalent here. Because address reuse is
> rampant, P2MR will *also*
> require an equivalent P2MR-disable-soft-fork. The only material difference
> is the cost, and some
> small minority that doesn't do heavy address reuse.
>
> > > Still, I think my point stands - in the face of many bitcoiners
> writing off the quantum
> > threat, wallets aren't going to have a lot of incentive to adopt
> technologies that make things
> > marginally more expensive.
> >
> > Maybe in 2027, but what about 2028, 2029? If we see steady progress
> toward a CRQC the drumbeat will
> > become louder and louder and wallets will want to tell their users they
> are quantum-safe and secure
> > against classical attacks on ECC.
> >
> > The first parties to move over will likely be big holders willing to pay
> a trivial increase in fees
> > for security against existential tail risks.
>
> Right, so the first parties to move will be the ones we don't really care
> about (because they can
> just move quickly later anyway) :).
>
> > > I'm confused by this comment - a soft fork that disables insecure
> spend paths to avoid them
> > being stolen is likely going to have a very easy time, not "fight an
> uphill battle"?
> >
> > soft-fork-1: Disables insecure key spend paths in P2TR. I don't have an
> opinion on the ethics of
> > this, but the incentives are aligned to make this happen (reduces
> supply).
> > soft-fork-2: ZKP proof of seed phase to allow people to safely spend
> from a disabled key spend path.
> > The incentives are aligned to oppose this soft-fork (increases supply).
> >
> > The incentives support soft-fork-1 happening, but soft-fork-2 not
> happening. I don't claim to
> > predict a future here, but the incentive issue here worries me.
>
> Fair. Given the ethics questions and the amount of pushback I have to
> imagine every effort *has* to
> be made to allow maximum wallets to retain coin ownership as otherwise the
> resulting Bitcoin has
> less value just because of seizure concerns. This all depends a ton on
> specifics, though - has it
> been 5 years since P2TRv2 was added? 10? 25? When did wallets start
> migrating in earnest? Did they
> even until it was too late?
>
> > Other questions:
> >
> > Soft-fork-1 must be designed so that soft-fork-2 is not a hard fork,
> that seems doable, has anyone
> > written up a plan for it?
>
> I believe this is largely only possible either with an ethereum-style
> "difficulty bomb" or simply
> doint it all in one go.
>
> > How big is this proposed PQ ZKP proof of seed phase? I've been assuming
> ~100kb per spend since we
> > have to use PQ ZKPs.
>
> Yes, I imagine quite large. Hence good to push migration along first. If
> migration is limited, I
> imagine there will be some desire to provide strong fee-discounts for
> these ZKPs, maybe also
> aggregating them in blocks.
>
> Matt
>
--
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%2BUh63i0nYt4zcsPzpeNW2nwGhowCqQEHxLEE8EYMRY%3DsA%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 9585 bytes --]
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms
2026-02-12 20:35 ` Ethan Heilman
@ 2026-02-12 20:43 ` Matt Corallo
0 siblings, 0 replies; 42+ messages in thread
From: Matt Corallo @ 2026-02-12 20:43 UTC (permalink / raw)
To: Ethan Heilman; +Cc: Jonas Nick, bitcoindev
On 2/12/26 3:35 PM, Ethan Heilman wrote:
> Replying to Waxwing, and Matt in this email
>
> Waxwing:
> > If supply and demand is king, why not just delete supply as much as possible? No more mining?
>
> I agree with you that a soft-fork that simply burns outputs to reduce supply is unlikely to
> activate. I do agree with Matt's point given the specific circumstances here.
>
> Everyone would want soft-fork1. It freezes coins that would otherwise be stolen with the promise to
> unfreeze them with a planned PQ ZKP proof of seed phrase. Even the people whose coins would be
> frozen would want soft-fork1 since it protects them. This makes it very likely that if the threat of
> quantum theft is credible, soft-fork1 would activate and everyone would be happy with this result
> (assuming it activates in time).
>
> Now time passes, and the people whose coins are frozen want soft-fork2. They feel they have waited
> long enough, but there is a problem. While soft-fork1 was trivial to write, soft-fork2 requires a
> complex PQ ZKP that will become consensus critical to Bitcoin. This is a complex task requiring
> expertise. Will it actually get done? By whom?
>
> Assume soft-fork2 actually gets built. Now it has to get activated. Blocking a soft-fork is much
> easier than activating a soft-fork and this will be a particularly contentious soft-fork.
>
> Some will argue it is unfair that holders who did the right thing and upgraded to secure outputs
> will be forced to on the consensus risks of a dangerous soft-fork simply to unfreeze coins that the
> original owners didn't even bother to secure. Others will just stall soft-fork2 by saying it hasn't
> been tested enough or there isn't consensus. Making this worse, miners are unlikely to want to
> increase supply. Getting miners to activate soft-fork2 is much harder than soft-fork1.
>
> Soft-fork1 activated because everyone was aligned. Soft-fork2 no longer has that alignment and is
> much riskier.
>
> "Aww shucks, we really support unfreezing these coins, but we the miners just don't think the
> current iteration is ready for prime time, why don't you put more work into it and try again in five
> years." - every five years until the heat death of the universe.
>
> Matt:
> > I believe this is largely only possible either with an ethereum-style "difficulty bomb" or
> simply doint it all in one go.
>
> The do it all in one go approach avoids the incentive problem, but how will this be built? How many
> cryptographers are willing to invest the years of effort to create a soft fork that is unlikely to
> activate, all to protect holders who can't be bothered to move to a safer output?
>
> The most likely outcome is some kid just writes a simple soft-fork that freezes all the insecure
> outputs, and miners activate it because they have cover to reduce supply/pump the price. I'm not
> endorsing this course of action, but it impacts my thinking on building PQ ZKP proof of seed phrase.
> I ask myself why spend 5+ years on a PQ ZKP proof of seed phrase soft-fork just to watch a low
> effort soft-fork annihilate all that work?
I think this is all totally fair analysis, but I certainly hope the availability of decent PQ ZKPs
will improve over time and at least one PQ ZKP will be generally considered high quality by the time
a CRQC is on the immediate horizon. If you think that's unlikely, this is maybe something the
Bitcoin community should fund in the shorter term!
> > No, P2TRv2 and P2MR are totally equivalent here. Because address reuse is rampant, P2MR will
> *also* require an equivalent P2MR-disable-soft-fork. The only material difference is the cost, and
> some small minority that doesn't do heavy address reuse.
>
> Wallets that encourage Schnorr key reuse with P2MR should be thrown out the metaphorical airlock.
I agree! But also I try to be realistic. I mentioned in another email but a wallet reliably in the
top three app store results for "Bitcoin wallet" over the past few years (Trust wallet) started off
with fresh addresses regularly, then made it optional because it confused their users, then they
simply removed it entirely because no one ever turned it on.
> Wallets claiming quantum safety must warn a user if that user has exposed a Schnorr public key on
> the blockchain and make it easy to move to a new address. There is UX work to be done on this
> problem, but it is achievable and worthwhile.
There has been some non-zero work to improve this situation for as long as I've been in Bitcoin, and
its only gotten worse and worse over the years. I wish I shared your optimism.
Matt
--
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/1e0842c2-a89b-44b6-a9d7-bc4a43636e9e%40mattcorallo.com.
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms
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
1 sibling, 1 reply; 42+ messages in thread
From: waxwing/ AdamISZ @ 2026-02-14 12:39 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 10499 bytes --]
Hi Matt, on this point:
> Imagine we discover a breakthrough in refrigeration technology that we've
missed for 200 years
tomorrow (or a room temperature superconductor, or...) plus a few other
major engineering
breakthroughs and we're now on track to have a CRQC in 2-3 years instead of
15-20, and oh in 6
months we discover that they're not just gonna be buildable soon but pretty
easy to build farms and
they'll be able to calculate a private key in seconds. Yes, we can stand on
principle and watch as
the CRQCs steal all the bitcoin and sell them to recoup their investment,
but the market is
obviously not going to value that because the thing that's left isn't
recognizable as Bitcoin - its
just some weird cryptographic scheme where tokens are shifting around all
the time and everyone is
stealing from everyone else.
For sure. It's unlikely but it's certainly *not* out of scope. Basically
the "it happens fast" scenario.
I don't see how it changes anything about the general principles. It's just
worse. People who are active
are going to move their coins to new outputs. People who are dead or lost
the keys are not. (People who
have locked them in a way that they are 100% inaccessible for 5+ years are
of course the most unfortunate case here, perhaps worth discussing
separately.)
It's just a worse (in terms of turbulence) version of the (far, far more
likely) slow scenario.
Look, I get the "yuck" reflex and the "this is ridiculous" reflex; if
something is patently obviously "open" and previously wasn't, then
"obviously" we should just lock it up - or do something, anyway. But the
real world, whether it's a 2 year time frame or the more likely 20-50++
year timeframe, doesn't have this clean epistemology: we won't *know for
sure* when the world shifts from "outputs are safe" to "this stuff is
claimable by anyone with the machine". Even *if* it isn't all developed in
super-secret (it probably will be), we still won't know. That's why I said
"perhaps worth discussing separately" for timelocks; there you have
objective, public-verifiable "this is frozen" status. The "secure" vs
"insecure" status simply will not be knowable in advance. That makes any
engineering decisions that even *might* violate private property rights
completely unworkable.
> we can stand on principle and watch as
the CRQCs steal all the bitcoin and sell them to recoup their investment
yes, this is precisely what you would have to do (except as per previous
paragraph, it will *not* be obvious, even if large movements occur - what
if someone actually owns the coins and is trying to trick the market?).
Assuming the thesis is correct (that it's CRQCs doing it), then the coins
at that point are held in completely insecure outputs. Who has the right to
take them? Answer: anyone who's fast enough, just like a coin whose private
key is "123" or similarly insecure, gets taken all the time. Should the
network freeze insecure private keys when it sees them?
The problem is not the *reasoning* of safety. The problem is that, more
than safety, principles matter, and unlike Groucho Marx, we don't have any
others :)
On Friday, February 13, 2026 at 1:21:28 PM UTC-3 Matt Corallo wrote:
>
>
> On 2/12/26 10:36 AM, waxwing/ AdamISZ wrote:
> > > For what its worth I do not see a scenario where a decision ultimately
> made by the market will
> pick
> > the fork side with materially, say 5-10x higher, supply, over the side
> with lower supply...supply
> > and demand is king, especially with the "confiscatory" nature is
> basically nil as ~all wallets today
> > use seedphrases, which could still be spent with a ZK
> proof-of-seedphrase :).
> >
> > This line of reasoning is wrong imo.
> >
> > If supply and demand is king, why not just delete supply as much as
> possible? No more mining?
> > Arbitrary freezing of various actors' coins (but with warning! so it's
> only confiscation in quotes,
> > right?).
> >
> > Hypothetical: someone proposes a fork which freezes all coins residing
> at utxos with addresses
> > containing "234" (insert technical description as appropriate - you get
> the idea). It'll be a bit
> > like the rules about driving into town with various letters in your
> license plate, though, a bit
> > more permanent :) The vast majority will benefit economically from the
> lazy few who don't notice,
> > since if they pay attention, they can hop out of the frozen addresses
> with time to spare, so why
> > doesn't it happen?
> >
> > Obviously, ridiculous examples, but .. point stands in general:
> >
> > It's a curious kind of self-referential. The "market" here is really the
> set of holders, their
> > *short term* interest is to grab any they can, but their long term
> interest is to have their stash
> > keep its value. There is *nothing* that will destroy bitcoin's value
> more effectively (certainly not
> > technical issues like bugs, certainly not an unexpected unlock of a big
> amount of coins to be moved
> > in the market) than an event that questions the "private property
> promise":
> >
> > 1/ coin inflation schedule is set in stone;
> > 2/ if you can cryptographically validate a transfer, bitcoin will let
> you do it, i.e. you can always
> > spend your own money;
> > 3/ if you "locked" a utxo with a certain ruleset in the past, that
> ruleset will still be active and
> > let you spend in future, i.e. you can't be locked out of your own money.
> >
> > Bitcoin is the only digital asset in the world for which those
> assertions are credible; it has never
> > yet violated them, and imo it's the thing that keeps it unique and
> important (PoW ties in; it's
> > another aspect of the same rigid adherence to no controlling entities).
> >
> > That's why both this idea and Peter Todd's tail emission idea, both high
> quality engineering-safety
> > thinking, will not happen, in my opinion.
>
> I obviously agree with you at a high level - the value of Bitcoin derives
> from its (attempt at)
> trustlessness and any attempts to break that will necessarily result in
> the market rejecting them
> precisely because they break the exact thing that gives Bitcoin value.
>
> Its also hard to analyze this because it depends so much on the very exact
> scenario we're talking
> about. There are indeed certainly scenarios I can imagine where I think
> the market would prefer to
> not disable insecure spend paths. But at the risk of using an equally
> absurd example as yours,
>
> Imagine we discover a breakthrough in refrigeration technology that we've
> missed for 200 years
> tomorrow (or a room temperature superconductor, or...) plus a few other
> major engineering
> breakthroughs and we're now on track to have a CRQC in 2-3 years instead
> of 15-20, and oh in 6
> months we discover that they're not just gonna be buildable soon but
> pretty easy to build farms and
> they'll be able to calculate a private key in seconds. Yes, we can stand
> on principle and watch as
> the CRQCs steal all the bitcoin and sell them to recoup their investment,
> but the market is
> obviously not going to value that because the thing that's left isn't
> recognizable as Bitcoin - its
> just some weird cryptographic scheme where tokens are shifting around all
> the time and everyone is
> stealing from everyone else.
>
> There would certainly be market participants (like you, I guess :p) that
> try to hold on to the
> original Bitcoin and might even invest some money in buying more (from the
> CRQC-operators). And the
> insecure-spend-paths-disabled fork would probably have somewhat less value
> than the original as a
> result. But the original chain would without question have nearly zero
> value, and the fork might
> have some.
>
> Now, this scenario maybe seems exaggerated, but actually I think its
> equivalent to the most likely
> outcome. Not that I think we'll see multiple major 100-year physics
> breakthroughs soon, but rather
> if we see a CRQC in the next 10-20 years, that the state of Bitcoin wallet
> adoption of PQ spend
> paths will be only marginally better than it is today. Sure, maybe 50% of
> wallets have upgraded, but
> that's not enough to have any outcome materially different from the above.
>
> Finally, more philosophically, I disagree that these are somehow
> equivalent. Yes, in stated
> black-and-white principles it violates the "ethics of Bitcoin", but that
> the *alternative does too*.
> Leaving the coins to be stolen by a CRQC almost equally violates the
> "ethics of Bitcoin" - the
> rightful owner of the coins, the one that created the private key and did
> not leak that private key
> to anyone else no longer has the coins! but...
>
> > > ZK proof-of-seedphrase :).
> >
> > Oh cool, that's a good point. Ethan's counterpoint is good too, that we
> would need a consensus rule
> > and that's v. hard, but: my spidey sense is tingling a bit about whether
> people might find tricks to
> > avoid it: if you consider the very clever tricks recently discovered
> around Glock, ArgoMAC and so
> > on, they enable gating txs behind ZKP schemes w/o new consensus but what
> we're talking about here is
> > way more narrowly defined than the larger problem they're trying to
> solve, which might support being
> > optimistic ...).
>
> I think this makes the philosophical point more stark! Now the options in
> front of the future
> Bitcoin community aren't "burn the coins or let the CRQC-operator steal
> them" then options in front
> of the future Bitcoin community are "burn some of the coins and let a
> probably-majority of the
> rightful owners claim them, or let the CRQC-operator steal all of them". I
> cannot justify why the
> second option is somehow more ethical or more in line with building the
> best, most trustless money
> on the planet.
>
> Matt
>
--
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/f9d2dd92-7fda-4d4c-a91d-02bc79460b69n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 11579 bytes --]
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms
2026-02-14 12:39 ` waxwing/ AdamISZ
@ 2026-02-15 12:12 ` Matt Corallo
0 siblings, 0 replies; 42+ messages in thread
From: Matt Corallo @ 2026-02-15 12:12 UTC (permalink / raw)
To: waxwing/ AdamISZ, Bitcoin Development Mailing List
On 2/14/26 7:39 AM, waxwing/ AdamISZ wrote:
> Hi Matt, on this point:
>
> > Imagine we discover a breakthrough in refrigeration technology that we've missed for 200 years
> tomorrow (or a room temperature superconductor, or...) plus a few other major engineering
> breakthroughs and we're now on track to have a CRQC in 2-3 years instead of 15-20, and oh in 6
> months we discover that they're not just gonna be buildable soon but pretty easy to build farms and
> they'll be able to calculate a private key in seconds. Yes, we can stand on principle and watch as
> the CRQCs steal all the bitcoin and sell them to recoup their investment, but the market is
> obviously not going to value that because the thing that's left isn't recognizable as Bitcoin - its
> just some weird cryptographic scheme where tokens are shifting around all the time and everyone is
> stealing from everyone else.
>
> For sure. It's unlikely but it's certainly *not* out of scope. Basically the "it happens fast" scenario.
>
> I don't see how it changes anything about the general principles. It's just worse. People who are active
> are going to move their coins to new outputs. People who are dead or lost the keys are not. (People who
> have locked them in a way that they are 100% inaccessible for 5+ years are of course the most
> unfortunate case here, perhaps worth discussing separately.)
No, its not just worse, it makes migration *impossible*. If we're talking about having a large
majority of coins (certainly ~all the "active" ones) move within a year or so, we'd have to first do
an immediate hard-fork to increase the block size to enable the migration to complete in time. In
the mean time fees will be insane.
> It's just a worse (in terms of turbulence) version of the (far, far more likely) slow scenario.
>
> Look, I get the "yuck" reflex and the "this is ridiculous" reflex; if something is patently
> obviously "open" and previously wasn't, then "obviously" we should just lock it up - or do
> something, anyway. But the real world, whether it's a 2 year time frame or the more likely 20-50++
> year timeframe, doesn't have this clean epistemology: we won't *know for sure* when the world shifts
> from "outputs are safe" to "this stuff is claimable by anyone with the machine". Even *if* it isn't
> all developed in super-secret (it probably will be), we still won't know.
I don't really buy this. Sure, we won't be able to predict, with certainty, two years out, the exact
day on which the first private key will be calculated correctly from a public key. But we will, in
all likelihood, be able to predict two years out that a CRQC is somewhere between one and three
years away. In that case, again in many likely scenarios though not all, I really do not think that
disabling insecure (non-seedphrase) spend paths is somehow immoral or against the tao of bitcoin.
> That's why I said "perhaps
> worth discussing separately" for timelocks; there you have objective, public-verifiable "this is
> frozen" status. The "secure" vs "insecure" status simply will not be knowable in advance. That makes
> any engineering decisions that even *might* violate private property rights completely unworkable.
>
> > we can stand on principle and watch as
> the CRQCs steal all the bitcoin and sell them to recoup their investment
>
> yes, this is precisely what you would have to do (except as per previous paragraph, it will *not* be
> obvious, even if large movements occur - what if someone actually owns the coins and is trying to
> trick the market?). Assuming the thesis is correct (that it's CRQCs doing it), then the coins at
> that point are held in completely insecure outputs. Who has the right to take them? Answer: anyone
> who's fast enough, just like a coin whose private key is "123" or similarly insecure, gets taken all
> the time. Should the network freeze insecure private keys when it sees them?
>
> The problem is not the *reasoning* of safety. The problem is that, more than safety, principles
> matter, and unlike Groucho Marx, we don't have any others :)
Right again I think a decent part of our disagreement here is that we're imaging drastically
different scenarios. You (and I believe Odell and others) are imagining a world where there's a
secret government lab operating a CRQC and stealing Bitcoin. We aren't sure if its a CRQC that's
moving these coins, we have no strong public evidence of it, and there's debate as to whether to
burn coins in response to very weak evidence. In that scenario I'd likely agree with you.
However, I do not buy this scenario as at-all likely. Thus far we've seen QC research operate
largely in the open, with a small world of researchers publishing their progress for financing
reasons - the more you talk about the progress the more you can continue to raise money to keep
working on it. Even if some labs "go dark" after making substantial progress, we'll be aware of the
trajectory of their progress before they do and can make reasonable, if conservative, conclusions
about their timeline. Given the huge cost of these machines they largely haven't been the domain of
academic labs (where there is a long history of government research partnership), but rather private
enterprise, where there is an interest in public promotion to encourage the market to buy their stock.
Further, given consensus cryptography recommendations have been pushing supporting PQ schemes to
avoid a rush to upgrade in a decade and the adoption of such schemes, its not clear to me that, by
the time a CRQC is actually built, there will be all that much left waiting to upgrade (aside from,
of course, borderline-unmaintained projects). Keeping a government-secret CRQC when public QC
research is screaming "we're only a few years away" is probably not actually all that valuable - the
value is decrypting old, now-insecure communication you've already captured.
Finally, its worth noting that this "secret government lab CRQC" seems somewhat unlikely to run
around stealing large quantities of Bitcoin. Such a CRQC only has any value if it stays a secret,
and any Bitcoin you steal is likely to start generating rumors, which will intensify greatly as you
steal more. At some point you've basically tipped your hand and might as well just make it public.
Matt
--
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/da3265b4-e153-4c82-b0ed-e6bb021db7c6%40mattcorallo.com.
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms
2026-02-11 0:19 ` Erik Aronesty
2026-02-11 2:40 ` Ethan Heilman
@ 2026-02-17 4:13 ` 'conduition' via Bitcoin Development Mailing List
2026-02-17 7:39 ` 'conduition' via Bitcoin Development Mailing List
1 sibling, 1 reply; 42+ messages in thread
From: 'conduition' via Bitcoin Development Mailing List @ 2026-02-17 4:13 UTC (permalink / raw)
To: Erik Aronesty; +Cc: Ethan Heilman, Jonas Nick, bitcoindev
[-- Attachment #1.1.1: Type: text/plain, Size: 3742 bytes --]
Hi list, just wanted to pipe in on the subject of commit/reveal using OP_TXHASH. I don't think it is possible. The protocol link Erik posted ( https://delvingbitcoin.org/t/a-quantum-resistance-script-only-using-op-ctv-op-txhash-and-no-new-signatures/2168 ) seems to contradict itself. On one hand the author says phase zero doesn't commit to final CTV templates E & T. However it also says T & E are committed to via the P_anchor tapscript tree, which must be pinned by phase 0. So unless I'm misunderstanding, this technique seems to require a priori knowledge of template hashes T and E when creating the funding address and UTXO in phase 0, so this would not be viable as a PQ fallback spending path. Happy to be proven wrong.
regards,
conduition
On Wednesday, February 11th, 2026 at 1:06 AM, Erik Aronesty <erik@q32.com> wrote:
> >
> >
> > You'd still need BIP 360 P2MR (or P2TRD) since OP_TXHASH needs tapscript, and the only available tapscript supporting output type, P2TR, isn't quantum safe.
>
>
> false, covenant based multistep secret-reveal spending paths don't rely on signatures at all
>
> >
> > I'm going to assume:
> > - you mean to use this commit-reveal for migrating between signature algorithms, not for everyday use,
>
>
> it can be used if "q day" happens. otherwise ignored.
>
> > - TXHASH is being used because you are waiting for the commitment to be confirmed on-chain rather than lifeboat's out-of-band commitment system
>
>
> it's used so you can commit to a spending constraint without committing to the final "as yet to be determined" quantum-safe destination: https://delvingbitcoin.org/t/a-quantum-resistance-script-only-using-op-ctv-op-txhash-and-no-new-signatures/2168
>
> > Once you post your commit-txn, but before it confirms, other parties can post competing commit-txns that double spend your output. If one of malicious transactions confirm, you must now wait for a timelock to expire and then try to post your transaction.
>
>
> agreed. they have to spend resources to attack your private key and the only thing they can do is "grief" using a timing attack with the results, rather than steal outright. a massive incentive difference.
>
> > They can block you again. Each time they burn some of you coins in fees. Miners get the fees, so they might be incentivized to do this. Thus, we must trust miners not to do this. Lifeboat doesn't have this issue since it uses out-of-band commitments, but out-of-band commitments have their own issues.
>
>
> each time you use the reset-path, they have to re-attack a new key. very expensive just to grief a small amount of fees spread across all miners. sounds like science-fiction levels of compute.
>
> plus.... TX_HASH is simple and generally useful and there is no guarantee that q-day will even come
>
> --
> 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/CAJowKgL5okUA%3DDHSyUJfzdb6p_z5a6H_hN6NuhZo6R9ZYbJFUQ%40mail.gmail.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/ByJc1I7sSQAMLnAzSHPi8KSSscU0qakPM2YI0qC6VBBOwzmYtQEW5NY6d80eLUCf7fmKxbdFlSuxm4RCoT5rtKT68Khdi2xjwYIu4B5e6BQ%3D%40proton.me.
[-- Attachment #1.1.2.1: Type: text/html, Size: 6703 bytes --]
[-- 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 --]
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms
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 18:48 ` Erik Aronesty
0 siblings, 2 replies; 42+ messages in thread
From: 'conduition' via Bitcoin Development Mailing List @ 2026-02-17 7:39 UTC (permalink / raw)
To: conduition; +Cc: Erik Aronesty, Ethan Heilman, Jonas Nick, bitcoindev
[-- Attachment #1.1.1: Type: text/plain, Size: 11807 bytes --]
> I just don't see a reason to do P2MR over just utilizing P2TR (or maybeP2TRv2).
>
> P2MR will *also* require an equivalent P2MR-disable-soft-fork
P2TRv2 means locking wallets into using elliptic curve code for as long as P2TRv2 exists, because you will always have to compute and verify the tweaked output pubkey. Future PQ Bitcoin wallet devs will see secp256k1 as we today see broken primitives like md5 or DES. Future devs shouldn't have to add legacy cruft EC libraries into their codebases when it's not even usable for cryptography anymore.
Even if you assume a second P2MR-disable-soft-fork will be needed (which is debatable), then it still pays to remove the inefficient and unnecessary cruft of EC crypto for the foreseeable post-quantum future. You might think of it as decoupling UTXO ownership from any specific public-key cryptosystem.
Furthermore, if EC/keypath spending is disabled, P2MR actually requires less witness space per input than P2TRv2 because we dont need the now-useless internal key in a P2MR script spend witness, whereas P2TRv2 will require it indefinitely until we can migrate to another new address format in the distant future. See https://github.com/bitcoin/bips/blob/master/bip-0360.mediawiki#comparison-with-p2tr-script-path-spend
P2MR is strictly more secure since it depends on weaker assumptions. P2TRv2 is more complex for wallets to implement than P2MR, unless you count code reuse from P2TRv1. P2TRv2 is (marginally) computationally slower, and less block-space-efficient for script path spends. So who would choose P2TRv2 over P2MR?
The only redeeming factor of P2TRv2 is that it saves a few dozen witness bytes per input when using schnorr EC key spending, compared to P2MR spending. For low-frequency use cases like cold storage, that doesnt matter much. At current rates thats like 10 sats per input. For high frequency use cases where every vbyte counts like hot wallets, exchanges, mining payouts, etc, i have good news: P2TRv1 still exists and can be used just fine. You "just" need to make sure the coins are moved to a PQ address before a quantum computer attacks them. I'm assuming these high-frequency use case actors are online enough to take that last step when necessary.
Thus i see P2MR as the superior choice to P2TRv2 even if P2TRv2 may be slightly more space efficient in the near-term. Thinking longer term, P2MR is the better choice.
Thinking even further into the future, we have options for a sort of P2TR-style of address using isogenies, by hiding a commitment to a taproot-style script tree inside a public key curve (public keys in isogeny cryptosystems are represented by elliptic curves). Keypath spending would be via SQIsign (or other schemes). So don't worry, we are not stuck with only merkle trees forever. I'll elaborate more on this idea in a forthcoming article i have cooking on isogenies.
> ZK proof-of-seedphrase
If we were going to use a ZK proof to rescue quantum procrastinators, it should be proof of BIP32 hardened key derivation, and possibly also proof of pubkey hash preimage knowledge. This is strictly more general than a zero-knowledge proof of seed phrase, the arithmetization would be wayyy more efficient, and would recover more coins from more diverse wallet types.
Also, there is no need for it to be a hefty zero-knowledge proof, like a STARK. Rescue could be deployed using a commit and reveal protocol, as has been discussed on the list previously (sorry, i dont have the link in front of me right now). The idea is that a sender can rescue frozen UTXOs using a commit/reveal sequence of transactions which ultimately proves the sender knew a BIP32 parent xpriv (or pubkey hash preimage) which controls the coins in question through hardened BIP32 CKD, which a CRQC shouldn't be able to forge.
This would maximize rescue coverage while minimizing blockspace congestion, and could be done as a soft fork.
-----
I'm glad to see thoughtful discussion on the subject of how to handle a quantum freeze. But it is important to put this in perspective in the context of this thread: right now the number one most important thing - which we NEED to do if Bitcoin is to survive appearance of a CRQC - is to provide a standardized wallet address format which includes a secure fallback way to authenticate UTXOs if ECC is unsafe to use. We can debate about freezing or rescuing coins, or the philosophy of ownership, but these questions will not be decidable for years.
What is decidable is this: how would you change Ethan's proposal, if at all? I'll remind everyone that currently it is limited only to adding two features: BIP360 P2MR addresses, and SLH-DSA opcodes. Those two changes are all we need in consensus to finally give hodlers an option to migrate.
I've gone through and catalogued some of the feedback on Ethan's proposal. So far I've heard these material critiques:
1. Why not instead deploy covenant opcodes (TXHASH, CTV) and use them to implement commit/reveal?
As i mentioned in my last message i don't think that is possible, at least not using the technique Erik linked. I'd be happy to be proven wrong here because that'd be fantastic news if true.
2. Why not use SHRINCS instead of SLH-DSA?
Seems like a valid idea to me. SHRINCS would add implementation and UX complexity but it'd also make the fallback sig scheme scalable - a very nice property to have in the worst case scenario where a majority of users end up needing to sign with it. Philosophically i dislike statefulness in a cryptosystem, but maybe as a fallback it is an acceptable tradeoff.
3. Why not deploy GSR and let wallet devs roll their own crypto?
As ethan pointed out, this would be bad for standardization and interoperability, and also requires GSR to be deployed as a pre-requisite. If GSR is activated and in-script signing schemes are standardized correctly, it could possibly be a suitable alternative to activating dedicated SLH-DSA opcodes.
4. Why not continue using P2TR and disable keypath spending later, rather than adding a whole new address format?
As ethan pointed out, this depends on timing a future disabling soft fork correctly and will lead to FUD, avoidable debate, and confusion. It is also confiscatory, as it would freeze standardized keypath-only P2TR outputs which lack a script path.
5. Why not redeploy P2TR with a new segwit version number, which opts into a future keypath-disabling soft fork?
Ethan and i have both made some compelling arguments as to why we should give the community a new address format which is totally decoupled from any PQ-vulnerable cryptography. If the increased fees of P2MR are an issue for high-frequency hot wallets, P2TR is still viable, at least until Q-day. As stated Ethan's proposal is more motivated by long term cold storage use cases. I consider a small increase in witness size to be an acceptable tradeoff for (speculative) quantum security, and the costs of clinging to those savings in the near-term to be unacceptable. Key-path spending may be reinvented in the future using other novel cryptosystems, with another new address format that depends on new cryptographic assumptions.
-----
I apologize if i missed anyone's feedback notes in this summary. Please correct me if i have!
regards,
conduition
On Tuesday, February 17th, 2026 at 4:22 AM, 'conduition' via Bitcoin Development Mailing List <bitcoindev@googlegroups.com> wrote:
> Hi list, just wanted to pipe in on the subject of commit/reveal using OP_TXHASH. I don't think it is possible. The protocol link Erik posted ( https://delvingbitcoin.org/t/a-quantum-resistance-script-only-using-op-ctv-op-txhash-and-no-new-signatures/2168 ) seems to contradict itself. On one hand the author says phase zero doesn't commit to final CTV templates E & T. However it also says T & E are committed to via the P_anchor tapscript tree, which must be pinned by phase 0. So unless I'm misunderstanding, this technique seems to require a priori knowledge of template hashes T and E when creating the funding address and UTXO in phase 0, so this would not be viable as a PQ fallback spending path. Happy to be proven wrong.
>
> regards,
> conduition
>
>
>
> On Wednesday, February 11th, 2026 at 1:06 AM, Erik Aronesty <erik@q32.com> wrote:
>
> > >
> > >
> > > You'd still need BIP 360 P2MR (or P2TRD) since OP_TXHASH needs tapscript, and the only available tapscript supporting output type, P2TR, isn't quantum safe.
> >
> >
> > false, covenant based multistep secret-reveal spending paths don't rely on signatures at all
> >
> > >
> > > I'm going to assume:
> > > - you mean to use this commit-reveal for migrating between signature algorithms, not for everyday use,
> >
> >
> > it can be used if "q day" happens. otherwise ignored.
> >
> > > - TXHASH is being used because you are waiting for the commitment to be confirmed on-chain rather than lifeboat's out-of-band commitment system
> >
> >
> > it's used so you can commit to a spending constraint without committing to the final "as yet to be determined" quantum-safe destination: https://delvingbitcoin.org/t/a-quantum-resistance-script-only-using-op-ctv-op-txhash-and-no-new-signatures/2168
> >
> > > Once you post your commit-txn, but before it confirms, other parties can post competing commit-txns that double spend your output. If one of malicious transactions confirm, you must now wait for a timelock to expire and then try to post your transaction.
> >
> >
> > agreed. they have to spend resources to attack your private key and the only thing they can do is "grief" using a timing attack with the results, rather than steal outright. a massive incentive difference.
> >
> > > They can block you again. Each time they burn some of you coins in fees. Miners get the fees, so they might be incentivized to do this. Thus, we must trust miners not to do this. Lifeboat doesn't have this issue since it uses out-of-band commitments, but out-of-band commitments have their own issues.
> >
> >
> > each time you use the reset-path, they have to re-attack a new key. very expensive just to grief a small amount of fees spread across all miners. sounds like science-fiction levels of compute.
> >
> > plus.... TX_HASH is simple and generally useful and there is no guarantee that q-day will even come
> >
> > --
> > 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/CAJowKgL5okUA%3DDHSyUJfzdb6p_z5a6H_hN6NuhZo6R9ZYbJFUQ%40mail.gmail.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/ByJc1I7sSQAMLnAzSHPi8KSSscU0qakPM2YI0qC6VBBOwzmYtQEW5NY6d80eLUCf7fmKxbdFlSuxm4RCoT5rtKT68Khdi2xjwYIu4B5e6BQ%3D%40proton.me.
--
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/GhzGKZ5zphDf7mFpC_PMD0Bn7-KIK14HXdCPLeB7HKvPBfDRVG8eUAlCKKLWcki6XDW0h0R1IQC5SS9B7jnMRS85GzOzcmCt9v5R3xoW4Js%3D%40proton.me.
[-- Attachment #1.1.2.1: Type: text/html, Size: 16823 bytes --]
[-- 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 --]
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms
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
1 sibling, 1 reply; 42+ messages in thread
From: Garlo Nicon @ 2026-02-19 14:35 UTC (permalink / raw)
To: conduition; +Cc: Erik Aronesty, Ethan Heilman, Jonas Nick, bitcoindev
[-- Attachment #1: Type: text/plain, Size: 14293 bytes --]
> Future PQ Bitcoin wallet devs will see secp256k1 as we today see broken
primitives like md5 or DES.
We still have OP_SHA1 in the Script, and even in the TapScript, even though
there are known collisions for that. Also note, that MD5 is broken, only
when it comes to collisions. MD5 preimages are still unknown, because
mounting a preimage attack is much harder.
So, if we talk about disabling obsolete cryptography, then when OP_SHA1
will be disabled? I guess it won't change in the nearest future, even
though the first SHA-1 collision happened in February 2017, around 9 years
ago.
> Future devs shouldn't have to add legacy cruft EC libraries into their
codebases when it's not even usable for cryptography anymore.
Well, to fully break OP_CHECKSIG, you need to break both secp256k1 and
SHA-256. Otherwise, by breaking only secp256k1 alone, you will still have
40-byte DER signatures, and not 9-byte minimal ones, where everything is
fully broken. And it is possible to enforce a given Proof of Work, if you
use OP_SIZE on DER signatures. Even if you use private key, equal to one,
then still: you won't sweep everything, for example from this transaction:
aba3c2ae442aa20150996ee68f9aa4da83b57a4312891078be0c2e68c50b2801
Which means, that there are still use cases for OP_CHECKSIG, even if you
can break secp256k1, as long as you cannot break SHA-256.
wt., 17 lut 2026 o 08:51 'conduition' via Bitcoin Development Mailing List <
bitcoindev@googlegroups.com> napisał(a):
> > I just don't see a reason to do P2MR over just utilizing P2TR (or maybe
> P2TRv2).
> >
> > P2MR will *also* require an equivalent P2MR-disable-soft-fork
>
>
>
> P2TRv2 means locking wallets into using elliptic curve code for as long as
> P2TRv2 exists, because you will always have to compute and verify the
> tweaked output pubkey. Future PQ Bitcoin wallet devs will see secp256k1 as
> we today see broken primitives like md5 or DES. Future devs shouldn't have
> to add legacy cruft EC libraries into their codebases when it's not even
> usable for cryptography anymore.
>
> Even if you assume a second P2MR-disable-soft-fork will be needed (which
> is debatable), then it still pays to remove the inefficient and unnecessary
> cruft of EC crypto for the foreseeable post-quantum future. You might think
> of it as decoupling UTXO ownership from any specific public-key
> cryptosystem.
>
> Furthermore, if EC/keypath spending is disabled, P2MR actually requires
> less witness space per input than P2TRv2 because we dont need the
> now-useless internal key in a P2MR script spend witness, whereas P2TRv2
> will require it indefinitely until we can migrate to another new address
> format in the distant future. See
> https://github.com/bitcoin/bips/blob/master/bip-0360.mediawiki#comparison-with-p2tr-script-path-spend
>
> P2MR is strictly more secure since it depends on weaker assumptions.
> P2TRv2 is more complex for wallets to implement than P2MR, unless you count
> code reuse from P2TRv1. P2TRv2 is (marginally) computationally slower, and
> less block-space-efficient for script path spends. So who would choose
> P2TRv2 over P2MR?
>
> The only redeeming factor of P2TRv2 is that it saves a few dozen witness
> bytes per input when using schnorr EC key spending, compared to P2MR
> spending. For low-frequency use cases like cold storage, that doesnt matter
> much. At current rates thats like 10 sats per input. For high frequency use
> cases where every vbyte counts like hot wallets, exchanges, mining payouts,
> etc, i have good news: P2TRv1 still exists and can be used just fine. You
> "just" need to make sure the coins are moved to a PQ address before a
> quantum computer attacks them. I'm assuming these high-frequency use case
> actors are online enough to take that last step when necessary.
>
> Thus i see P2MR as the superior choice to P2TRv2 even if P2TRv2 may be
> slightly more space efficient in the near-term. Thinking longer term, P2MR
> is the better choice.
>
> Thinking even further into the future, we have options for a sort of
> P2TR-style of address using isogenies, by hiding a commitment to a
> taproot-style script tree inside a public key curve (public keys in isogeny
> cryptosystems are represented by elliptic curves). Keypath spending would
> be via SQIsign (or other schemes). So don't worry, we are not stuck with
> only merkle trees forever. I'll elaborate more on this idea in a
> forthcoming article i have cooking on isogenies.
>
>
> > ZK proof-of-seedphrase
>
> If we were going to use a ZK proof to rescue quantum procrastinators, it
> should be proof of BIP32 hardened key derivation, and possibly also proof
> of pubkey hash preimage knowledge. This is strictly more general than a
> zero-knowledge proof of seed phrase, the arithmetization would be wayyy
> more efficient, and would recover more coins from more diverse wallet types.
>
> Also, there is no need for it to be a hefty zero-knowledge proof, like a
> STARK. Rescue could be deployed using a commit and reveal protocol, as has
> been discussed on the list previously (sorry, i dont have the link in front
> of me right now). The idea is that a sender can rescue frozen UTXOs using a
> commit/reveal sequence of transactions which ultimately proves the sender
> knew a BIP32 parent xpriv (or pubkey hash preimage) which controls the
> coins in question through hardened BIP32 CKD, which a CRQC shouldn't be
> able to forge.
>
> This would maximize rescue coverage while minimizing blockspace
> congestion, and could be done as a soft fork.
>
>
> -----
>
> I'm glad to see thoughtful discussion on the subject of how to handle a
> quantum freeze. But it is important to put this in perspective in the
> context of this thread: right now the number one most important thing -
> which we NEED to do if Bitcoin is to survive appearance of a CRQC - is to
> provide a standardized wallet address format which includes a secure
> fallback way to authenticate UTXOs if ECC is unsafe to use. We can debate
> about freezing or rescuing coins, or the philosophy of ownership, but these
> questions will not be decidable for years.
>
> What is decidable is this: how would you change Ethan's proposal, if at
> all? I'll remind everyone that currently it is limited only to adding two
> features: BIP360 P2MR addresses, and SLH-DSA opcodes. Those two changes are
> all we need in consensus to finally give hodlers an option to migrate.
>
>
> I've gone through and catalogued some of the feedback on Ethan's proposal.
> So far I've heard these material critiques:
>
>
> 1. Why not instead deploy covenant opcodes (TXHASH, CTV) and use them to
> implement commit/reveal?
>
> As i mentioned in my last message i don't think that is possible, at least
> not using the technique Erik linked. I'd be happy to be proven wrong here
> because that'd be fantastic news if true.
>
>
> 2. Why not use SHRINCS instead of SLH-DSA?
>
> Seems like a valid idea to me. SHRINCS would add implementation and UX
> complexity but it'd also make the fallback sig scheme scalable - a very
> nice property to have in the worst case scenario where a majority of users
> end up needing to sign with it. Philosophically i dislike statefulness in a
> cryptosystem, but maybe as a fallback it is an acceptable tradeoff.
>
>
> 3. Why not deploy GSR and let wallet devs roll their own crypto?
>
> As ethan pointed out, this would be bad for standardization and
> interoperability, and also requires GSR to be deployed as a pre-requisite.
> If GSR is activated and in-script signing schemes are standardized
> correctly, it could possibly be a suitable alternative to activating
> dedicated SLH-DSA opcodes.
>
>
> 4. Why not continue using P2TR and disable keypath spending later, rather
> than adding a whole new address format?
>
> As ethan pointed out, this depends on timing a future disabling soft fork
> correctly and will lead to FUD, avoidable debate, and confusion. It is also
> confiscatory, as it would freeze standardized keypath-only P2TR outputs
> which lack a script path.
>
>
> 5. Why not redeploy P2TR with a new segwit version number, which opts into
> a future keypath-disabling soft fork?
>
> Ethan and i have both made some compelling arguments as to why we should
> give the community a new address format which is totally decoupled from any
> PQ-vulnerable cryptography. If the increased fees of P2MR are an issue for
> high-frequency hot wallets, P2TR is still viable, at least until Q-day. As
> stated Ethan's proposal is more motivated by long term cold storage use
> cases. I consider a small increase in witness size to be an acceptable
> tradeoff for (speculative) quantum security, and the costs of clinging to
> those savings in the near-term to be unacceptable. Key-path spending may be
> reinvented in the future using other novel cryptosystems, with another new
> address format that depends on new cryptographic assumptions.
>
> -----
>
> I apologize if i missed anyone's feedback notes in this summary. Please
> correct me if i have!
>
> regards,
> conduition
>
>
> On Tuesday, February 17th, 2026 at 4:22 AM, 'conduition' via Bitcoin
> Development Mailing List <bitcoindev@googlegroups.com> wrote:
>
> Hi list, just wanted to pipe in on the subject of commit/reveal using
> OP_TXHASH. I don't think it is possible. The protocol link Erik posted (
> https://delvingbitcoin.org/t/a-quantum-resistance-script-only-using-op-ctv-op-txhash-and-no-new-signatures/2168
> ) seems to contradict itself. On one hand the author says phase zero
> doesn't commit to final CTV templates E & T. However it also says T & E are
> committed to via the P_anchor tapscript tree, which must be pinned by phase
> 0. So unless I'm misunderstanding, this technique seems to require a priori
> knowledge of template hashes T and E when creating the funding address and
> UTXO in phase 0, so this would not be viable as a PQ fallback spending
> path. Happy to be proven wrong.
>
> regards,
> conduition
>
>
>
> On Wednesday, February 11th, 2026 at 1:06 AM, Erik Aronesty <erik@q32.com>
> wrote:
>
>
>>
>> You'd still need BIP 360 P2MR (or P2TRD) since OP_TXHASH needs tapscript,
>> and the only available tapscript supporting output type, P2TR, isn't
>> quantum safe.
>>
>
> false, covenant based multistep secret-reveal spending paths don't rely on
> signatures at all
>
>>
>> I'm going to assume:
>> - you mean to use this commit-reveal for migrating between signature
>> algorithms, not for everyday use,
>>
>
> it can be used if "q day" happens. otherwise ignored.
>
>> - TXHASH is being used because you are waiting for the commitment to be
>> confirmed on-chain rather than lifeboat's out-of-band commitment system
>>
>
> it's used so you can commit to a spending constraint without committing to
> the final "as yet to be determined" quantum-safe destination:
> https://delvingbitcoin.org/t/a-quantum-resistance-script-only-using-op-ctv-op-txhash-and-no-new-signatures/2168
>
>> Once you post your commit-txn, but before it confirms, other parties can
>> post competing commit-txns that double spend your output. If one of
>> malicious transactions confirm, you must now wait for a timelock to expire
>> and then try to post your transaction.
>>
>
> agreed. they have to spend resources to attack your private key and the
> only thing they can do is "grief" using a timing attack with the results,
> rather than steal outright. a massive incentive difference.
>
>> They can block you again. Each time they burn some of you coins in fees.
>> Miners get the fees, so they might be incentivized to do this. Thus, we
>> must trust miners not to do this. Lifeboat doesn't have this issue since it
>> uses out-of-band commitments, but out-of-band commitments have their own
>> issues.
>>
>
> each time you use the reset-path, they have to re-attack a new key. very
> expensive just to grief a small amount of fees spread across all miners.
> sounds like science-fiction levels of compute.
>
> plus.... TX_HASH is simple and generally useful and there is no guarantee
> that q-day will even come
>
> --
> 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/CAJowKgL5okUA%3DDHSyUJfzdb6p_z5a6H_hN6NuhZo6R9ZYbJFUQ%40mail.gmail.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/ByJc1I7sSQAMLnAzSHPi8KSSscU0qakPM2YI0qC6VBBOwzmYtQEW5NY6d80eLUCf7fmKxbdFlSuxm4RCoT5rtKT68Khdi2xjwYIu4B5e6BQ%3D%40proton.me
> .
>
>
> --
> 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/GhzGKZ5zphDf7mFpC_PMD0Bn7-KIK14HXdCPLeB7HKvPBfDRVG8eUAlCKKLWcki6XDW0h0R1IQC5SS9B7jnMRS85GzOzcmCt9v5R3xoW4Js%3D%40proton.me
> <https://groups.google.com/d/msgid/bitcoindev/GhzGKZ5zphDf7mFpC_PMD0Bn7-KIK14HXdCPLeB7HKvPBfDRVG8eUAlCKKLWcki6XDW0h0R1IQC5SS9B7jnMRS85GzOzcmCt9v5R3xoW4Js%3D%40proton.me?utm_medium=email&utm_source=footer>
> .
>
--
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/CAN7kyNizzKzDg4fVOGe976Xq%3DMLCpiAufZaJLkRV-AhhFW28_g%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 19380 bytes --]
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms
2026-02-19 14:35 ` Garlo Nicon
@ 2026-02-20 1:41 ` Alex
0 siblings, 0 replies; 42+ messages in thread
From: Alex @ 2026-02-20 1:41 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 15434 bytes --]
> So, if we talk about disabling obsolete cryptography, then when OP_SHA1
will be disabled?
This is a dishonest misrepresentation of the proposal in this thread.
Nobody is arguing about disabling any algorithm. The proposal _explicitly_
states, that the same Elliptic Curve signatures would still be the
preferred default signatures and that they merely would move from being
implicitly default via the key spend path to instead being explicitly
called upon via a spending script.
Please, do not strawman the proposal if you haven't read it. Nobody is
arguing about disabling Schnorr/ECDSA. Read the proposal before assuming.
torsdag 19 februari 2026 kl. 16:12:01 UTC+1 skrev Garlo Nicon:
> > Future PQ Bitcoin wallet devs will see secp256k1 as we today see broken
> primitives like md5 or DES.
>
> We still have OP_SHA1 in the Script, and even in the TapScript, even
> though there are known collisions for that. Also note, that MD5 is broken,
> only when it comes to collisions. MD5 preimages are still unknown, because
> mounting a preimage attack is much harder.
>
> So, if we talk about disabling obsolete cryptography, then when OP_SHA1
> will be disabled? I guess it won't change in the nearest future, even
> though the first SHA-1 collision happened in February 2017, around 9 years
> ago.
>
>
> > Future devs shouldn't have to add legacy cruft EC libraries into their
> codebases when it's not even usable for cryptography anymore.
>
> Well, to fully break OP_CHECKSIG, you need to break both secp256k1 and
> SHA-256. Otherwise, by breaking only secp256k1 alone, you will still have
> 40-byte DER signatures, and not 9-byte minimal ones, where everything is
> fully broken. And it is possible to enforce a given Proof of Work, if you
> use OP_SIZE on DER signatures. Even if you use private key, equal to one,
> then still: you won't sweep everything, for example from this transaction:
> aba3c2ae442aa20150996ee68f9aa4da83b57a4312891078be0c2e68c50b2801
>
> Which means, that there are still use cases for OP_CHECKSIG, even if you
> can break secp256k1, as long as you cannot break SHA-256.
>
> wt., 17 lut 2026 o 08:51 'conduition' via Bitcoin Development Mailing List
> <bitco...@googlegroups.com> napisał(a):
>
>> > I just don't see a reason to do P2MR over just utilizing P2TR (or maybe
>> P2TRv2).
>> >
>> > P2MR will *also* require an equivalent P2MR-disable-soft-fork
>>
>>
>>
>> P2TRv2 means locking wallets into using elliptic curve code for as long
>> as P2TRv2 exists, because you will always have to compute and verify the
>> tweaked output pubkey. Future PQ Bitcoin wallet devs will see secp256k1 as
>> we today see broken primitives like md5 or DES. Future devs shouldn't have
>> to add legacy cruft EC libraries into their codebases when it's not even
>> usable for cryptography anymore.
>>
>> Even if you assume a second P2MR-disable-soft-fork will be needed (which
>> is debatable), then it still pays to remove the inefficient and unnecessary
>> cruft of EC crypto for the foreseeable post-quantum future. You might think
>> of it as decoupling UTXO ownership from any specific public-key
>> cryptosystem.
>>
>> Furthermore, if EC/keypath spending is disabled, P2MR actually requires
>> less witness space per input than P2TRv2 because we dont need the
>> now-useless internal key in a P2MR script spend witness, whereas P2TRv2
>> will require it indefinitely until we can migrate to another new address
>> format in the distant future. See
>> https://github.com/bitcoin/bips/blob/master/bip-0360.mediawiki#comparison-with-p2tr-script-path-spend
>>
>> P2MR is strictly more secure since it depends on weaker assumptions.
>> P2TRv2 is more complex for wallets to implement than P2MR, unless you count
>> code reuse from P2TRv1. P2TRv2 is (marginally) computationally slower, and
>> less block-space-efficient for script path spends. So who would choose
>> P2TRv2 over P2MR?
>>
>> The only redeeming factor of P2TRv2 is that it saves a few dozen witness
>> bytes per input when using schnorr EC key spending, compared to P2MR
>> spending. For low-frequency use cases like cold storage, that doesnt matter
>> much. At current rates thats like 10 sats per input. For high frequency use
>> cases where every vbyte counts like hot wallets, exchanges, mining payouts,
>> etc, i have good news: P2TRv1 still exists and can be used just fine. You
>> "just" need to make sure the coins are moved to a PQ address before a
>> quantum computer attacks them. I'm assuming these high-frequency use case
>> actors are online enough to take that last step when necessary.
>>
>> Thus i see P2MR as the superior choice to P2TRv2 even if P2TRv2 may be
>> slightly more space efficient in the near-term. Thinking longer term, P2MR
>> is the better choice.
>>
>> Thinking even further into the future, we have options for a sort of
>> P2TR-style of address using isogenies, by hiding a commitment to a
>> taproot-style script tree inside a public key curve (public keys in isogeny
>> cryptosystems are represented by elliptic curves). Keypath spending would
>> be via SQIsign (or other schemes). So don't worry, we are not stuck with
>> only merkle trees forever. I'll elaborate more on this idea in a
>> forthcoming article i have cooking on isogenies.
>>
>>
>> > ZK proof-of-seedphrase
>>
>> If we were going to use a ZK proof to rescue quantum procrastinators, it
>> should be proof of BIP32 hardened key derivation, and possibly also proof
>> of pubkey hash preimage knowledge. This is strictly more general than a
>> zero-knowledge proof of seed phrase, the arithmetization would be wayyy
>> more efficient, and would recover more coins from more diverse wallet types.
>>
>> Also, there is no need for it to be a hefty zero-knowledge proof, like a
>> STARK. Rescue could be deployed using a commit and reveal protocol, as has
>> been discussed on the list previously (sorry, i dont have the link in front
>> of me right now). The idea is that a sender can rescue frozen UTXOs using a
>> commit/reveal sequence of transactions which ultimately proves the sender
>> knew a BIP32 parent xpriv (or pubkey hash preimage) which controls the
>> coins in question through hardened BIP32 CKD, which a CRQC shouldn't be
>> able to forge.
>>
>> This would maximize rescue coverage while minimizing blockspace
>> congestion, and could be done as a soft fork.
>>
>>
>> -----
>>
>> I'm glad to see thoughtful discussion on the subject of how to handle a
>> quantum freeze. But it is important to put this in perspective in the
>> context of this thread: right now the number one most important thing -
>> which we NEED to do if Bitcoin is to survive appearance of a CRQC - is to
>> provide a standardized wallet address format which includes a secure
>> fallback way to authenticate UTXOs if ECC is unsafe to use. We can debate
>> about freezing or rescuing coins, or the philosophy of ownership, but these
>> questions will not be decidable for years.
>>
>> What is decidable is this: how would you change Ethan's proposal, if at
>> all? I'll remind everyone that currently it is limited only to adding two
>> features: BIP360 P2MR addresses, and SLH-DSA opcodes. Those two changes are
>> all we need in consensus to finally give hodlers an option to migrate.
>>
>>
>> I've gone through and catalogued some of the feedback on Ethan's
>> proposal. So far I've heard these material critiques:
>>
>>
>> 1. Why not instead deploy covenant opcodes (TXHASH, CTV) and use them to
>> implement commit/reveal?
>>
>> As i mentioned in my last message i don't think that is possible, at
>> least not using the technique Erik linked. I'd be happy to be proven wrong
>> here because that'd be fantastic news if true.
>>
>>
>> 2. Why not use SHRINCS instead of SLH-DSA?
>>
>> Seems like a valid idea to me. SHRINCS would add implementation and UX
>> complexity but it'd also make the fallback sig scheme scalable - a very
>> nice property to have in the worst case scenario where a majority of users
>> end up needing to sign with it. Philosophically i dislike statefulness in a
>> cryptosystem, but maybe as a fallback it is an acceptable tradeoff.
>>
>>
>> 3. Why not deploy GSR and let wallet devs roll their own crypto?
>>
>> As ethan pointed out, this would be bad for standardization and
>> interoperability, and also requires GSR to be deployed as a pre-requisite.
>> If GSR is activated and in-script signing schemes are standardized
>> correctly, it could possibly be a suitable alternative to activating
>> dedicated SLH-DSA opcodes.
>>
>>
>> 4. Why not continue using P2TR and disable keypath spending later, rather
>> than adding a whole new address format?
>>
>> As ethan pointed out, this depends on timing a future disabling soft fork
>> correctly and will lead to FUD, avoidable debate, and confusion. It is also
>> confiscatory, as it would freeze standardized keypath-only P2TR outputs
>> which lack a script path.
>>
>>
>> 5. Why not redeploy P2TR with a new segwit version number, which opts
>> into a future keypath-disabling soft fork?
>>
>> Ethan and i have both made some compelling arguments as to why we should
>> give the community a new address format which is totally decoupled from any
>> PQ-vulnerable cryptography. If the increased fees of P2MR are an issue for
>> high-frequency hot wallets, P2TR is still viable, at least until Q-day. As
>> stated Ethan's proposal is more motivated by long term cold storage use
>> cases. I consider a small increase in witness size to be an acceptable
>> tradeoff for (speculative) quantum security, and the costs of clinging to
>> those savings in the near-term to be unacceptable. Key-path spending may be
>> reinvented in the future using other novel cryptosystems, with another new
>> address format that depends on new cryptographic assumptions.
>>
>> -----
>>
>> I apologize if i missed anyone's feedback notes in this summary. Please
>> correct me if i have!
>>
>> regards,
>> conduition
>>
>>
>> On Tuesday, February 17th, 2026 at 4:22 AM, 'conduition' via Bitcoin
>> Development Mailing List <bitco...@googlegroups.com> wrote:
>>
>> Hi list, just wanted to pipe in on the subject of commit/reveal using
>> OP_TXHASH. I don't think it is possible. The protocol link Erik posted (
>> https://delvingbitcoin.org/t/a-quantum-resistance-script-only-using-op-ctv-op-txhash-and-no-new-signatures/2168
>> ) seems to contradict itself. On one hand the author says phase zero
>> doesn't commit to final CTV templates E & T. However it also says T & E are
>> committed to via the P_anchor tapscript tree, which must be pinned by phase
>> 0. So unless I'm misunderstanding, this technique seems to require a priori
>> knowledge of template hashes T and E when creating the funding address and
>> UTXO in phase 0, so this would not be viable as a PQ fallback spending
>> path. Happy to be proven wrong.
>>
>> regards,
>> conduition
>>
>>
>>
>> On Wednesday, February 11th, 2026 at 1:06 AM, Erik Aronesty <
>> er...@q32.com> wrote:
>>
>>
>>>
>>> You'd still need BIP 360 P2MR (or P2TRD) since OP_TXHASH needs
>>> tapscript, and the only available tapscript supporting output type, P2TR,
>>> isn't quantum safe.
>>>
>>
>> false, covenant based multistep secret-reveal spending paths don't rely
>> on signatures at all
>>
>>>
>>> I'm going to assume:
>>> - you mean to use this commit-reveal for migrating between signature
>>> algorithms, not for everyday use,
>>>
>>
>> it can be used if "q day" happens. otherwise ignored.
>>
>>> - TXHASH is being used because you are waiting for the commitment to be
>>> confirmed on-chain rather than lifeboat's out-of-band commitment system
>>>
>>
>> it's used so you can commit to a spending constraint without committing
>> to the final "as yet to be determined" quantum-safe destination:
>> https://delvingbitcoin.org/t/a-quantum-resistance-script-only-using-op-ctv-op-txhash-and-no-new-signatures/2168
>>
>>> Once you post your commit-txn, but before it confirms, other parties can
>>> post competing commit-txns that double spend your output. If one of
>>> malicious transactions confirm, you must now wait for a timelock to expire
>>> and then try to post your transaction.
>>>
>>
>> agreed. they have to spend resources to attack your private key and the
>> only thing they can do is "grief" using a timing attack with the results,
>> rather than steal outright. a massive incentive difference.
>>
>>> They can block you again. Each time they burn some of you coins in fees.
>>> Miners get the fees, so they might be incentivized to do this. Thus, we
>>> must trust miners not to do this. Lifeboat doesn't have this issue since it
>>> uses out-of-band commitments, but out-of-band commitments have their own
>>> issues.
>>>
>>
>> each time you use the reset-path, they have to re-attack a new key. very
>> expensive just to grief a small amount of fees spread across all miners.
>> sounds like science-fiction levels of compute.
>>
>> plus.... TX_HASH is simple and generally useful and there is no guarantee
>> that q-day will even come
>>
>> --
>> 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/msgid/bitcoindev/CAJowKgL5okUA%3DDHSyUJfzdb6p_z5a6H_hN6NuhZo6R9ZYbJFUQ%40mail.gmail.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+...@googlegroups.com.
>> To view this discussion visit
>> https://groups.google.com/d/msgid/bitcoindev/ByJc1I7sSQAMLnAzSHPi8KSSscU0qakPM2YI0qC6VBBOwzmYtQEW5NY6d80eLUCf7fmKxbdFlSuxm4RCoT5rtKT68Khdi2xjwYIu4B5e6BQ%3D%40proton.me
>> .
>>
>>
>> --
>> 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/msgid/bitcoindev/GhzGKZ5zphDf7mFpC_PMD0Bn7-KIK14HXdCPLeB7HKvPBfDRVG8eUAlCKKLWcki6XDW0h0R1IQC5SS9B7jnMRS85GzOzcmCt9v5R3xoW4Js%3D%40proton.me
>> <https://groups.google.com/d/msgid/bitcoindev/GhzGKZ5zphDf7mFpC_PMD0Bn7-KIK14HXdCPLeB7HKvPBfDRVG8eUAlCKKLWcki6XDW0h0R1IQC5SS9B7jnMRS85GzOzcmCt9v5R3xoW4Js%3D%40proton.me?utm_medium=email&utm_source=footer>
>> .
>>
>
--
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/0b534992-146b-46bd-8865-56b7afda31adn%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 22209 bytes --]
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms
2026-02-17 7:39 ` 'conduition' via Bitcoin Development Mailing List
2026-02-19 14:35 ` Garlo Nicon
@ 2026-02-20 18:48 ` Erik Aronesty
2026-02-23 14:00 ` 'conduition' via Bitcoin Development Mailing List
1 sibling, 1 reply; 42+ messages in thread
From: Erik Aronesty @ 2026-02-20 18:48 UTC (permalink / raw)
To: conduition; +Cc: Ethan Heilman, Jonas Nick, bitcoindev
[-- Attachment #1: Type: text/plain, Size: 12745 bytes --]
Covenant backed multistep secret-reveal schemes are inherently quantum
resistant (as long as we eliminate the mandatory nums-spend-path with a
small optional tr version addition)
It's clearly too soon to pick a signature scheme for quantum. Kyber is
probably the most broadly accepted scheme, but nobody uses it without a
hybrid approach, and it doesn't trivially support schemes like xpub key
derivation.
But it's NOT too soon to add covenants, which can give people peace-of-mind
quantum-safe vaults without needing to trust new quantum sigs.
On Mon, Feb 16, 2026 at 11:39 PM conduition <conduition@proton.me> wrote:
> > I just don't see a reason to do P2MR over just utilizing P2TR (or maybe
> P2TRv2).
> >
> > P2MR will *also* require an equivalent P2MR-disable-soft-fork
>
>
>
> P2TRv2 means locking wallets into using elliptic curve code for as long as
> P2TRv2 exists, because you will always have to compute and verify the
> tweaked output pubkey. Future PQ Bitcoin wallet devs will see secp256k1 as
> we today see broken primitives like md5 or DES. Future devs shouldn't have
> to add legacy cruft EC libraries into their codebases when it's not even
> usable for cryptography anymore.
>
> Even if you assume a second P2MR-disable-soft-fork will be needed (which
> is debatable), then it still pays to remove the inefficient and unnecessary
> cruft of EC crypto for the foreseeable post-quantum future. You might think
> of it as decoupling UTXO ownership from any specific public-key
> cryptosystem.
>
> Furthermore, if EC/keypath spending is disabled, P2MR actually requires
> less witness space per input than P2TRv2 because we dont need the
> now-useless internal key in a P2MR script spend witness, whereas P2TRv2
> will require it indefinitely until we can migrate to another new address
> format in the distant future. See
> https://github.com/bitcoin/bips/blob/master/bip-0360.mediawiki#comparison-with-p2tr-script-path-spend
>
> P2MR is strictly more secure since it depends on weaker assumptions.
> P2TRv2 is more complex for wallets to implement than P2MR, unless you count
> code reuse from P2TRv1. P2TRv2 is (marginally) computationally slower, and
> less block-space-efficient for script path spends. So who would choose
> P2TRv2 over P2MR?
>
> The only redeeming factor of P2TRv2 is that it saves a few dozen witness
> bytes per input when using schnorr EC key spending, compared to P2MR
> spending. For low-frequency use cases like cold storage, that doesnt matter
> much. At current rates thats like 10 sats per input. For high frequency use
> cases where every vbyte counts like hot wallets, exchanges, mining payouts,
> etc, i have good news: P2TRv1 still exists and can be used just fine. You
> "just" need to make sure the coins are moved to a PQ address before a
> quantum computer attacks them. I'm assuming these high-frequency use case
> actors are online enough to take that last step when necessary.
>
> Thus i see P2MR as the superior choice to P2TRv2 even if P2TRv2 may be
> slightly more space efficient in the near-term. Thinking longer term, P2MR
> is the better choice.
>
> Thinking even further into the future, we have options for a sort of
> P2TR-style of address using isogenies, by hiding a commitment to a
> taproot-style script tree inside a public key curve (public keys in isogeny
> cryptosystems are represented by elliptic curves). Keypath spending would
> be via SQIsign (or other schemes). So don't worry, we are not stuck with
> only merkle trees forever. I'll elaborate more on this idea in a
> forthcoming article i have cooking on isogenies.
>
>
> > ZK proof-of-seedphrase
>
> If we were going to use a ZK proof to rescue quantum procrastinators, it
> should be proof of BIP32 hardened key derivation, and possibly also proof
> of pubkey hash preimage knowledge. This is strictly more general than a
> zero-knowledge proof of seed phrase, the arithmetization would be wayyy
> more efficient, and would recover more coins from more diverse wallet types.
>
> Also, there is no need for it to be a hefty zero-knowledge proof, like a
> STARK. Rescue could be deployed using a commit and reveal protocol, as has
> been discussed on the list previously (sorry, i dont have the link in front
> of me right now). The idea is that a sender can rescue frozen UTXOs using a
> commit/reveal sequence of transactions which ultimately proves the sender
> knew a BIP32 parent xpriv (or pubkey hash preimage) which controls the
> coins in question through hardened BIP32 CKD, which a CRQC shouldn't be
> able to forge.
>
> This would maximize rescue coverage while minimizing blockspace
> congestion, and could be done as a soft fork.
>
>
> -----
>
> I'm glad to see thoughtful discussion on the subject of how to handle a
> quantum freeze. But it is important to put this in perspective in the
> context of this thread: right now the number one most important thing -
> which we NEED to do if Bitcoin is to survive appearance of a CRQC - is to
> provide a standardized wallet address format which includes a secure
> fallback way to authenticate UTXOs if ECC is unsafe to use. We can debate
> about freezing or rescuing coins, or the philosophy of ownership, but these
> questions will not be decidable for years.
>
> What is decidable is this: how would you change Ethan's proposal, if at
> all? I'll remind everyone that currently it is limited only to adding two
> features: BIP360 P2MR addresses, and SLH-DSA opcodes. Those two changes are
> all we need in consensus to finally give hodlers an option to migrate.
>
>
> I've gone through and catalogued some of the feedback on Ethan's proposal.
> So far I've heard these material critiques:
>
>
> 1. Why not instead deploy covenant opcodes (TXHASH, CTV) and use them to
> implement commit/reveal?
>
> As i mentioned in my last message i don't think that is possible, at least
> not using the technique Erik linked. I'd be happy to be proven wrong here
> because that'd be fantastic news if true.
>
>
> 2. Why not use SHRINCS instead of SLH-DSA?
>
> Seems like a valid idea to me. SHRINCS would add implementation and UX
> complexity but it'd also make the fallback sig scheme scalable - a very
> nice property to have in the worst case scenario where a majority of users
> end up needing to sign with it. Philosophically i dislike statefulness in a
> cryptosystem, but maybe as a fallback it is an acceptable tradeoff.
>
>
> 3. Why not deploy GSR and let wallet devs roll their own crypto?
>
> As ethan pointed out, this would be bad for standardization and
> interoperability, and also requires GSR to be deployed as a pre-requisite.
> If GSR is activated and in-script signing schemes are standardized
> correctly, it could possibly be a suitable alternative to activating
> dedicated SLH-DSA opcodes.
>
>
> 4. Why not continue using P2TR and disable keypath spending later, rather
> than adding a whole new address format?
>
> As ethan pointed out, this depends on timing a future disabling soft fork
> correctly and will lead to FUD, avoidable debate, and confusion. It is also
> confiscatory, as it would freeze standardized keypath-only P2TR outputs
> which lack a script path.
>
>
> 5. Why not redeploy P2TR with a new segwit version number, which opts into
> a future keypath-disabling soft fork?
>
> Ethan and i have both made some compelling arguments as to why we should
> give the community a new address format which is totally decoupled from any
> PQ-vulnerable cryptography. If the increased fees of P2MR are an issue for
> high-frequency hot wallets, P2TR is still viable, at least until Q-day. As
> stated Ethan's proposal is more motivated by long term cold storage use
> cases. I consider a small increase in witness size to be an acceptable
> tradeoff for (speculative) quantum security, and the costs of clinging to
> those savings in the near-term to be unacceptable. Key-path spending may be
> reinvented in the future using other novel cryptosystems, with another new
> address format that depends on new cryptographic assumptions.
>
> -----
>
> I apologize if i missed anyone's feedback notes in this summary. Please
> correct me if i have!
>
> regards,
> conduition
>
>
> On Tuesday, February 17th, 2026 at 4:22 AM, 'conduition' via Bitcoin
> Development Mailing List <bitcoindev@googlegroups.com> wrote:
>
> Hi list, just wanted to pipe in on the subject of commit/reveal using
> OP_TXHASH. I don't think it is possible. The protocol link Erik posted (
> https://delvingbitcoin.org/t/a-quantum-resistance-script-only-using-op-ctv-op-txhash-and-no-new-signatures/2168
> ) seems to contradict itself. On one hand the author says phase zero
> doesn't commit to final CTV templates E & T. However it also says T & E are
> committed to via the P_anchor tapscript tree, which must be pinned by phase
> 0. So unless I'm misunderstanding, this technique seems to require a priori
> knowledge of template hashes T and E when creating the funding address and
> UTXO in phase 0, so this would not be viable as a PQ fallback spending
> path. Happy to be proven wrong.
>
> regards,
> conduition
>
>
>
> On Wednesday, February 11th, 2026 at 1:06 AM, Erik Aronesty <erik@q32.com>
> wrote:
>
>
>>
>> You'd still need BIP 360 P2MR (or P2TRD) since OP_TXHASH needs tapscript,
>> and the only available tapscript supporting output type, P2TR, isn't
>> quantum safe.
>>
>
> false, covenant based multistep secret-reveal spending paths don't rely on
> signatures at all
>
>>
>> I'm going to assume:
>> - you mean to use this commit-reveal for migrating between signature
>> algorithms, not for everyday use,
>>
>
> it can be used if "q day" happens. otherwise ignored.
>
>> - TXHASH is being used because you are waiting for the commitment to be
>> confirmed on-chain rather than lifeboat's out-of-band commitment system
>>
>
> it's used so you can commit to a spending constraint without committing to
> the final "as yet to be determined" quantum-safe destination:
> https://delvingbitcoin.org/t/a-quantum-resistance-script-only-using-op-ctv-op-txhash-and-no-new-signatures/2168
>
>> Once you post your commit-txn, but before it confirms, other parties can
>> post competing commit-txns that double spend your output. If one of
>> malicious transactions confirm, you must now wait for a timelock to expire
>> and then try to post your transaction.
>>
>
> agreed. they have to spend resources to attack your private key and the
> only thing they can do is "grief" using a timing attack with the results,
> rather than steal outright. a massive incentive difference.
>
>> They can block you again. Each time they burn some of you coins in fees.
>> Miners get the fees, so they might be incentivized to do this. Thus, we
>> must trust miners not to do this. Lifeboat doesn't have this issue since it
>> uses out-of-band commitments, but out-of-band commitments have their own
>> issues.
>>
>
> each time you use the reset-path, they have to re-attack a new key. very
> expensive just to grief a small amount of fees spread across all miners.
> sounds like science-fiction levels of compute.
>
> plus.... TX_HASH is simple and generally useful and there is no guarantee
> that q-day will even come
>
> --
> 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/CAJowKgL5okUA%3DDHSyUJfzdb6p_z5a6H_hN6NuhZo6R9ZYbJFUQ%40mail.gmail.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/ByJc1I7sSQAMLnAzSHPi8KSSscU0qakPM2YI0qC6VBBOwzmYtQEW5NY6d80eLUCf7fmKxbdFlSuxm4RCoT5rtKT68Khdi2xjwYIu4B5e6BQ%3D%40proton.me
> .
>
>
>
--
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/CAJowKgL-hAxkb2uVTdHE%3Duo6%2BkRq1TEhabF_LNawE9K3j8_ivQ%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 18916 bytes --]
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms
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
0 siblings, 1 reply; 42+ messages in thread
From: 'conduition' via Bitcoin Development Mailing List @ 2026-02-23 14:00 UTC (permalink / raw)
To: Erik Aronesty, garlonicon; +Cc: Ethan Heilman, Jonas Nick, bitcoindev
[-- Attachment #1.1.1: Type: text/plain, Size: 16365 bytes --]
For Garlo:
> So, if we talk about disabling obsolete cryptography, then when OP_SHA1 will be disabled?
We are not talking about disabling obsolete cryptography. We are talking about adding new address formats to Bitcoin, with an eye specifically on resisting breaks in the ECDLP (such as by a CRQC). I hope you can see why enabling a new address format is a totally different proposition than your examples.
> Well, to fully break OP_CHECKSIG, you need to break both secp256k1 and SHA-256.
This is not about OP_CHECKSIG or its future in script. See previous paragraph.
For Erik:
> Covenant backed multistep secret-reveal schemes are inherently quantum resistant (as long as we eliminate the mandatory nums-spend-path with a small optional tr version addition)
I'd be excited to learn about this as an option. Erik, could you please answer my previous questions about the viability of your linked protocol? I'm not questioning its quantum-resistance properties (yet). I'm wondering how it is possible to instantiate this scheme in a way that allows a wallet to actually use this commit/reveal scheme without knowing the final destination CTV templates (denoted T & E in the delving post) in advance of creating the phase 0 locking script.
Quoting myself:
> On one hand the author says phase zero doesn't commit to final CTV templates E & T. However it also says T & E are committed to via the P_anchor tapscript tree, which must be pinned by phase 0. So unless I'm misunderstanding, this technique seems to require a priori knowledge of template hashes T and E when creating the funding address and UTXO in phase 0, so this would not be viable as a PQ fallback spending path. Happy to be proven wrong.
If this is indeed possible i would be super joyed to see it. I just don't understand how it would be, based on my limited knowledge of TXHASH and CTV.
> It's clearly too soon to pick a signature scheme for quantum.
Notwithstanding any forthcoming answers to my previous questions on covenant-based commit/reveal, i agree partially. Yes, it is too early to risk adding a new cutting edge cryptosystem that relies on novel assumptions, like closest-vector, or isogeny-path problems. There is much progress still to be made in attacking these schemes, and in improving their performance and flexibility.
But in the case of hash-based signature (HBS) schemes, i disagree. HBS is already mature. Whatever cryptanalytic breakthroughs the future holds, we can be reasonably sure that SHA256 preimage resistance will hold for a long time, so HBS security will hold. Even today md4 and md5 preimage resistance still holds. Securing coins using hashes alone is the ideal fallback, and even if HBS is not the most efficient class of schemes, that doesn't matter so much if we don't use HBS as our primary everyday signature scheme. Its value lies in security, not efficiency.
Once an efficient PQ scheme is mature, we can use that to someday replace ECDLP, and rely on HBS as a fallback once again.
If you're worried about stuff like how xpubs would work with HBS, we have solutions for that too, and they are mostly drop-in replacements for existing standards.
regards
conduitionOn Friday, February 20th, 2026 at 6:48 PM, Erik Aronesty <erik@q32.com> wrote:
> Covenant backed multistep secret-reveal schemes are inherently quantum resistant (as long as we eliminate the mandatory nums-spend-path with a small optional tr version addition)
>
>
> It's clearly too soon to pick a signature scheme for quantum. Kyber is probably the most broadly accepted scheme, but nobody uses it without a hybrid approach, and it doesn't trivially support schemes like xpub key derivation.
>
> But it's NOT too soon to add covenants, which can give people peace-of-mind quantum-safe vaults without needing to trust new quantum sigs.
>
> On Mon, Feb 16, 2026 at 11:39 PM conduition <conduition@proton.me> wrote:
>
> > > I just don't see a reason to do P2MR over just utilizing P2TR (or maybeP2TRv2).
> > >
> > > P2MR will *also* require an equivalent P2MR-disable-soft-fork
> >
> >
> >
> > P2TRv2 means locking wallets into using elliptic curve code for as long as P2TRv2 exists, because you will always have to compute and verify the tweaked output pubkey. Future PQ Bitcoin wallet devs will see secp256k1 as we today see broken primitives like md5 or DES. Future devs shouldn't have to add legacy cruft EC libraries into their codebases when it's not even usable for cryptography anymore.
> >
> > Even if you assume a second P2MR-disable-soft-fork will be needed (which is debatable), then it still pays to remove the inefficient and unnecessary cruft of EC crypto for the foreseeable post-quantum future. You might think of it as decoupling UTXO ownership from any specific public-key cryptosystem.
> >
> > Furthermore, if EC/keypath spending is disabled, P2MR actually requires less witness space per input than P2TRv2 because we dont need the now-useless internal key in a P2MR script spend witness, whereas P2TRv2 will require it indefinitely until we can migrate to another new address format in the distant future. See https://github.com/bitcoin/bips/blob/master/bip-0360.mediawiki#comparison-with-p2tr-script-path-spend
> >
> > P2MR is strictly more secure since it depends on weaker assumptions. P2TRv2 is more complex for wallets to implement than P2MR, unless you count code reuse from P2TRv1. P2TRv2 is (marginally) computationally slower, and less block-space-efficient for script path spends. So who would choose P2TRv2 over P2MR?
> >
> > The only redeeming factor of P2TRv2 is that it saves a few dozen witness bytes per input when using schnorr EC key spending, compared to P2MR spending. For low-frequency use cases like cold storage, that doesnt matter much. At current rates thats like 10 sats per input. For high frequency use cases where every vbyte counts like hot wallets, exchanges, mining payouts, etc, i have good news: P2TRv1 still exists and can be used just fine. You "just" need to make sure the coins are moved to a PQ address before a quantum computer attacks them. I'm assuming these high-frequency use case actors are online enough to take that last step when necessary.
> >
> > Thus i see P2MR as the superior choice to P2TRv2 even if P2TRv2 may be slightly more space efficient in the near-term. Thinking longer term, P2MR is the better choice.
> >
> > Thinking even further into the future, we have options for a sort of P2TR-style of address using isogenies, by hiding a commitment to a taproot-style script tree inside a public key curve (public keys in isogeny cryptosystems are represented by elliptic curves). Keypath spending would be via SQIsign (or other schemes). So don't worry, we are not stuck with only merkle trees forever. I'll elaborate more on this idea in a forthcoming article i have cooking on isogenies.
> >
> >
> > > ZK proof-of-seedphrase
> >
> > If we were going to use a ZK proof to rescue quantum procrastinators, it should be proof of BIP32 hardened key derivation, and possibly also proof of pubkey hash preimage knowledge. This is strictly more general than a zero-knowledge proof of seed phrase, the arithmetization would be wayyy more efficient, and would recover more coins from more diverse wallet types.
> >
> > Also, there is no need for it to be a hefty zero-knowledge proof, like a STARK. Rescue could be deployed using a commit and reveal protocol, as has been discussed on the list previously (sorry, i dont have the link in front of me right now). The idea is that a sender can rescue frozen UTXOs using a commit/reveal sequence of transactions which ultimately proves the sender knew a BIP32 parent xpriv (or pubkey hash preimage) which controls the coins in question through hardened BIP32 CKD, which a CRQC shouldn't be able to forge.
> >
> > This would maximize rescue coverage while minimizing blockspace congestion, and could be done as a soft fork.
> >
> >
> > -----
> >
> > I'm glad to see thoughtful discussion on the subject of how to handle a quantum freeze. But it is important to put this in perspective in the context of this thread: right now the number one most important thing - which we NEED to do if Bitcoin is to survive appearance of a CRQC - is to provide a standardized wallet address format which includes a secure fallback way to authenticate UTXOs if ECC is unsafe to use. We can debate about freezing or rescuing coins, or the philosophy of ownership, but these questions will not be decidable for years.
> >
> > What is decidable is this: how would you change Ethan's proposal, if at all? I'll remind everyone that currently it is limited only to adding two features: BIP360 P2MR addresses, and SLH-DSA opcodes. Those two changes are all we need in consensus to finally give hodlers an option to migrate.
> >
> >
> > I've gone through and catalogued some of the feedback on Ethan's proposal. So far I've heard these material critiques:
> >
> >
> > 1. Why not instead deploy covenant opcodes (TXHASH, CTV) and use them to implement commit/reveal?
> >
> > As i mentioned in my last message i don't think that is possible, at least not using the technique Erik linked. I'd be happy to be proven wrong here because that'd be fantastic news if true.
> >
> >
> > 2. Why not use SHRINCS instead of SLH-DSA?
> >
> > Seems like a valid idea to me. SHRINCS would add implementation and UX complexity but it'd also make the fallback sig scheme scalable - a very nice property to have in the worst case scenario where a majority of users end up needing to sign with it. Philosophically i dislike statefulness in a cryptosystem, but maybe as a fallback it is an acceptable tradeoff.
> >
> >
> > 3. Why not deploy GSR and let wallet devs roll their own crypto?
> >
> > As ethan pointed out, this would be bad for standardization and interoperability, and also requires GSR to be deployed as a pre-requisite. If GSR is activated and in-script signing schemes are standardized correctly, it could possibly be a suitable alternative to activating dedicated SLH-DSA opcodes.
> >
> >
> > 4. Why not continue using P2TR and disable keypath spending later, rather than adding a whole new address format?
> >
> > As ethan pointed out, this depends on timing a future disabling soft fork correctly and will lead to FUD, avoidable debate, and confusion. It is also confiscatory, as it would freeze standardized keypath-only P2TR outputs which lack a script path.
> >
> >
> > 5. Why not redeploy P2TR with a new segwit version number, which opts into a future keypath-disabling soft fork?
> >
> > Ethan and i have both made some compelling arguments as to why we should give the community a new address format which is totally decoupled from any PQ-vulnerable cryptography. If the increased fees of P2MR are an issue for high-frequency hot wallets, P2TR is still viable, at least until Q-day. As stated Ethan's proposal is more motivated by long term cold storage use cases. I consider a small increase in witness size to be an acceptable tradeoff for (speculative) quantum security, and the costs of clinging to those savings in the near-term to be unacceptable. Key-path spending may be reinvented in the future using other novel cryptosystems, with another new address format that depends on new cryptographic assumptions.
> >
> > -----
> >
> > I apologize if i missed anyone's feedback notes in this summary. Please correct me if i have!
> >
> > regards,
> > conduition
> >
> >
> > On Tuesday, February 17th, 2026 at 4:22 AM, 'conduition' via Bitcoin Development Mailing List <bitcoindev@googlegroups.com> wrote:
> >
> > > Hi list, just wanted to pipe in on the subject of commit/reveal using OP_TXHASH. I don't think it is possible. The protocol link Erik posted ( https://delvingbitcoin.org/t/a-quantum-resistance-script-only-using-op-ctv-op-txhash-and-no-new-signatures/2168 ) seems to contradict itself. On one hand the author says phase zero doesn't commit to final CTV templates E & T. However it also says T & E are committed to via the P_anchor tapscript tree, which must be pinned by phase 0. So unless I'm misunderstanding, this technique seems to require a priori knowledge of template hashes T and E when creating the funding address and UTXO in phase 0, so this would not be viable as a PQ fallback spending path. Happy to be proven wrong.
> > >
> > > regards,
> > > conduition
> > >
> > >
> > >
> > > On Wednesday, February 11th, 2026 at 1:06 AM, Erik Aronesty <erik@q32.com> wrote:
> > >
> > > > >
> > > > >
> > > > > You'd still need BIP 360 P2MR (or P2TRD) since OP_TXHASH needs tapscript, and the only available tapscript supporting output type, P2TR, isn't quantum safe.
> > > >
> > > >
> > > > false, covenant based multistep secret-reveal spending paths don't rely on signatures at all
> > > >
> > > > >
> > > > > I'm going to assume:
> > > > > - you mean to use this commit-reveal for migrating between signature algorithms, not for everyday use,
> > > >
> > > >
> > > > it can be used if "q day" happens. otherwise ignored.
> > > >
> > > > > - TXHASH is being used because you are waiting for the commitment to be confirmed on-chain rather than lifeboat's out-of-band commitment system
> > > >
> > > >
> > > > it's used so you can commit to a spending constraint without committing to the final "as yet to be determined" quantum-safe destination: https://delvingbitcoin.org/t/a-quantum-resistance-script-only-using-op-ctv-op-txhash-and-no-new-signatures/2168
> > > >
> > > > > Once you post your commit-txn, but before it confirms, other parties can post competing commit-txns that double spend your output. If one of malicious transactions confirm, you must now wait for a timelock to expire and then try to post your transaction.
> > > >
> > > >
> > > > agreed. they have to spend resources to attack your private key and the only thing they can do is "grief" using a timing attack with the results, rather than steal outright. a massive incentive difference.
> > > >
> > > > > They can block you again. Each time they burn some of you coins in fees. Miners get the fees, so they might be incentivized to do this. Thus, we must trust miners not to do this. Lifeboat doesn't have this issue since it uses out-of-band commitments, but out-of-band commitments have their own issues.
> > > >
> > > >
> > > > each time you use the reset-path, they have to re-attack a new key. very expensive just to grief a small amount of fees spread across all miners. sounds like science-fiction levels of compute.
> > > >
> > > > plus.... TX_HASH is simple and generally useful and there is no guarantee that q-day will even come
> > > >
> > > > --
> > > > 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/CAJowKgL5okUA%3DDHSyUJfzdb6p_z5a6H_hN6NuhZo6R9ZYbJFUQ%40mail.gmail.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/ByJc1I7sSQAMLnAzSHPi8KSSscU0qakPM2YI0qC6VBBOwzmYtQEW5NY6d80eLUCf7fmKxbdFlSuxm4RCoT5rtKT68Khdi2xjwYIu4B5e6BQ%3D%40proton.me.
--
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/WCU43Srj6CNeiFvY13jPrHlceJeD6SeKoTWmsHwgebvImqPDO1IEZ6N-0qlm_ialjt0_fAGnAuBB62c0gMfM1QGJAKQJjFZ0bJ0NjNepiY0%3D%40proton.me.
[-- Attachment #1.1.2.1: Type: text/html, Size: 23774 bytes --]
[-- 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 --]
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms
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-27 19:31 ` 'conduition' via Bitcoin Development Mailing List
0 siblings, 2 replies; 42+ messages in thread
From: Erik Aronesty @ 2026-02-23 19:08 UTC (permalink / raw)
To: conduition; +Cc: garlonicon, Ethan Heilman, Jonas Nick, bitcoindev
[-- Attachment #1: Type: text/plain, Size: 3016 bytes --]
>
>
>
> I'd be excited to learn about this as an option. Erik, could you please
> answer my previous questions about the viability of your linked protocol?
> I'm not questioning its quantum-resistance properties (yet). I'm wondering
> how it is possible to instantiate this scheme in a way that allows a wallet
> to actually use this commit/reveal scheme without knowing the final
> destination CTV templates (denoted T & E in the delving post) in advance of
> creating the phase 0 locking script.
>
I provided an example script that shows how it works:
https://gist.github.com/earonesty/ea086aa995be1a860af093f93bd45bf2. you
don't pin to the final destination in phase 0.
txhash is a partial-commitment, not over all fields. this give the
flexibility needed for the final spend, since you don't commit to it.
however someone has pointed out a fee-problem that CCV's value-aware
composability can solve. coming around to thinking the ccv-based
construction would be necessary. CCV is more powerful but requires much
more care in policy and analysis. CTV is trivial, we could merge it
tomorrow and hardly worry about surface area issues. TXHASH is only
slightly more complicated. CCV has a much bigger burden of proof around
implementation and node safety... but i think you could do many kinds of
vaulting schemes with it alone.
But in the case of hash-based signature (HBS) schemes, i disagree. HBS is
> already mature. Whatever cryptanalytic breakthroughs the future holds, we
> can be reasonably sure that SHA256 preimage resistance will hold for a long
> time, so HBS security will hold. Even today md4 and md5 preimage resistance
> still holds. Securing coins using hashes alone is the ideal fallback, and
> even if HBS is not the most efficient class of schemes, that doesn't matter
> so much if we don't use HBS as our primary everyday signature scheme. Its
> value lies in security, not efficiency.
>
When I mean "too soon", I'm including SPHINCS, not sure what
1. Earlier versions of the SPHINCS framework were found to be susceptible
to fault attacks
2. Earlier "Tight" proof for v1 SPHINCS was flawed, leading to 60 bits of
security, not 128
> If you're worried about stuff like how xpubs would work with HBS, we have
solutions for that too, and they are mostly drop-in replacements for
existing standards.
I thought "tweaking", in general, is lost in SPHINCS, as well as multiparty
sigs. Be interested to see those solutions. But, regardless, 17kb sigs
are... not compatible with a decentralized bitcoin, imo. Lattice-sigs are
the only reasonable PQ way forward and they aren't ready yet.
--
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/CAJowKgL%2BYMWSgEPcVF-u8bNvPFK35cY-3cHtimWD2mtXdDhUzQ%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 4215 bytes --]
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms
2026-02-23 19:08 ` Erik Aronesty
@ 2026-02-23 21:42 ` Ethan Heilman
2026-02-24 0:12 ` Alex
2026-02-26 15:51 ` Matt Corallo
2026-02-27 19:31 ` 'conduition' via Bitcoin Development Mailing List
1 sibling, 2 replies; 42+ messages in thread
From: Ethan Heilman @ 2026-02-23 21:42 UTC (permalink / raw)
To: Erik Aronesty; +Cc: conduition, garlonicon, Jonas Nick, bitcoindev
[-- Attachment #1: Type: text/plain, Size: 4646 bytes --]
> I thought "tweaking", in general, is lost in SPHINCS, as well as
multiparty sigs. Be interested to see those solutions. But, regardless,
17kb sigs are... not compatible with a decentralized bitcoin, imo.
Lattice-sigs are the only reasonable PQ way forward and they aren't ready
yet.
SPHINCS is ~8kb (7,888 bytes) not 17kb.
SPHINCS SLH-DSA-128s has 32 byte public keys and 7,856 byte signatures
Total size of 7,888 bytes not 17kb.
The Lattice sigs aren't that much better than SPHINCS
CRYSTALS-Dilithium ML-DSA has 1,312 byte public keys and 2,420 byte
signatures
Total size of 3,732 bytes.
Falcon has 897 byte public keys and 666 signatures
1,563 bytes
ML-DSA currently has the most support in the Lattice world, but it is still
too large to be a drop in replacement for ECC without a witness discount.
If we had to choose tomorrow, I'd advocate for ML-DSA with a massive
witness discount, but I'd be very unhappy with the witness discount. If the
witness discount was out of the question, then I'd advocate for something
similar to 324-byte stateful hash based SHRINCS signature. Neither is ideal.
My current thinking is to use SLH-DSA as a backup. This keeps us safe if
everything goes wrong and allows us to reach safety early so we can take
time to determine the right drop-in replacement for ECC. Hopefully in 3
years, SQI-sign is fast enough to be considered.
On Mon, Feb 23, 2026 at 2:08 PM Erik Aronesty <erik@q32.com> wrote:
>
>>
>> I'd be excited to learn about this as an option. Erik, could you please
>> answer my previous questions about the viability of your linked protocol?
>> I'm not questioning its quantum-resistance properties (yet). I'm wondering
>> how it is possible to instantiate this scheme in a way that allows a wallet
>> to actually use this commit/reveal scheme without knowing the final
>> destination CTV templates (denoted T & E in the delving post) in advance of
>> creating the phase 0 locking script.
>>
>
> I provided an example script that shows how it works:
> https://gist.github.com/earonesty/ea086aa995be1a860af093f93bd45bf2. you
> don't pin to the final destination in phase 0.
>
> txhash is a partial-commitment, not over all fields. this give the
> flexibility needed for the final spend, since you don't commit to it.
>
> however someone has pointed out a fee-problem that CCV's value-aware
> composability can solve. coming around to thinking the ccv-based
> construction would be necessary. CCV is more powerful but requires much
> more care in policy and analysis. CTV is trivial, we could merge it
> tomorrow and hardly worry about surface area issues. TXHASH is only
> slightly more complicated. CCV has a much bigger burden of proof around
> implementation and node safety... but i think you could do many kinds of
> vaulting schemes with it alone.
>
>
> But in the case of hash-based signature (HBS) schemes, i disagree. HBS is
>> already mature. Whatever cryptanalytic breakthroughs the future holds, we
>> can be reasonably sure that SHA256 preimage resistance will hold for a long
>> time, so HBS security will hold. Even today md4 and md5 preimage resistance
>> still holds. Securing coins using hashes alone is the ideal fallback, and
>> even if HBS is not the most efficient class of schemes, that doesn't matter
>> so much if we don't use HBS as our primary everyday signature scheme. Its
>> value lies in security, not efficiency.
>>
>
> When I mean "too soon", I'm including SPHINCS, not sure what
>
> 1. Earlier versions of the SPHINCS framework were found to be susceptible
> to fault attacks
> 2. Earlier "Tight" proof for v1 SPHINCS was flawed, leading to 60 bits of
> security, not 128
>
> > If you're worried about stuff like how xpubs would work with HBS, we
> have solutions for that too, and they are mostly drop-in replacements for
> existing standards.
>
> I thought "tweaking", in general, is lost in SPHINCS, as well as
> multiparty sigs. Be interested to see those solutions. But, regardless,
> 17kb sigs are... not compatible with a decentralized bitcoin, imo.
> Lattice-sigs are the only reasonable PQ way forward and they aren't ready
> yet.
>
--
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%2BWAR3YXmdrrT-zN210ob53dmYC1KZwBZ%3DOK2bKgNeAHUg%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 6051 bytes --]
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms
2026-02-23 21:42 ` Ethan Heilman
@ 2026-02-24 0:12 ` Alex
2026-02-25 10:43 ` Javier Mateos
2026-02-26 15:51 ` Matt Corallo
1 sibling, 1 reply; 42+ messages in thread
From: Alex @ 2026-02-24 0:12 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 5908 bytes --]
You don't need "the perfect signature" on day 1, you just need something
everyone can agree on is good enough as a migration step. SLH-DSA can
indeed fill that role - it means a transaction will cost about 10x more
than now.
Whether SLH-DSA or ML-DSA is picked is IMO less important because
eventually "the perfect signature" will be ready: https://sqisign.org/
SQIsign is 65 + 148 bytes and my DDR3 era Haswell PC (from 2014) can verify
1000 sigs per second using the non-optimized reference implementation. A
modern budget CPU can do 30k verifications per second.
You only need SLH-DSA as an (optional) signature that maybe is never even
used at all. It's just an insurance. When I hear people say "we don't need
this we can just make a ZK proof of the seed phrase" - I'm pretty sure such
a ZK proof is much larger than SLH-DSA anyways and would require a total
halt of the Bitcoin network and be way less efficient. With SLH-DSA you
would get that migration done seamlessly and more efficient anyways.
måndag 23 februari 2026 kl. 23:03:03 UTC+1 skrev Ethan Heilman:
> > I thought "tweaking", in general, is lost in SPHINCS, as well as
> multiparty sigs. Be interested to see those solutions. But, regardless,
> 17kb sigs are... not compatible with a decentralized bitcoin, imo.
> Lattice-sigs are the only reasonable PQ way forward and they aren't ready
> yet.
>
> SPHINCS is ~8kb (7,888 bytes) not 17kb.
>
> SPHINCS SLH-DSA-128s has 32 byte public keys and 7,856 byte signatures
> Total size of 7,888 bytes not 17kb.
>
> The Lattice sigs aren't that much better than SPHINCS
>
> CRYSTALS-Dilithium ML-DSA has 1,312 byte public keys and 2,420 byte
> signatures
> Total size of 3,732 bytes.
>
> Falcon has 897 byte public keys and 666 signatures
> 1,563 bytes
>
> ML-DSA currently has the most support in the Lattice world, but it is
> still too large to be a drop in replacement for ECC without a witness
> discount. If we had to choose tomorrow, I'd advocate for ML-DSA with a
> massive witness discount, but I'd be very unhappy with the witness
> discount. If the witness discount was out of the question, then I'd
> advocate for something similar to 324-byte stateful hash based SHRINCS
> signature. Neither is ideal.
>
> My current thinking is to use SLH-DSA as a backup. This keeps us safe if
> everything goes wrong and allows us to reach safety early so we can take
> time to determine the right drop-in replacement for ECC. Hopefully in 3
> years, SQI-sign is fast enough to be considered.
>
> On Mon, Feb 23, 2026 at 2:08 PM Erik Aronesty <er...@q32.com> wrote:
>
>>
>>>
>>> I'd be excited to learn about this as an option. Erik, could you please
>>> answer my previous questions about the viability of your linked protocol?
>>> I'm not questioning its quantum-resistance properties (yet). I'm wondering
>>> how it is possible to instantiate this scheme in a way that allows a wallet
>>> to actually use this commit/reveal scheme without knowing the final
>>> destination CTV templates (denoted T & E in the delving post) in advance of
>>> creating the phase 0 locking script.
>>>
>>
>> I provided an example script that shows how it works:
>> https://gist.github.com/earonesty/ea086aa995be1a860af093f93bd45bf2. you
>> don't pin to the final destination in phase 0.
>>
>> txhash is a partial-commitment, not over all fields. this give the
>> flexibility needed for the final spend, since you don't commit to it.
>>
>> however someone has pointed out a fee-problem that CCV's value-aware
>> composability can solve. coming around to thinking the ccv-based
>> construction would be necessary. CCV is more powerful but requires much
>> more care in policy and analysis. CTV is trivial, we could merge it
>> tomorrow and hardly worry about surface area issues. TXHASH is only
>> slightly more complicated. CCV has a much bigger burden of proof around
>> implementation and node safety... but i think you could do many kinds of
>> vaulting schemes with it alone.
>>
>>
>> But in the case of hash-based signature (HBS) schemes, i disagree. HBS is
>>> already mature. Whatever cryptanalytic breakthroughs the future holds, we
>>> can be reasonably sure that SHA256 preimage resistance will hold for a long
>>> time, so HBS security will hold. Even today md4 and md5 preimage resistance
>>> still holds. Securing coins using hashes alone is the ideal fallback, and
>>> even if HBS is not the most efficient class of schemes, that doesn't matter
>>> so much if we don't use HBS as our primary everyday signature scheme. Its
>>> value lies in security, not efficiency.
>>>
>>
>> When I mean "too soon", I'm including SPHINCS, not sure what
>>
>> 1. Earlier versions of the SPHINCS framework were found to be
>> susceptible to fault attacks
>> 2. Earlier "Tight" proof for v1 SPHINCS was flawed, leading to 60 bits of
>> security, not 128
>>
>> > If you're worried about stuff like how xpubs would work with HBS, we
>> have solutions for that too, and they are mostly drop-in replacements for
>> existing standards.
>>
>> I thought "tweaking", in general, is lost in SPHINCS, as well as
>> multiparty sigs. Be interested to see those solutions. But, regardless,
>> 17kb sigs are... not compatible with a decentralized bitcoin, imo.
>> Lattice-sigs are the only reasonable PQ way forward and they aren't ready
>> yet.
>>
>
--
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/2e1d77b5-080c-423c-9796-d5ba3f22017dn%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 7594 bytes --]
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms
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
0 siblings, 1 reply; 42+ messages in thread
From: Javier Mateos @ 2026-02-25 10:43 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 7452 bytes --]
Hi list,
Ethan’s framework of using Schnorr for everyday spending and a hash based
signature as a fallback inside P2MR strikes me as the right direction. I’ve
been working on a concrete proposal for that fallback role.
WOTS-Tree [1] is essentially XMSS parameterized for Bitcoin: SHA-256
truncated to 128 bits for the WOTS+ chains, and full SHA-256 for the Merkle
tree. The fallback witness is 675 bytes with 1,024 leaves, or 353 bytes for
single use UTXOs. Verification is bounded at 4,601 hash computations.
It is deployed as a leaf under BIP 341 and is compatible with BIP 360. When
spending with Schnorr, the extra cost is the same ~10 vbytes as any other
unused leaf.
It is stateful, which I understand is not ideal for everyone. However,
unlike generic XMSS, the main risk of stateful schemes reusing an index and
breaking security is mitigated here because the blockchain already records
which leaves have been used. The paper describes a three step state
recovery protocol based on the UTXO set, and chain isolation ensures that
RBF does not force signature reuse.
Paper with full security reduction, implementation, and test vectors:
[1] https://eprint.iacr.org/2026/374 <https://eprint.iacr.org/2026/XXX>
[2] https://github.com/javierpmateos/wots-tree
Best regards,
Javier
El miércoles, 25 de febrero de 2026 a las 0:42:16 UTC-3, Alex escribió:
> You don't need "the perfect signature" on day 1, you just need something
> everyone can agree on is good enough as a migration step. SLH-DSA can
> indeed fill that role - it means a transaction will cost about 10x more
> than now.
>
> Whether SLH-DSA or ML-DSA is picked is IMO less important because
> eventually "the perfect signature" will be ready: https://sqisign.org/
>
> SQIsign is 65 + 148 bytes and my DDR3 era Haswell PC (from 2014) can
> verify 1000 sigs per second using the non-optimized reference
> implementation. A modern budget CPU can do 30k verifications per second.
>
> You only need SLH-DSA as an (optional) signature that maybe is never even
> used at all. It's just an insurance. When I hear people say "we don't need
> this we can just make a ZK proof of the seed phrase" - I'm pretty sure such
> a ZK proof is much larger than SLH-DSA anyways and would require a total
> halt of the Bitcoin network and be way less efficient. With SLH-DSA you
> would get that migration done seamlessly and more efficient anyways.
>
> måndag 23 februari 2026 kl. 23:03:03 UTC+1 skrev Ethan Heilman:
>
>> > I thought "tweaking", in general, is lost in SPHINCS, as well as
>> multiparty sigs. Be interested to see those solutions. But, regardless,
>> 17kb sigs are... not compatible with a decentralized bitcoin, imo.
>> Lattice-sigs are the only reasonable PQ way forward and they aren't ready
>> yet.
>>
>> SPHINCS is ~8kb (7,888 bytes) not 17kb.
>>
>> SPHINCS SLH-DSA-128s has 32 byte public keys and 7,856 byte signatures
>> Total size of 7,888 bytes not 17kb.
>>
>> The Lattice sigs aren't that much better than SPHINCS
>>
>> CRYSTALS-Dilithium ML-DSA has 1,312 byte public keys and 2,420 byte
>> signatures
>> Total size of 3,732 bytes.
>>
>> Falcon has 897 byte public keys and 666 signatures
>> 1,563 bytes
>>
>> ML-DSA currently has the most support in the Lattice world, but it is
>> still too large to be a drop in replacement for ECC without a witness
>> discount. If we had to choose tomorrow, I'd advocate for ML-DSA with a
>> massive witness discount, but I'd be very unhappy with the witness
>> discount. If the witness discount was out of the question, then I'd
>> advocate for something similar to 324-byte stateful hash based SHRINCS
>> signature. Neither is ideal.
>>
>> My current thinking is to use SLH-DSA as a backup. This keeps us safe if
>> everything goes wrong and allows us to reach safety early so we can take
>> time to determine the right drop-in replacement for ECC. Hopefully in 3
>> years, SQI-sign is fast enough to be considered.
>>
>> On Mon, Feb 23, 2026 at 2:08 PM Erik Aronesty <er...@q32.com> wrote:
>>
>>>
>>>>
>>>> I'd be excited to learn about this as an option. Erik, could you please
>>>> answer my previous questions about the viability of your linked protocol?
>>>> I'm not questioning its quantum-resistance properties (yet). I'm wondering
>>>> how it is possible to instantiate this scheme in a way that allows a wallet
>>>> to actually use this commit/reveal scheme without knowing the final
>>>> destination CTV templates (denoted T & E in the delving post) in advance of
>>>> creating the phase 0 locking script.
>>>>
>>>
>>> I provided an example script that shows how it works:
>>> https://gist.github.com/earonesty/ea086aa995be1a860af093f93bd45bf2. you
>>> don't pin to the final destination in phase 0.
>>>
>>> txhash is a partial-commitment, not over all fields. this give the
>>> flexibility needed for the final spend, since you don't commit to it.
>>>
>>> however someone has pointed out a fee-problem that CCV's value-aware
>>> composability can solve. coming around to thinking the ccv-based
>>> construction would be necessary. CCV is more powerful but requires much
>>> more care in policy and analysis. CTV is trivial, we could merge it
>>> tomorrow and hardly worry about surface area issues. TXHASH is only
>>> slightly more complicated. CCV has a much bigger burden of proof around
>>> implementation and node safety... but i think you could do many kinds of
>>> vaulting schemes with it alone.
>>>
>>>
>>> But in the case of hash-based signature (HBS) schemes, i disagree. HBS
>>>> is already mature. Whatever cryptanalytic breakthroughs the future holds,
>>>> we can be reasonably sure that SHA256 preimage resistance will hold for a
>>>> long time, so HBS security will hold. Even today md4 and md5 preimage
>>>> resistance still holds. Securing coins using hashes alone is the ideal
>>>> fallback, and even if HBS is not the most efficient class of schemes, that
>>>> doesn't matter so much if we don't use HBS as our primary everyday
>>>> signature scheme. Its value lies in security, not efficiency.
>>>>
>>>
>>> When I mean "too soon", I'm including SPHINCS, not sure what
>>>
>>> 1. Earlier versions of the SPHINCS framework were found to be
>>> susceptible to fault attacks
>>> 2. Earlier "Tight" proof for v1 SPHINCS was flawed, leading to 60 bits
>>> of security, not 128
>>>
>>> > If you're worried about stuff like how xpubs would work with HBS, we
>>> have solutions for that too, and they are mostly drop-in replacements for
>>> existing standards.
>>>
>>> I thought "tweaking", in general, is lost in SPHINCS, as well as
>>> multiparty sigs. Be interested to see those solutions. But, regardless,
>>> 17kb sigs are... not compatible with a decentralized bitcoin, imo.
>>> Lattice-sigs are the only reasonable PQ way forward and they aren't ready
>>> yet.
>>>
>>
--
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/5ce409f5-2416-4d79-9883-c2fb4b3eaaa8n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 9637 bytes --]
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms
2026-02-25 10:43 ` Javier Mateos
@ 2026-02-26 13:24 ` 'Mikhail Kudinov' via Bitcoin Development Mailing List
0 siblings, 0 replies; 42+ messages in thread
From: 'Mikhail Kudinov' via Bitcoin Development Mailing List @ 2026-02-26 13:24 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 9869 bytes --]
Dear Javier,
Thank you for your work. I am happy that more people are looking at the
possibility of using Hash-based schemes as a PQ solution for Bitcoin.
As far as I understood, the main idea was to propose concrete
instantiations/parameters, and essentially, the small signatures come from
the 2^10 limit on the number of signatures + fast route for the first
signature. The other proposal was to use 128-bit hash functions for chains,
which I think is the default way for the 128-bit security requirement.
I don't see why one needs to use the full 256 hashes in the Merkle trees.
In the signature context, we don't require collision resistance for
security. We only need target collision resistance, which can not be
attacked with the birthday paradox.
As for the statefulness issue: I agree that the blockchain does record the
signed transactions, but some of them may not end on the blockchain, hence
it is not a 100% reliable source of state. Given that the reuse of a nonce
leads to a forgery of the signature scheme, we can not use blockchain state
as a source of state.
As for the comparison with the alternative schemes, I think we should not
omit the number of supported signatures. It is an important metric that is
tightly related to the efficiency of a hash-based signature scheme.
Regarding some details that you mention in the paper:
Second-preimage resistance is not enough for the security of W-OTS+. Even
in [9] they require preimage resistance and undetectability. There is a
newer and tighter proof for XMSS, which can be found
here: https://eprint.iacr.org/2023/408 (based on
https://eprint.iacr.org/2022/346).
To achieve 128-bit security with the non-tight reduction strategy, one
needs to add K + log(lw) bits rather than just log(lw). But with the tight
proof I referenced, this loss can be avoided.
I also did not understand how you suggest deriving the public seed from the
transaction, given that the public seed is needed to compute the public key
root.
The original SPHINCS scheme used HORST, not FORS. FORS was introduced later
for SPHINCS+ (SLH-DSA).
Best,
Mike
On Wednesday, February 25, 2026 at 12:32:47 PM UTC+1 Javier Mateos wrote:
> Hi list,
>
> Ethan’s framework of using Schnorr for everyday spending and a hash based
> signature as a fallback inside P2MR strikes me as the right direction. I’ve
> been working on a concrete proposal for that fallback role.
>
> WOTS-Tree [1] is essentially XMSS parameterized for Bitcoin: SHA-256
> truncated to 128 bits for the WOTS+ chains, and full SHA-256 for the Merkle
> tree. The fallback witness is 675 bytes with 1,024 leaves, or 353 bytes for
> single use UTXOs. Verification is bounded at 4,601 hash computations.
>
> It is deployed as a leaf under BIP 341 and is compatible with BIP 360.
> When spending with Schnorr, the extra cost is the same ~10 vbytes as any
> other unused leaf.
>
> It is stateful, which I understand is not ideal for everyone. However,
> unlike generic XMSS, the main risk of stateful schemes reusing an index and
> breaking security is mitigated here because the blockchain already records
> which leaves have been used. The paper describes a three step state
> recovery protocol based on the UTXO set, and chain isolation ensures that
> RBF does not force signature reuse.
>
> Paper with full security reduction, implementation, and test vectors:
> [1] https://eprint.iacr.org/2026/374 <https://eprint.iacr.org/2026/XXX>
> [2] https://github.com/javierpmateos/wots-tree
>
> Best regards,
> Javier
>
> El miércoles, 25 de febrero de 2026 a las 0:42:16 UTC-3, Alex escribió:
>
>> You don't need "the perfect signature" on day 1, you just need something
>> everyone can agree on is good enough as a migration step. SLH-DSA can
>> indeed fill that role - it means a transaction will cost about 10x more
>> than now.
>>
>> Whether SLH-DSA or ML-DSA is picked is IMO less important because
>> eventually "the perfect signature" will be ready: https://sqisign.org/
>>
>> SQIsign is 65 + 148 bytes and my DDR3 era Haswell PC (from 2014) can
>> verify 1000 sigs per second using the non-optimized reference
>> implementation. A modern budget CPU can do 30k verifications per second.
>>
>> You only need SLH-DSA as an (optional) signature that maybe is never even
>> used at all. It's just an insurance. When I hear people say "we don't need
>> this we can just make a ZK proof of the seed phrase" - I'm pretty sure such
>> a ZK proof is much larger than SLH-DSA anyways and would require a total
>> halt of the Bitcoin network and be way less efficient. With SLH-DSA you
>> would get that migration done seamlessly and more efficient anyways.
>>
>> måndag 23 februari 2026 kl. 23:03:03 UTC+1 skrev Ethan Heilman:
>>
>>> > I thought "tweaking", in general, is lost in SPHINCS, as well as
>>> multiparty sigs. Be interested to see those solutions. But, regardless,
>>> 17kb sigs are... not compatible with a decentralized bitcoin, imo.
>>> Lattice-sigs are the only reasonable PQ way forward and they aren't ready
>>> yet.
>>>
>>> SPHINCS is ~8kb (7,888 bytes) not 17kb.
>>>
>>> SPHINCS SLH-DSA-128s has 32 byte public keys and 7,856 byte signatures
>>> Total size of 7,888 bytes not 17kb.
>>>
>>> The Lattice sigs aren't that much better than SPHINCS
>>>
>>> CRYSTALS-Dilithium ML-DSA has 1,312 byte public keys and 2,420 byte
>>> signatures
>>> Total size of 3,732 bytes.
>>>
>>> Falcon has 897 byte public keys and 666 signatures
>>> 1,563 bytes
>>>
>>> ML-DSA currently has the most support in the Lattice world, but it is
>>> still too large to be a drop in replacement for ECC without a witness
>>> discount. If we had to choose tomorrow, I'd advocate for ML-DSA with a
>>> massive witness discount, but I'd be very unhappy with the witness
>>> discount. If the witness discount was out of the question, then I'd
>>> advocate for something similar to 324-byte stateful hash based SHRINCS
>>> signature. Neither is ideal.
>>>
>>> My current thinking is to use SLH-DSA as a backup. This keeps us safe if
>>> everything goes wrong and allows us to reach safety early so we can take
>>> time to determine the right drop-in replacement for ECC. Hopefully in 3
>>> years, SQI-sign is fast enough to be considered.
>>>
>>> On Mon, Feb 23, 2026 at 2:08 PM Erik Aronesty <er...@q32.com> wrote:
>>>
>>>>
>>>>>
>>>>> I'd be excited to learn about this as an option. Erik, could you
>>>>> please answer my previous questions about the viability of your linked
>>>>> protocol? I'm not questioning its quantum-resistance properties (yet). I'm
>>>>> wondering how it is possible to instantiate this scheme in a way that
>>>>> allows a wallet to actually use this commit/reveal scheme without knowing
>>>>> the final destination CTV templates (denoted T & E in the delving post) in
>>>>> advance of creating the phase 0 locking script.
>>>>>
>>>>
>>>> I provided an example script that shows how it works:
>>>> https://gist.github.com/earonesty/ea086aa995be1a860af093f93bd45bf2.
>>>> you don't pin to the final destination in phase 0.
>>>>
>>>> txhash is a partial-commitment, not over all fields. this give the
>>>> flexibility needed for the final spend, since you don't commit to it.
>>>>
>>>> however someone has pointed out a fee-problem that CCV's value-aware
>>>> composability can solve. coming around to thinking the ccv-based
>>>> construction would be necessary. CCV is more powerful but requires much
>>>> more care in policy and analysis. CTV is trivial, we could merge it
>>>> tomorrow and hardly worry about surface area issues. TXHASH is only
>>>> slightly more complicated. CCV has a much bigger burden of proof around
>>>> implementation and node safety... but i think you could do many kinds of
>>>> vaulting schemes with it alone.
>>>>
>>>>
>>>> But in the case of hash-based signature (HBS) schemes, i disagree. HBS
>>>>> is already mature. Whatever cryptanalytic breakthroughs the future holds,
>>>>> we can be reasonably sure that SHA256 preimage resistance will hold for a
>>>>> long time, so HBS security will hold. Even today md4 and md5 preimage
>>>>> resistance still holds. Securing coins using hashes alone is the ideal
>>>>> fallback, and even if HBS is not the most efficient class of schemes, that
>>>>> doesn't matter so much if we don't use HBS as our primary everyday
>>>>> signature scheme. Its value lies in security, not efficiency.
>>>>>
>>>>
>>>> When I mean "too soon", I'm including SPHINCS, not sure what
>>>>
>>>> 1. Earlier versions of the SPHINCS framework were found to be
>>>> susceptible to fault attacks
>>>> 2. Earlier "Tight" proof for v1 SPHINCS was flawed, leading to 60 bits
>>>> of security, not 128
>>>>
>>>> > If you're worried about stuff like how xpubs would work with HBS, we
>>>> have solutions for that too, and they are mostly drop-in replacements for
>>>> existing standards.
>>>>
>>>> I thought "tweaking", in general, is lost in SPHINCS, as well as
>>>> multiparty sigs. Be interested to see those solutions. But, regardless,
>>>> 17kb sigs are... not compatible with a decentralized bitcoin, imo.
>>>> Lattice-sigs are the only reasonable PQ way forward and they aren't ready
>>>> yet.
>>>>
>>>
--
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/45c53988-f011-4bc5-b58b-7656dcf5d080n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 12535 bytes --]
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms
2026-02-23 21:42 ` Ethan Heilman
2026-02-24 0:12 ` Alex
@ 2026-02-26 15:51 ` Matt Corallo
2026-02-27 15:18 ` 'Mikhail Kudinov' via Bitcoin Development Mailing List
1 sibling, 1 reply; 42+ messages in thread
From: Matt Corallo @ 2026-02-26 15:51 UTC (permalink / raw)
To: Ethan Heilman, Erik Aronesty
Cc: conduition, garlonicon, Jonas Nick, bitcoindev
On 2/23/26 4:42 PM, Ethan Heilman wrote:
> > I thought "tweaking", in general, is lost in SPHINCS, as well as multiparty sigs. Be interested
> to see those solutions. But, regardless, 17kb sigs are... not compatible with a decentralized
> bitcoin, imo. Lattice-sigs are the only reasonable PQ way forward and they aren't ready yet.
>
> SPHINCS is ~8kb (7,888 bytes) not 17kb.
>
> SPHINCS SLH-DSA-128s has 32 byte public keys and 7,856 byte signatures
> Total size of 7,888 bytes not 17kb.
>
> The Lattice sigs aren't that much better than SPHINCS
>
> CRYSTALS-Dilithium ML-DSA has 1,312 byte public keys and 2,420 byte signatures
> Total size of 3,732 bytes.
>
> Falcon has 897 byte public keys and 666 signatures
> 1,563 bytes
>
> ML-DSA currently has the most support in the Lattice world, but it is still too large to be a drop
> in replacement for ECC without a witness discount. If we had to choose tomorrow, I'd advocate for
> ML-DSA with a massive witness discount, but I'd be very unhappy with the witness discount. If the
> witness discount was out of the question, then I'd advocate for something similar to 324-byte
> stateful hash based SHRINCS signature. Neither is ideal.
>
> My current thinking is to use SLH-DSA as a backup. This keeps us safe if everything goes wrong and
> allows us to reach safety early so we can take time to determine the right drop-in replacement for
> ECC. Hopefully in 3 years, SQI-sign is fast enough to be considered.
Why not just do SHRINCS today? The cost to use it in "stateless mode" is only marginally higher than
other stateless hash-based signatures, and wallets can elect to use the stateful mode at signing
time if they're set up for it.
Matt
--
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/1ee30c09-ca46-404f-a9f4-2ff8ff6a2c0b%40mattcorallo.com.
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms
2026-02-26 15:51 ` Matt Corallo
@ 2026-02-27 15:18 ` 'Mikhail Kudinov' via Bitcoin Development Mailing List
0 siblings, 0 replies; 42+ messages in thread
From: 'Mikhail Kudinov' via Bitcoin Development Mailing List @ 2026-02-27 15:18 UTC (permalink / raw)
To: Matt Corallo
Cc: Ethan Heilman, Erik Aronesty, conduition, garlonicon, Jonas Nick,
bitcoindev
[-- Attachment #1: Type: text/plain, Size: 4876 bytes --]
Speaking of Lattice-Based solutions. There has been significant progress in
adopting PQ solutions in the real world. Signatures are not as widely
deployed, but the work is going on. There is a recent update from Apple:
https://support.apple.com/guide/security/quantum-secure-cryptography-apple-devices-secc7c82e533/web
.
An interesting point is that it does not use level 1 security for lattice
schemes (it offers level 3 or level 5, both for ML-KEM and ML-DSA). A
similar approach was used in Cloudflare:
https://blog.cloudflare.com/pq-2025/. More specifically, see this part:
https://blog.cloudflare.com/pq-2025/#ml-kem-768-and-x25519. Let me cite Bas
here: "There is a lot of trust in the (non post-quantum) security of
X25519: matching AES-128 is more than enough. Although we are comfortable
in the security of ML-KEM-512 today, over the coming decades, cryptanalysis
could improve. Thus, we'd like to keep a margin for now."
Cloudflare settles for a smaller margin for ML-DSA, but the reasoning is
that they can upgrade later if needed:
"ML-DSA-44 as level 2 is comfortably above level 1. It's indeed below
ML-KEM-768. I'd be comfortable with level 2 ML-KEM, but that doesn't exist.
Anyway, ML-DSA requires less margin as it doesn't suffer
store-now/decrypt-later. We can roll ML-DSA certs if attacks improve, but
we can't roll captured data encrypted with ML-KEM."
In our setting, switching to a new set of parameters is more difficult.
So, it seems reasonable that, if we are discussing a lattice-based
construction, we should also include some margin. That said, if we exclude
level 1 security, the smallest size we get is 3073 bytes for Falcon level
5. See https://pqshield.github.io/nist-sigs-zoo/ for a quick comparison.
Level 3 ML-DSA requires 5,261 bytes.
Of course, lattice constructions have more to offer than just smaller
sizes. Different schemes may allow for public key derivation, maybe more
efficient multi/threshold signatures, and so on. We should keep in mind
that, if we want to include a security margin for possible future
improvements, the sizes will be larger.
Best,
Mike
On Thu, Feb 26, 2026 at 4:56 PM Matt Corallo <lf-lists@mattcorallo.com>
wrote:
>
>
> On 2/23/26 4:42 PM, Ethan Heilman wrote:
> > > I thought "tweaking", in general, is lost in SPHINCS, as well as
> multiparty sigs. Be interested
> > to see those solutions. But, regardless, 17kb sigs are... not
> compatible with a decentralized
> > bitcoin, imo. Lattice-sigs are the only reasonable PQ way forward and
> they aren't ready yet.
> >
> > SPHINCS is ~8kb (7,888 bytes) not 17kb.
> >
> > SPHINCS SLH-DSA-128s has 32 byte public keys and 7,856 byte signatures
> > Total size of 7,888 bytes not 17kb.
> >
> > The Lattice sigs aren't that much better than SPHINCS
> >
> > CRYSTALS-Dilithium ML-DSA has 1,312 byte public keys and 2,420 byte
> signatures
> > Total size of 3,732 bytes.
> >
> > Falcon has 897 byte public keys and 666 signatures
> > 1,563 bytes
> >
> > ML-DSA currently has the most support in the Lattice world, but it is
> still too large to be a drop
> > in replacement for ECC without a witness discount. If we had to choose
> tomorrow, I'd advocate for
> > ML-DSA with a massive witness discount, but I'd be very unhappy with the
> witness discount. If the
> > witness discount was out of the question, then I'd advocate for
> something similar to 324-byte
> > stateful hash based SHRINCS signature. Neither is ideal.
> >
> > My current thinking is to use SLH-DSA as a backup. This keeps us safe if
> everything goes wrong and
> > allows us to reach safety early so we can take time to determine the
> right drop-in replacement for
> > ECC. Hopefully in 3 years, SQI-sign is fast enough to be considered.
>
>
> Why not just do SHRINCS today? The cost to use it in "stateless mode" is
> only marginally higher than
> other stateless hash-based signatures, and wallets can elect to use the
> stateful mode at signing
> time if they're set up for it.
>
> Matt
>
> --
> 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/1ee30c09-ca46-404f-a9f4-2ff8ff6a2c0b%40mattcorallo.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/CAPcK4uQvkjUAAvVxS2%2BgX8VBiXp5cnxvCURRtkJSOMU5wfRVHA%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 6213 bytes --]
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms
2026-02-23 19:08 ` Erik Aronesty
2026-02-23 21:42 ` Ethan Heilman
@ 2026-02-27 19:31 ` 'conduition' via Bitcoin Development Mailing List
2026-03-01 12:24 ` 'Mikhail Kudinov' via Bitcoin Development Mailing List
1 sibling, 1 reply; 42+ messages in thread
From: 'conduition' via Bitcoin Development Mailing List @ 2026-02-27 19:31 UTC (permalink / raw)
To: Erik Aronesty; +Cc: garlonicon, Ethan Heilman, Jonas Nick, bitcoindev
[-- Attachment #1.1.1: Type: text/plain, Size: 5423 bytes --]
> I thought "tweaking", in general, is lost in SPHINCS, as well as multiparty sigs. Be interested to see those solutions.
This is correct, but you don't actually need public-key tweaking to use an SLH-DSA pubkey as a backup for an ECC xpub. You can just append the SLH-DSA public key to a BIP32 xpub, and use the result to construct PQ-hybridized child addresses. For privacy we can attach a pseudorandom nonce derived from the chaincode, to prevent on-chain fingerprinting of unused BIP360 leaves. The resulting tap leaf hash looks random, and the SLH-DSA public key (and nonce) is only revealed if used for spending.
All this will be spec'd out as part of a non-consensus BIP, to help wallets build safe and robust quantum-resistant addresses.
> I provided an example script that shows how it works: https://gist.github.com/earonesty/ea086aa995be1a860af093f93bd45bf2. you don't pin to the final destination in phase 0.
This pseudocode seems to commit the CTV hashes T & E in the anchor_script which is used to construct the funding UTXO. This is exactly the problem I mentioned which would prevent this technique from being usable as a PQ fallback script.
> txhash is a partial-commitment, not over all fields. this give the flexibility needed for the final spend, since you don't commit to it.
You've stated specifically in your post that TXHASH enforces that the `AnchorPublishTx` creates a UTXO paying to `P_anchor`.
> OP_TXHASH is used only in Phase 0 to enforce a partial covenant... [that] pins the next envelope (P_anchor)
You've also stated that `P_anchor` commits to the CTV template hashes `T` & `E`.
> P_anchor: Taproot output key committing to an Anchor script tree that ... enforces reveal-or-escape spending conditions
This statement is backed up by the pseudocode which depends on `T` and `E` when constructing `P_anchor`, as i pointed out earlier in this email.
Thus, TXHASH (and by extension, the funding script pubkey) commits to CTV hashes `T` & `E`, yes?
Perhaps it would help if you mentioned which `TxFieldSelector` you are using, otherwise i'm just left to guess. The pseudocode is unclear.
regards,
conduition
On Monday, February 23rd, 2026 at 11:08 AM, Erik Aronesty <erik@q32.com> wrote:
> >
> >
> > I'd be excited to learn about this as an option. Erik, could you please answer my previous questions about the viability of your linked protocol? I'm not questioning its quantum-resistance properties (yet). I'm wondering how it is possible to instantiate this scheme in a way that allows a wallet to actually use this commit/reveal scheme without knowing the final destination CTV templates (denoted T & E in the delving post) in advance of creating the phase 0 locking script.
>
>
> I provided an example script that shows how it works: https://gist.github.com/earonesty/ea086aa995be1a860af093f93bd45bf2. you don't pin to the final destination in phase 0.
>
> txhash is a partial-commitment, not over all fields. this give the flexibility needed for the final spend, since you don't commit to it.
>
> however someone has pointed out a fee-problem that CCV's value-aware composability can solve. coming around to thinking the ccv-based construction would be necessary. CCV is more powerful but requires much more care in policy and analysis. CTV is trivial, we could merge it tomorrow and hardly worry about surface area issues. TXHASH is only slightly more complicated. CCV has a much bigger burden of proof around implementation and node safety... but i think you could do many kinds of vaulting schemes with it alone.
>
>
>
> > But in the case of hash-based signature (HBS) schemes, i disagree. HBS is already mature. Whatever cryptanalytic breakthroughs the future holds, we can be reasonably sure that SHA256 preimage resistance will hold for a long time, so HBS security will hold. Even today md4 and md5 preimage resistance still holds. Securing coins using hashes alone is the ideal fallback, and even if HBS is not the most efficient class of schemes, that doesn't matter so much if we don't use HBS as our primary everyday signature scheme. Its value lies in security, not efficiency.
>
>
> When I mean "too soon", I'm including SPHINCS, not sure what
> 1. Earlier versions of the SPHINCS framework were found to be susceptible to fault attacks
> 2. Earlier "Tight" proof for v1 SPHINCS was flawed, leading to 60 bits of security, not 128
> > If you're worried about stuff like how xpubs would work with HBS, we have solutions for that too, and they are mostly drop-in replacements for existing standards.
>
> I thought "tweaking", in general, is lost in SPHINCS, as well as multiparty sigs. Be interested to see those solutions. But, regardless, 17kb sigs are... not compatible with a decentralized bitcoin, imo. Lattice-sigs are the only reasonable PQ way forward and they aren't ready yet.
--
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/xGWRYbDSxkWxiv5eYH_LbX3hTXs1x2wrn6ar5EfMKKCwvRAT137keXQZqs9SaeTxOjrb5tziRcFU82wSPGD-QVokCrA-Aikfr4vktqSvK7c%3D%40proton.me.
[-- Attachment #1.1.2.1: Type: text/html, Size: 11036 bytes --]
[-- 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 --]
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms
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
0 siblings, 1 reply; 42+ messages in thread
From: 'Mikhail Kudinov' via Bitcoin Development Mailing List @ 2026-03-01 12:24 UTC (permalink / raw)
To: conduition
Cc: Erik Aronesty, garlonicon, Ethan Heilman, Jonas Nick, bitcoindev
[-- Attachment #1: Type: text/plain, Size: 7243 bytes --]
I don’t think that Fault attacks are mitigated for SLH-DSA, the mitigation
that is available is to run the signing process multiple times and check if
the signatures are the same. But fault injection attacks require physical
access to signing device with the ability to flip at least one bit during
the computation.
As for the security proof.
There was a problem with the old security proof, but the scheme still had a
proof, just not as tight as it was claimed. The problem with the proof did
not constitute any attack. A new proof was constructed with out changing
the scheme even slightly. This new proof was later formally verified with
EasyCrypt:
https://eprint.iacr.org/2024/910
Пт, 27 февр. 2026 г. в 22:21, 'conduition' via Bitcoin Development Mailing
List <bitcoindev@googlegroups.com>:
> I thought "tweaking", in general, is lost in SPHINCS, as well as
> multiparty sigs. Be interested to see those solutions.
>
>
> This is correct, but you don't actually need public-key tweaking to use an
> SLH-DSA pubkey as a backup for an ECC xpub. You can just append the SLH-DSA
> public key to a BIP32 xpub, and use the result to construct PQ-hybridized
> child addresses. For privacy we can attach a pseudorandom nonce derived
> from the chaincode, to prevent on-chain fingerprinting of unused BIP360
> leaves. The resulting tap leaf hash looks random, and the SLH-DSA public
> key (and nonce) is only revealed if used for spending.
>
> All this will be spec'd out as part of a non-consensus BIP, to help
> wallets build safe and robust quantum-resistant addresses.
>
> I provided an example script that shows how it works:
> https://gist.github.com/earonesty/ea086aa995be1a860af093f93bd45bf2. you
> don't pin to the final destination in phase 0.
>
>
> This pseudocode seems to commit the CTV hashes T & E in the anchor_script
> <https://gist.github.com/earonesty/ea086aa995be1a860af093f93bd45bf2#file-gistfile1-txt-L305> which
> is used to construct the funding UTXO
> <https://gist.github.com/earonesty/ea086aa995be1a860af093f93bd45bf2#file-gistfile1-txt-L324-L328>.
> This is exactly the problem I mentioned which would prevent this technique
> from being usable as a PQ fallback script.
>
> txhash is a partial-commitment, not over all fields. this give the
> flexibility needed for the final spend, since you don't commit to it.
>
>
> You've stated specifically in your post that TXHASH enforces that the
> AnchorPublishTx creates a UTXO paying to P_anchor.
>
> OP_TXHASH is used only in Phase 0 to enforce a partial covenant... [that] pins
> the next envelope (P_anchor)
>
>
> You've also stated that P_anchor commits to the CTV template hashes T &
> E.
>
> P_anchor: Taproot output key committing to an Anchor script tree that ... enforces
> reveal-or-escape spending conditions
>
>
> This statement is backed up by the pseudocode which depends on T and E
> when constructing P_anchor, as i pointed out earlier in this email.
>
> Thus, TXHASH (and by extension, the funding script pubkey) commits to CTV
> hashes T & E, yes?
>
> Perhaps it would help if you mentioned which TxFieldSelector you are
> using, otherwise i'm just left to guess. The pseudocode is unclear.
>
> regards,
> conduition
>
> On Monday, February 23rd, 2026 at 11:08 AM, Erik Aronesty <erik@q32.com>
> wrote:
>
>
>>
>> I'd be excited to learn about this as an option. Erik, could you please
>> answer my previous questions about the viability of your linked protocol?
>> I'm not questioning its quantum-resistance properties (yet). I'm wondering
>> how it is possible to instantiate this scheme in a way that allows a wallet
>> to actually use this commit/reveal scheme without knowing the final
>> destination CTV templates (denoted T & E in the delving post) in advance of
>> creating the phase 0 locking script.
>>
>
> I provided an example script that shows how it works:
> https://gist.github.com/earonesty/ea086aa995be1a860af093f93bd45bf2. you
> don't pin to the final destination in phase 0.
>
> txhash is a partial-commitment, not over all fields. this give the
> flexibility needed for the final spend, since you don't commit to it.
>
> however someone has pointed out a fee-problem that CCV's value-aware
> composability can solve. coming around to thinking the ccv-based
> construction would be necessary. CCV is more powerful but requires much
> more care in policy and analysis. CTV is trivial, we could merge it
> tomorrow and hardly worry about surface area issues. TXHASH is only
> slightly more complicated. CCV has a much bigger burden of proof around
> implementation and node safety... but i think you could do many kinds of
> vaulting schemes with it alone.
>
>
> But in the case of hash-based signature (HBS) schemes, i disagree. HBS is
>> already mature. Whatever cryptanalytic breakthroughs the future holds, we
>> can be reasonably sure that SHA256 preimage resistance will hold for a long
>> time, so HBS security will hold. Even today md4 and md5 preimage resistance
>> still holds. Securing coins using hashes alone is the ideal fallback, and
>> even if HBS is not the most efficient class of schemes, that doesn't matter
>> so much if we don't use HBS as our primary everyday signature scheme. Its
>> value lies in security, not efficiency.
>>
>
> When I mean "too soon", I'm including SPHINCS, not sure what
>
> 1. Earlier versions of the SPHINCS framework were found to be susceptible
> to fault attacks
> 2. Earlier "Tight" proof for v1 SPHINCS was flawed, leading to 60 bits of
> security, not 128
>
> > If you're worried about stuff like how xpubs would work with HBS, we
> have solutions for that too, and they are mostly drop-in replacements for
> existing standards.
>
> I thought "tweaking", in general, is lost in SPHINCS, as well as
> multiparty sigs. Be interested to see those solutions. But, regardless,
> 17kb sigs are... not compatible with a decentralized bitcoin, imo.
> Lattice-sigs are the only reasonable PQ way forward and they aren't ready
> yet.
>
>
> --
> 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/xGWRYbDSxkWxiv5eYH_LbX3hTXs1x2wrn6ar5EfMKKCwvRAT137keXQZqs9SaeTxOjrb5tziRcFU82wSPGD-QVokCrA-Aikfr4vktqSvK7c%3D%40proton.me
> <https://groups.google.com/d/msgid/bitcoindev/xGWRYbDSxkWxiv5eYH_LbX3hTXs1x2wrn6ar5EfMKKCwvRAT137keXQZqs9SaeTxOjrb5tziRcFU82wSPGD-QVokCrA-Aikfr4vktqSvK7c%3D%40proton.me?utm_medium=email&utm_source=footer>
> .
>
--
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/CAPcK4uR_Zh4Mncjkj10CDojs%2BddYB08CT%2BJ3coWSKEBL%3Dd_EJw%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 14683 bytes --]
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms
2026-03-01 12:24 ` 'Mikhail Kudinov' via Bitcoin Development Mailing List
@ 2026-03-01 21:28 ` Alex
0 siblings, 0 replies; 42+ messages in thread
From: Alex @ 2026-03-01 21:28 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 9128 bytes --]
> I don’t think that Fault attacks are mitigated for SLH-DSA, the
mitigation that is available is to run the signing process multiple times
and check if the signatures are the same. But fault injection attacks
require physical access to signing device with the ability to flip at least
one bit during the computation.
Whether a signing device has an implementation bug/issue that flips bits
and therefore exposes private information or not is irrelevant to the
Bitcoin network. The Bitcoin network only _verifies_ SLH-DSA. Highly
academic "what ifs" regarding "what if we corrupt memory of the signer
while it signs" is just that, academic. In reality, SLH-DSA does not have
any known weakness for validation and the algorithm is standardized PQC
NIST algo.
If your Trezor/Ledger/mobile phone device can't hold RAM non-corrupt while
it runs a signing algo, you have bigger problems.
SLH-DSA is not in need for any mitigations. If implementations cannot trust
their RAM they need to emulate error corrected RAM or use error corrected
RAM. It's an implementation detail of the signer.
In any case, hyper focusing on SLH-DSA is really missing the point of this
thread. The point is "algorithmic agility" meaning, we need to have a way
to support many algos, including SLH-DSA and/or ML-DSA. And the proposed
overall solution in this tread is to have those algos as OP-codes that are
invoked via a spending script that is part of a bigger Merkle tree of
spending scripts that optionally can be invoked as we find out what algos
are broken and which are not.
söndag 1 mars 2026 kl. 13:30:52 UTC+1 skrev Mikhail Kudinov:
> I don’t think that Fault attacks are mitigated for SLH-DSA, the mitigation
> that is available is to run the signing process multiple times and check if
> the signatures are the same. But fault injection attacks require physical
> access to signing device with the ability to flip at least one bit during
> the computation.
>
> As for the security proof.
> There was a problem with the old security proof, but the scheme still had
> a proof, just not as tight as it was claimed. The problem with the proof
> did not constitute any attack. A new proof was constructed with out
> changing the scheme even slightly. This new proof was later formally
> verified with EasyCrypt:
> https://eprint.iacr.org/2024/910
>
> Пт, 27 февр. 2026 г. в 22:21, 'conduition' via Bitcoin Development Mailing
> List <bitco...@googlegroups.com>:
>
>> I thought "tweaking", in general, is lost in SPHINCS, as well as
>> multiparty sigs. Be interested to see those solutions.
>>
>>
>> This is correct, but you don't actually need public-key tweaking to use
>> an SLH-DSA pubkey as a backup for an ECC xpub. You can just append the
>> SLH-DSA public key to a BIP32 xpub, and use the result to construct
>> PQ-hybridized child addresses. For privacy we can attach a pseudorandom
>> nonce derived from the chaincode, to prevent on-chain fingerprinting of
>> unused BIP360 leaves. The resulting tap leaf hash looks random, and the
>> SLH-DSA public key (and nonce) is only revealed if used for spending.
>>
>> All this will be spec'd out as part of a non-consensus BIP, to help
>> wallets build safe and robust quantum-resistant addresses.
>>
>> I provided an example script that shows how it works:
>> https://gist.github.com/earonesty/ea086aa995be1a860af093f93bd45bf2. you
>> don't pin to the final destination in phase 0.
>>
>>
>> This pseudocode seems to commit the CTV hashes T & E in the anchor_script
>> <https://gist.github.com/earonesty/ea086aa995be1a860af093f93bd45bf2#file-gistfile1-txt-L305> which
>> is used to construct the funding UTXO
>> <https://gist.github.com/earonesty/ea086aa995be1a860af093f93bd45bf2#file-gistfile1-txt-L324-L328>.
>> This is exactly the problem I mentioned which would prevent this technique
>> from being usable as a PQ fallback script.
>>
>> txhash is a partial-commitment, not over all fields. this give the
>> flexibility needed for the final spend, since you don't commit to it.
>>
>>
>> You've stated specifically in your post that TXHASH enforces that the
>> AnchorPublishTx creates a UTXO paying to P_anchor.
>>
>> OP_TXHASH is used only in Phase 0 to enforce a partial covenant... [that] pins
>> the next envelope (P_anchor)
>>
>>
>> You've also stated that P_anchor commits to the CTV template hashes T &
>> E.
>>
>> P_anchor: Taproot output key committing to an Anchor script tree that ... enforces
>> reveal-or-escape spending conditions
>>
>>
>> This statement is backed up by the pseudocode which depends on T and E
>> when constructing P_anchor, as i pointed out earlier in this email.
>>
>> Thus, TXHASH (and by extension, the funding script pubkey) commits to CTV
>> hashes T & E, yes?
>>
>> Perhaps it would help if you mentioned which TxFieldSelector you are
>> using, otherwise i'm just left to guess. The pseudocode is unclear.
>>
>> regards,
>> conduition
>>
>> On Monday, February 23rd, 2026 at 11:08 AM, Erik Aronesty <er...@q32.com>
>> wrote:
>>
>>
>>>
>>> I'd be excited to learn about this as an option. Erik, could you please
>>> answer my previous questions about the viability of your linked protocol?
>>> I'm not questioning its quantum-resistance properties (yet). I'm wondering
>>> how it is possible to instantiate this scheme in a way that allows a wallet
>>> to actually use this commit/reveal scheme without knowing the final
>>> destination CTV templates (denoted T & E in the delving post) in advance of
>>> creating the phase 0 locking script.
>>>
>>
>> I provided an example script that shows how it works:
>> https://gist.github.com/earonesty/ea086aa995be1a860af093f93bd45bf2. you
>> don't pin to the final destination in phase 0.
>>
>> txhash is a partial-commitment, not over all fields. this give the
>> flexibility needed for the final spend, since you don't commit to it.
>>
>> however someone has pointed out a fee-problem that CCV's value-aware
>> composability can solve. coming around to thinking the ccv-based
>> construction would be necessary. CCV is more powerful but requires much
>> more care in policy and analysis. CTV is trivial, we could merge it
>> tomorrow and hardly worry about surface area issues. TXHASH is only
>> slightly more complicated. CCV has a much bigger burden of proof around
>> implementation and node safety... but i think you could do many kinds of
>> vaulting schemes with it alone.
>>
>>
>> But in the case of hash-based signature (HBS) schemes, i disagree. HBS is
>>> already mature. Whatever cryptanalytic breakthroughs the future holds, we
>>> can be reasonably sure that SHA256 preimage resistance will hold for a long
>>> time, so HBS security will hold. Even today md4 and md5 preimage resistance
>>> still holds. Securing coins using hashes alone is the ideal fallback, and
>>> even if HBS is not the most efficient class of schemes, that doesn't matter
>>> so much if we don't use HBS as our primary everyday signature scheme. Its
>>> value lies in security, not efficiency.
>>>
>>
>> When I mean "too soon", I'm including SPHINCS, not sure what
>>
>> 1. Earlier versions of the SPHINCS framework were found to be
>> susceptible to fault attacks
>> 2. Earlier "Tight" proof for v1 SPHINCS was flawed, leading to 60 bits of
>> security, not 128
>>
>> > If you're worried about stuff like how xpubs would work with HBS, we
>> have solutions for that too, and they are mostly drop-in replacements for
>> existing standards.
>>
>> I thought "tweaking", in general, is lost in SPHINCS, as well as
>> multiparty sigs. Be interested to see those solutions. But, regardless,
>> 17kb sigs are... not compatible with a decentralized bitcoin, imo.
>> Lattice-sigs are the only reasonable PQ way forward and they aren't ready
>> yet.
>>
>>
>> --
>> 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/msgid/bitcoindev/xGWRYbDSxkWxiv5eYH_LbX3hTXs1x2wrn6ar5EfMKKCwvRAT137keXQZqs9SaeTxOjrb5tziRcFU82wSPGD-QVokCrA-Aikfr4vktqSvK7c%3D%40proton.me
>> <https://groups.google.com/d/msgid/bitcoindev/xGWRYbDSxkWxiv5eYH_LbX3hTXs1x2wrn6ar5EfMKKCwvRAT137keXQZqs9SaeTxOjrb5tziRcFU82wSPGD-QVokCrA-Aikfr4vktqSvK7c%3D%40proton.me?utm_medium=email&utm_source=footer>
>> .
>>
>
--
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/187d45c3-2b19-4d57-99cb-e6511818d6b7n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 18644 bytes --]
^ permalink raw reply [flat|nested] 42+ messages in thread
end of thread, other threads:[~2026-03-01 21:34 UTC | newest]
Thread overview: 42+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-02-09 14:20 [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms Ethan Heilman
2026-02-10 8:53 ` Jonas Nick
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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox