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