Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms

[Ethan Heilman]

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:

“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

[Jonas Nick]

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).

[Ethan Heilman]

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.

--
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/ea3a12db-e3fd-44b2-a22c-b960ed7ec6d3%40gmail.com.

[Ethan Heilman]

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 <fre...@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 <eth...@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/CAEM%3Dy%2BWTqe8%3DuqChu2vN3HruiJCvFcDMNP%2BJA0AwyOkaR%3Dz0Cw%40mail.gmail.com.

[Ethan Heilman]

>   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 <er...@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

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAEM%3Dy%2BU_PV7dA5Azr7D4Rnr40QaHKUrxdLmx0zPPjYoE-HZ%3DHw%40mail.gmail.com.

[Brandon Black]

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 <eth...@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:

--

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/CAEM%3Dy%2BWTqe8%3DuqChu2vN3HruiJCvFcDMNP%2BJA0AwyOkaR%3Dz0Cw%40mail.gmail.com.

[Erik Aronesty]

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

[Ethan Heilman]

>>  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

[Erik Aronesty]

i see so a minimal change to taproot would be a new version: “script spend only” or similar.

[Ethan Heilman]

>  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

[Matt Corallo]

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

[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

[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

[Alex]

>  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).

[Alex]

>  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?

[waxwing/ AdamISZ]

> 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

[Ethan Heilman]

>  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.

[Matt Corallo]

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

[Matt Corallo]

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

[Matt Corallo]

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

[Matt Corallo]

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

[Matt Corallo]

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

[Ethan Heilman]

 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.

[Matt Corallo]

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

[waxwing/ AdamISZ]

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 :)

[Matt Corallo]

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

[conduition]

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

--

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.

[conduition]

> 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

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/ByJc1I7sSQAMLnAzSHPi8KSSscU0qakPM2YI0qC6VBBOwzmYtQEW5NY6d80eLUCf7fmKxbdFlSuxm4RCoT5rtKT68Khdi2xjwYIu4B5e6BQ%3D%40proton.me.

[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.

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/GhzGKZ5zphDf7mFpC_PMD0Bn7-KIK14HXdCPLeB7HKvPBfDRVG8eUAlCKKLWcki6XDW0h0R1IQC5SS9B7jnMRS85GzOzcmCt9v5R3xoW4Js%3D%40proton.me.

[conduition]

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

conduition

On Friday, February 20th, 2026 at 6:48 PM, Erik Aronesty <er...@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.

[Erik Aronesty]

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.

[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.

[Alex]

>  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.

[Erik Aronesty]

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 <condu...@proton.me> wrote:

[Alex]

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.

[Javier Mateos]

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
[2] https://github.com/javierpmateos/wots-tree

Best regards,
Javier

[Mikhail Kudinov]

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

[Matt Corallo]

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

[Mikhail Kudinov]

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 

--
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/1ee30c09-ca46-404f-a9f4-2ff8ff6a2c0b%40mattcorallo.com.

[conduition]

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

[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>:

--
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.

[Alex]

>  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.