From: Ethan Heilman <eth3rs@gmail.com>
To: Erik Aronesty <erik@q32.com>
Cc: Jonas Nick <jonasd.nick@gmail.com>, bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms
Date: Wed, 11 Feb 2026 11:37:39 -0500 [thread overview]
Message-ID: <CAEM=y+UNum_=1Me0Q=fBc7oS6s4i_GwZEw1Ad60S_efHOVnqMw@mail.gmail.com> (raw)
In-Reply-To: <CAJowKg+ruUmiwxJLppALCuGSRO0v+Jg0m2TeMrmzgKQYj-pQBg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5536 bytes --]
> i see so a minimal change to taproot would be a new version: “script
spend only” or similar.
BIP 360's P2MR (Pay-to-Merkle-Root) is P2TR but script spend only via a
simple and minimal change.
Thanks for working on commit-reveal -- also thanks to Tadge for lifeboat, I
think this line of research is worthwhile and helpful. Correct me if you
disagree, I think of commit-reveal as useful for the following case: Q-day
happens AND we have P2MR AND OP_TXHASH, but not OP_SLH_CHECKSIG,
commit-reveal might be the best option to migrate to a PQ signature scheme.
I am pursuing the P2MR + OP_SLH_CHECKSIG approach this approach is the
least disruptive to how people use Bitcoin today and would be simpler for
wallets to support (SLH only requires signing a single transaction vs. two
transactions and having to handle griefing/reset).
In both cases we want BIP 360's P2MR. I'd also like OP_TXHASH and
OP_SLH_CHECKSIG as well.
I'm using OP_SLH_CHECKSIG as a placeholder here, if you like
OP_SHRINCS_CHECKSIG better, you could also do P2MR + OP_SHRINCS_CHECKSIG
On Wed, Feb 11, 2026 at 2:25 AM Erik Aronesty <erik@q32.com> wrote:
> i see so a minimal change to taproot would be a new version: “script spend
> only” or similar.
>
> On Tue, Feb 10, 2026 at 6:41 PM Ethan Heilman <eth3rs@gmail.com> wrote:
>
>> >> You'd still need BIP 360 P2MR (or P2TRD) since OP_TXHASH needs
>> tapscript
>> > false, covenant based multistep secret-reveal spending paths don't
>> rely on signatures at all
>>
>> P2TR has a public key baked into it via the key spend path. This key path
>> spend bypasses any covenant or script constraints. The attacker does not
>> need to see a value spend to break the key path spend. This means a quantum
>> attacker can break the nums point in key spend path of the initial output
>> and the AnchorPublishTx output and then just taking all the coins [0].
>>
>> > agreed. they have to spend resources to attack your private key and
>> the only thing they can do is "grief" using a timing attack with the
>> results, rather than steal outright. a massive incentive difference.
>>
>> Ok, so a core assumption you are making here is that a CRQC isn't
>> powerful enough for recovering signing keys to be effectively free. This is
>> likely to be true at the early stages of CRQC, but this assumption may not
>> hold forever. If ECC is mathematically broken via a classical attack this
>> assumption might not hold at all. I'm attempting to address both quantum
>> and classical breaks.
>>
>> > TX_HASH is simple and generally useful and there is no guarantee that
>> q-day will even come
>>
>> TX_HASH is great!
>>
>> [0]: As originally noted here:
>> https://delvingbitcoin.org/t/a-quantum-resistance-script-only-using-op-ctv-op-txhash-and-no-new-signatures/2168/4
>>
>> On Tue, Feb 10, 2026 at 7:19 PM Erik Aronesty <erik@q32.com> wrote:
>>
>>>
>>>>
>>>> You'd still need BIP 360 P2MR (or P2TRD) since OP_TXHASH needs
>>>> tapscript, and the only available tapscript supporting output type, P2TR,
>>>> isn't quantum safe.
>>>>
>>>
>>> false, covenant based multistep secret-reveal spending paths don't rely
>>> on signatures at all
>>>
>>>
>>>>
>>>> I'm going to assume:
>>>> - you mean to use this commit-reveal for migrating between signature
>>>> algorithms, not for everyday use,
>>>>
>>>
>>> it can be used if "q day" happens. otherwise ignored.
>>>
>>>
>>>> - TXHASH is being used because you are waiting for the commitment to be
>>>> confirmed on-chain rather than lifeboat's out-of-band commitment system
>>>>
>>>
>>> it's used so you can commit to a spending constraint without committing
>>> to the final "as yet to be determined" quantum-safe destination:
>>> https://delvingbitcoin.org/t/a-quantum-resistance-script-only-using-op-ctv-op-txhash-and-no-new-signatures/2168
>>>
>>>
>>>
>>>> Once you post your commit-txn, but before it confirms, other parties
>>>> can post competing commit-txns that double spend your output. If one of
>>>> malicious transactions confirm, you must now wait for a timelock to expire
>>>> and then try to post your transaction.
>>>>
>>>
>>> agreed. they have to spend resources to attack your private key and the
>>> only thing they can do is "grief" using a timing attack with the results,
>>> rather than steal outright. a massive incentive difference.
>>>
>>>
>>>> They can block you again. Each time they burn some of you coins in
>>>> fees. Miners get the fees, so they might be incentivized to do this. Thus,
>>>> we must trust miners not to do this. Lifeboat doesn't have this issue since
>>>> it uses out-of-band commitments, but out-of-band commitments have their own
>>>> issues.
>>>>
>>>
>>> each time you use the reset-path, they have to re-attack a new key.
>>> very expensive just to grief a small amount of fees spread across all
>>> miners. sounds like science-fiction levels of compute.
>>>
>>>
>>> plus.... TX_HASH is simple and generally useful and there is no
>>> guarantee that q-day will even come
>>>
>>
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAEM%3Dy%2BUNum_%3D1Me0Q%3DfBc7oS6s4i_GwZEw1Ad60S_efHOVnqMw%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 7976 bytes --]
next prev parent reply other threads:[~2026-02-11 18:43 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-09 14:20 Ethan Heilman
2026-02-10 8:53 ` Jonas Nick
2026-02-10 16:44 ` Ethan Heilman
[not found] ` <CAJowKg+WJLAJoMhyhVfkC9OSdks5jBieDWty9ce-Qju-84URFA@mail.gmail.com>
2026-02-10 23:13 ` Ethan Heilman
2026-02-11 0:19 ` Erik Aronesty
2026-02-11 2:40 ` Ethan Heilman
2026-02-11 7:25 ` Erik Aronesty
2026-02-11 16:37 ` Ethan Heilman [this message]
2026-02-17 4:13 ` 'conduition' via Bitcoin Development Mailing List
2026-02-17 7:39 ` 'conduition' via Bitcoin Development Mailing List
2026-02-19 14:35 ` Garlo Nicon
2026-02-20 1:41 ` Alex
2026-02-20 18:48 ` Erik Aronesty
2026-02-23 14:00 ` 'conduition' via Bitcoin Development Mailing List
2026-02-23 19:08 ` Erik Aronesty
2026-02-23 21:42 ` Ethan Heilman
2026-02-24 0:12 ` Alex
2026-02-25 10:43 ` Javier Mateos
2026-02-26 13:24 ` 'Mikhail Kudinov' via Bitcoin Development Mailing List
2026-02-26 15:51 ` Matt Corallo
2026-02-27 15:18 ` 'Mikhail Kudinov' via Bitcoin Development Mailing List
2026-02-27 19:31 ` 'conduition' via Bitcoin Development Mailing List
2026-03-01 12:24 ` 'Mikhail Kudinov' via Bitcoin Development Mailing List
2026-03-01 21:28 ` Alex
2026-02-11 18:53 ` Matt Corallo
2026-02-11 22:57 ` Ethan Heilman
2026-02-12 14:55 ` Matt Corallo
2026-02-12 15:35 ` Alex
2026-02-12 19:20 ` Matt Corallo
2026-02-12 18:08 ` Ethan Heilman
2026-02-12 19:13 ` Matt Corallo
2026-02-12 20:35 ` Ethan Heilman
2026-02-12 20:43 ` Matt Corallo
2026-02-12 15:13 ` Alex
2026-02-12 19:16 ` Matt Corallo
2026-02-12 15:36 ` waxwing/ AdamISZ
2026-02-12 19:35 ` Matt Corallo
2026-02-12 19:43 ` Matt Corallo
2026-02-14 12:39 ` waxwing/ AdamISZ
2026-02-15 12:12 ` Matt Corallo
2026-02-10 21:51 ` 'Brandon Black' via Bitcoin Development Mailing List
2026-02-10 22:19 ` Ethan Heilman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAEM=y+UNum_=1Me0Q=fBc7oS6s4i_GwZEw1Ad60S_efHOVnqMw@mail.gmail.com' \
--to=eth3rs@gmail.com \
--cc=bitcoindev@googlegroups.com \
--cc=erik@q32.com \
--cc=jonasd.nick@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox