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

'conduition' via Bitcoin Development Mailing List
2026-02-17T04:23:06Z

[-- Attachment #1.1.1: Type: text/plain, Size: 3742 bytes --]

Hi list, just wanted to pipe in on the subject of commit/reveal using OP_TXHASH. I don't think it is possible. The protocol link Erik posted ( https://delvingbitcoin.org/t/a-quantum-resistance-script-only-using-op-ctv-op-txhash-and-no-new-signatures/2168 ) seems to contradict itself. On one hand the author says phase zero doesn't commit to final CTV templates E & T. However it also says T & E are committed to via the P_anchor tapscript tree, which must be pinned by phase 0. So unless I'm misunderstanding, this technique seems to require a priori knowledge of template hashes T and E when creating the funding address and UTXO in phase 0, so this would not be viable as a PQ fallback spending path. Happy to be proven wrong.

regards,
conduition

On Wednesday, February 11th, 2026 at 1:06 AM, Erik Aronesty <erik@q32.com> wrote:

> >

> >

> > You'd still need BIP 360 P2MR (or P2TRD) since OP_TXHASH needs tapscript, and the only available tapscript supporting output type, P2TR, isn't quantum safe.
>

>

> false, covenant based multistep secret-reveal spending paths don't rely on signatures at all
>

> >

> > I'm going to assume:
> > - you mean to use this commit-reveal for migrating between signature algorithms, not for everyday use,
>

>

> it can be used if "q day" happens. otherwise ignored.
>

> > - TXHASH is being used because you are waiting for the commitment to be confirmed on-chain rather than lifeboat's out-of-band commitment system
>

>

> it's used so you can commit to a spending constraint without committing to the final "as yet to be determined" quantum-safe destination: https://delvingbitcoin.org/t/a-quantum-resistance-script-only-using-op-ctv-op-txhash-and-no-new-signatures/2168
>

> > Once you post your commit-txn, but before it confirms, other parties can post competing commit-txns that double spend your output. If one of malicious transactions confirm, you must now wait for a timelock to expire and then try to post your transaction.
>

>

> agreed. they have to spend resources to attack your private key and the only thing they can do is "grief" using a timing attack with the results, rather than steal outright. a massive incentive difference.
>

> > They can block you again. Each time they burn some of you coins in fees. Miners get the fees, so they might be incentivized to do this. Thus, we must trust miners not to do this. Lifeboat doesn't have this issue since it uses out-of-band commitments, but out-of-band commitments have their own issues.
>

>

> each time you use the reset-path, they have to re-attack a new key. very expensive just to grief a small amount of fees spread across all miners. sounds like science-fiction levels of compute.
>

> plus.... TX_HASH is simple and generally useful and there is no guarantee that q-day will even come
>

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

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

[-- Attachment #1.1.2.1: Type: text/html, Size: 6703 bytes --]

[-- Attachment #1.2: publickey - conduition@proton.me - 0x474891AD.asc --]
[-- Type: application/pgp-keys, Size: 649 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 343 bytes --]