Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms

Garlo Nicon
2026-02-19T15:12:09Z

[-- Attachment #1: Type: text/plain, Size: 14293 bytes --]

> Future PQ Bitcoin wallet devs will see secp256k1 as we today see broken
primitives like md5 or DES.

We still have OP_SHA1 in the Script, and even in the TapScript, even though
there are known collisions for that. Also note, that MD5 is broken, only
when it comes to collisions. MD5 preimages are still unknown, because
mounting a preimage attack is much harder.

So, if we talk about disabling obsolete cryptography, then when OP_SHA1
will be disabled? I guess it won't change in the nearest future, even
though the first SHA-1 collision happened in February 2017, around 9 years
ago.

> Future devs shouldn't have to add legacy cruft EC libraries into their
codebases when it's not even usable for cryptography anymore.

Well, to fully break OP_CHECKSIG, you need to break both secp256k1 and
SHA-256. Otherwise, by breaking only secp256k1 alone, you will still have
40-byte DER signatures, and not 9-byte minimal ones, where everything is
fully broken. And it is possible to enforce a given Proof of Work, if you
use OP_SIZE on DER signatures. Even if you use private key, equal to one,
then still: you won't sweep everything, for example from this transaction:
aba3c2ae442aa20150996ee68f9aa4da83b57a4312891078be0c2e68c50b2801

Which means, that there are still use cases for OP_CHECKSIG, even if you
can break secp256k1, as long as you cannot break SHA-256.

wt., 17 lut 2026 o 08:51 'conduition' via Bitcoin Development Mailing List <
bitcoindev@googlegroups.com> napisał(a):

> > I just don't see a reason to do P2MR over just utilizing P2TR (or maybe
> P2TRv2).
> >
> > P2MR will *also* require an equivalent P2MR-disable-soft-fork
>
>
>
> P2TRv2 means locking wallets into using elliptic curve code for as long as
> P2TRv2 exists, because you will always have to compute and verify the
> tweaked output pubkey. Future PQ Bitcoin wallet devs will see secp256k1 as
> we today see broken primitives like md5 or DES. Future devs shouldn't have
> to add legacy cruft EC libraries into their codebases when it's not even
> usable for cryptography anymore.
>
> Even if you assume a second P2MR-disable-soft-fork will be needed (which
> is debatable), then it still pays to remove the inefficient and unnecessary
> cruft of EC crypto for the foreseeable post-quantum future. You might think
> of it as decoupling UTXO ownership from any specific public-key
> cryptosystem.
>
> Furthermore, if EC/keypath spending is disabled, P2MR actually requires
> less witness space per input than P2TRv2 because we dont need the
> now-useless internal key in a P2MR script spend witness, whereas P2TRv2
> will require it indefinitely until we can migrate to another new address
> format in the distant future. See
> https://github.com/bitcoin/bips/blob/master/bip-0360.mediawiki#comparison-with-p2tr-script-path-spend
>
> P2MR is strictly more secure since it depends on weaker assumptions.
> P2TRv2 is more complex for wallets to implement than P2MR, unless you count
> code reuse from P2TRv1. P2TRv2 is (marginally) computationally slower, and
> less block-space-efficient for script path spends. So who would choose
> P2TRv2 over P2MR?
>
> The only redeeming factor of P2TRv2 is that it saves a few dozen witness
> bytes per input when using schnorr EC key spending, compared to P2MR
> spending. For low-frequency use cases like cold storage, that doesnt matter
> much. At current rates thats like 10 sats per input. For high frequency use
> cases where every vbyte counts like hot wallets, exchanges, mining payouts,
> etc, i have good news: P2TRv1 still exists and can be used just fine. You
> "just" need to make sure the coins are moved to a PQ address before a
> quantum computer attacks them. I'm assuming these high-frequency use case
> actors are online enough to take that last step when necessary.
>
> Thus i see P2MR as the superior choice to P2TRv2 even if P2TRv2 may be
> slightly more space efficient in the near-term. Thinking longer term, P2MR
> is the better choice.
>
> Thinking even further into the future, we have options for a sort of
> P2TR-style of address using isogenies, by hiding a commitment to a
> taproot-style script tree inside a public key curve (public keys in isogeny
> cryptosystems are represented by elliptic curves). Keypath spending would
> be via SQIsign (or other schemes). So don't worry, we are not stuck with
> only merkle trees forever. I'll elaborate more on this idea in a
> forthcoming article i have cooking on isogenies.
>
>
> > ZK proof-of-seedphrase
>
> If we were going to use a ZK proof to rescue quantum procrastinators, it
> should be proof of BIP32 hardened key derivation, and possibly also proof
> of pubkey hash preimage knowledge. This is strictly more general than a
> zero-knowledge proof of seed phrase, the arithmetization would be wayyy
> more efficient, and would recover more coins from more diverse wallet types.
>
> Also, there is no need for it to be a hefty zero-knowledge proof, like a
> STARK. Rescue could be deployed using a commit and reveal protocol, as has
> been discussed on the list previously (sorry, i dont have the link in front
> of me right now). The idea is that a sender can rescue frozen UTXOs using a
> commit/reveal sequence of transactions which ultimately proves the sender
> knew a BIP32 parent xpriv (or pubkey hash preimage) which controls the
> coins in question through hardened BIP32 CKD, which a CRQC shouldn't be
> able to forge.
>
> This would maximize rescue coverage while minimizing blockspace
> congestion, and could be done as a soft fork.
>
>
> -----
>
> I'm glad to see thoughtful discussion on the subject of how to handle a
> quantum freeze. But it is important to put this in perspective in the
> context of this thread: right now the number one most important thing -
> which we NEED to do if Bitcoin is to survive appearance of a CRQC - is to
> provide a standardized wallet address format which includes a secure
> fallback way to authenticate UTXOs if ECC is unsafe to use. We can debate
> about freezing or rescuing coins, or the philosophy of ownership, but these
> questions will not be decidable for years.
>
> What is decidable is this: how would you change Ethan's proposal, if at
> all? I'll remind everyone that currently it is limited only to adding two
> features: BIP360 P2MR addresses, and SLH-DSA opcodes. Those two changes are
> all we need in consensus to finally give hodlers an option to migrate.
>
>
> I've gone through and catalogued some of the feedback on Ethan's proposal.
> So far I've heard these material critiques:
>
>
> 1. Why not instead deploy covenant opcodes (TXHASH, CTV) and use them to
> implement commit/reveal?
>
> As i mentioned in my last message i don't think that is possible, at least
> not using the technique Erik linked. I'd be happy to be proven wrong here
> because that'd be fantastic news if true.
>
>
> 2. Why not use SHRINCS instead of SLH-DSA?
>
> Seems like a valid idea to me. SHRINCS would add implementation and UX
> complexity but it'd also make the fallback sig scheme scalable - a very
> nice property to have in the worst case scenario where a majority of users
> end up needing to sign with it. Philosophically i dislike statefulness in a
> cryptosystem, but maybe as a fallback it is an acceptable tradeoff.
>
>
> 3. Why not deploy GSR and let wallet devs roll their own crypto?
>
> As ethan pointed out, this would be bad for standardization and
> interoperability, and also requires GSR to be deployed as a pre-requisite.
> If GSR is activated and in-script signing schemes are standardized
> correctly, it could possibly be a suitable alternative to activating
> dedicated SLH-DSA opcodes.
>
>
> 4. Why not continue using P2TR and disable keypath spending later, rather
> than adding a whole new address format?
>
> As ethan pointed out, this depends on timing a future disabling soft fork
> correctly and will lead to FUD, avoidable debate, and confusion. It is also
> confiscatory, as it would freeze standardized keypath-only P2TR outputs
> which lack a script path.
>
>
> 5. Why not redeploy P2TR with a new segwit version number, which opts into
> a future keypath-disabling soft fork?
>
> Ethan and i have both made some compelling arguments as to why we should
> give the community a new address format which is totally decoupled from any
> PQ-vulnerable cryptography. If the increased fees of P2MR are an issue for
> high-frequency hot wallets, P2TR is still viable, at least until Q-day. As
> stated Ethan's proposal is more motivated by long term cold storage use
> cases. I consider a small increase in witness size to be an acceptable
> tradeoff for (speculative) quantum security, and the costs of clinging to
> those savings in the near-term to be unacceptable. Key-path spending may be
> reinvented in the future using other novel cryptosystems, with another new
> address format that depends on new cryptographic assumptions.
>
> -----
>
> I apologize if i missed anyone's feedback notes in this summary. Please
> correct me if i have!
>
> regards,
> conduition
>
>
> On Tuesday, February 17th, 2026 at 4:22 AM, 'conduition' via Bitcoin
> Development Mailing List <bitcoindev@googlegroups.com> wrote:
>
> Hi list, just wanted to pipe in on the subject of commit/reveal using
> OP_TXHASH. I don't think it is possible. The protocol link Erik posted (
> https://delvingbitcoin.org/t/a-quantum-resistance-script-only-using-op-ctv-op-txhash-and-no-new-signatures/2168
> ) seems to contradict itself. On one hand the author says phase zero
> doesn't commit to final CTV templates E & T. However it also says T & E are
> committed to via the P_anchor tapscript tree, which must be pinned by phase
> 0. So unless I'm misunderstanding, this technique seems to require a priori
> knowledge of template hashes T and E when creating the funding address and
> UTXO in phase 0, so this would not be viable as a PQ fallback spending
> path. Happy to be proven wrong.
>
> regards,
> conduition
>
>
>
> On Wednesday, February 11th, 2026 at 1:06 AM, Erik Aronesty <erik@q32.com>
> wrote:
>
>
>>
>> You'd still need BIP 360 P2MR (or P2TRD) since OP_TXHASH needs tapscript,
>> and the only available tapscript supporting output type, P2TR, isn't
>> quantum safe.
>>
>
> false, covenant based multistep secret-reveal spending paths don't rely on
> signatures at all
>
>>
>> I'm going to assume:
>> - you mean to use this commit-reveal for migrating between signature
>> algorithms, not for everyday use,
>>
>
> it can be used if "q day" happens. otherwise ignored.
>
>> - TXHASH is being used because you are waiting for the commitment to be
>> confirmed on-chain rather than lifeboat's out-of-band commitment system
>>
>
> it's used so you can commit to a spending constraint without committing to
> the final "as yet to be determined" quantum-safe destination:
> https://delvingbitcoin.org/t/a-quantum-resistance-script-only-using-op-ctv-op-txhash-and-no-new-signatures/2168
>
>> Once you post your commit-txn, but before it confirms, other parties can
>> post competing commit-txns that double spend your output. If one of
>> malicious transactions confirm, you must now wait for a timelock to expire
>> and then try to post your transaction.
>>
>
> agreed. they have to spend resources to attack your private key and the
> only thing they can do is "grief" using a timing attack with the results,
> rather than steal outright. a massive incentive difference.
>
>> They can block you again. Each time they burn some of you coins in fees.
>> Miners get the fees, so they might be incentivized to do this. Thus, we
>> must trust miners not to do this. Lifeboat doesn't have this issue since it
>> uses out-of-band commitments, but out-of-band commitments have their own
>> issues.
>>
>
> each time you use the reset-path, they have to re-attack a new key. very
> expensive just to grief a small amount of fees spread across all miners.
> sounds like science-fiction levels of compute.
>
> plus.... TX_HASH is simple and generally useful and there is no guarantee
> that q-day will even come
>
> --
> You received this message because you are subscribed to the Google Groups
> "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/CAJowKgL5okUA%3DDHSyUJfzdb6p_z5a6H_hN6NuhZo6R9ZYbJFUQ%40mail.gmail.com
> .
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/ByJc1I7sSQAMLnAzSHPi8KSSscU0qakPM2YI0qC6VBBOwzmYtQEW5NY6d80eLUCf7fmKxbdFlSuxm4RCoT5rtKT68Khdi2xjwYIu4B5e6BQ%3D%40proton.me
> .
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/GhzGKZ5zphDf7mFpC_PMD0Bn7-KIK14HXdCPLeB7HKvPBfDRVG8eUAlCKKLWcki6XDW0h0R1IQC5SS9B7jnMRS85GzOzcmCt9v5R3xoW4Js%3D%40proton.me
> <https://groups.google.com/d/msgid/bitcoindev/GhzGKZ5zphDf7mFpC_PMD0Bn7-KIK14HXdCPLeB7HKvPBfDRVG8eUAlCKKLWcki6XDW0h0R1IQC5SS9B7jnMRS85GzOzcmCt9v5R3xoW4Js%3D%40proton.me?utm_medium=email&utm_source=footer>
> .
>

--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAN7kyNizzKzDg4fVOGe976Xq%3DMLCpiAufZaJLkRV-AhhFW28_g%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 19380 bytes --]