From: Nagaev Boris <bnagaev@gmail.com>
To: Pieter Wuille <bitcoin-dev@wuille.net>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Giving teeth to expected EC disabling: P2XX(-T)(-ML)
Date: Thu, 25 Jun 2026 22:40:53 -0500 [thread overview]
Message-ID: <CAFC_Vt7OfZ-rztFP5D5ycpxe3ZQOJJbY5cHgEk73OMYAmnDBjQ@mail.gmail.com> (raw)
In-Reply-To: <yHRpA2LEJ2AugT4W2KiWO3ggSims4GuHBkr6rWtE-e1uVC2wh3ZqD4bUDyxXq1iEuPrezhZZeqDoG7uBLNvjbW0sk_UTorI1Pkz6LcKhXRA=@wuille.net>
Hi Pieter,
I think Tripwire is an improvement to all "Later" versions of P2MR,
P2TRv2, and P2TRH. Given coin owners have pre-agreed to later
lockdown, having an upper bound does not harm.
For Miner Lockdown, I see a potential false-positive activation. A
large classical theft may happen, be misinterpreted as a CRQC event,
and miners may lock the EC path with the best intentions, but it turns
out to be a false alarm. Shouldn't there be a mechanism for
reactivation in this case? We have historical examples of bugs causing
large-scale or initially mysterious thefts: Milk Sad, Android
SecureRandom 2013, and the LuBian 2020 theft. A similar event in the
future could be confused with Q-day, and miners could push the button.
Can you elaborate on the scope of EC disabling, please? Does it
disable only the main EC path (e.g. key spend in the case of Taproot
v2) or all EC involving paths? What will happen to scripts using
something else in addition to EC? Some useful constructions may
include an EC opcode, e.g. hybrid EC-PQ signatures or HTLCs. Maybe it
makes sense to disable the main spending path and keep hash-protected
supplementary paths available?
Best,
Boris
On Thu, Jun 25, 2026 at 1:31 PM Pieter Wuille <bitcoin-dev@wuille.net> wrote:
>
> Hi all,
>
> In parallel to the threads[1][2][3] discussing the P2TRv2 and P2MR
> concepts, I'd like to talk about the possibility of codifying in the
> consensus rules the (expectation of) the disabling of EC opcodes/paths
> within the new output type.
>
> The motivation for this is that while P2TRv2 has a "soft" built-in
> expectation of a future softfork that will disable EC opcodes/paths (just
> within the new output type itself) at the right time, its consensus rules
> are identical to P2TR (with the exception of PQC opcodes, if those aren't
> also added to P2TR). Plans and intent of protocol designers are one thing,
> but the future ecosystem isn't beholden to those: the only certainty is the
> adopted consensus rules themselves. Without confidence that the intended
> disabling will happen, it becomes unclear what CRQC-resistance the P2TRv2
> type offers. Meanwhile, P2MR as formulated doesn't need/have such an
> expectation, but would still benefit from it, as users are otherwise
> restricted to (IMO) extremely onerous restrictions on public key sharing.
>
> To some extent, this is an unsolvable problem: we cannot codify plans that
> depend on outside-world conditions like CRQCs existing. Still,
> approximations exist which can be added as automatic triggers for this EC
> disabling, along with the new output type itself:
>
> * Tripwire (P2XX-T): use the presence of a NUMS point spend as trigger
> (suggested by Tadge Dryja[4]).
>
> Specifically, as part of the softfork definition, a NUMS point is
> picked. Whenever a transaction is mined whose input contains a successful
> "<NUMS> OP_CHECKSIG", EC opcodes/paths are disabled within the new
> output type, as of the next block.
>
> Note that the tripwire isn't intended as a replacement for the expected
> future EC-disabling softfork; instead, it puts an upper bound on that
> disabling.
>
> * Miner Lockdown (P2XX-ML): allow a hashrate majority/threshold to trigger
> the disabling, allowing a faster reaction time to urgent CRQC threats.
>
> Practically, this can be achieved by bundling the expected EC-disabling
> softfork with the softfork that introduces the new output type, but
> giving the disabling one a separate, and very long or infinite,
> activation window. This means that in addition to expecting the future
> ecosystem to decide when Q-day is too close, the hashrate majority is
> allowed to make that call too. (suggested offline by Sjors Provoost)
>
> * Combination (P2XX-T-ML): trigger EC disabling either through Tripwire, or
> through Miner Lockdown.
>
> I believe P2TR-T and P2MR-T are unambiguous improvements over P2TRv2 and
> P2MR respectively. This is because:
>
> * With Tripwire, anyone with a CRQC can, without permission, disable the EC
> paths/opcodes in the new output type for everyone. Because of that
> possibility, disabling is something all users of the new output type need
> to be prepared for at all times, and thus the later EC-disabling softfork
> cannot be considered confiscatory. That could otherwise be a reason to
> oppose the future EC-disabling softfork.
>
> Consider P2TR and P2TRv2. If there are no differences in consensus rules
> between them, it is worth asking why the future ecosystem should be
> expected to disable EC paths & opcodes in one but not the other, just
> based on earlier-stated plans. With Tripwire, disabling EC in P2TR-T is
> categorically non-confiscatory, making doing it there an objective
> choice.
>
> * Relatedly, for the same reason it likely convinces users and wallet
> developers to test, more seriously, the usability of the expected PQC
> paths, as not doing so inevitably means risking burning those coins. This
> is especially important for P2MR, which has some incentives to use it
> beyond CRQC-protecting coins.
>
> * The only downside I see is some additional technical complexity. The
> ability to sign with a NUMS point is an unequivocal proof that the
> secp256k1 ECDLP assumption no longer holds, and is thus a clear upper
> bound on when EC ought not to be used anymore. Note that this differs
> from a canary (an idea which has also been discussed) that uses a weaker
> curve, as the goal of those is to be predictive. The point here is
> specifically to just be an upper bound.
>
> To me, this makes both P2MR-T and P2TR-T more "Later"-style (as I've
> defined it in [5] and follow-ups) than P2MR and P2TRv2 respectively, which
> I consider an improvement for both. There still is an expectation of a
> later softfork that disables the EC paths/opcodes within the PQC output
> type, and thus the tripwire isn't actually expected to ever trigger. Still,
> I believe that its presence changes the game theory and incentives around
> usage of the output type, and future consensus changes.
>
> Of course, it cannot help with deciding what the right time for the
> EC-disabling softfork is, but it can help make it happen. The same is true
> for the Miner Lockdown idea. I'm a bit more hesitant about that, as it may
> be empowering the (collective of) miners too much. They always have the
> ability to just disallow EC spends of course, but the Miner Lockdown idea
> makes network nodes start enforcing the same rule too, making it
> irreversible. On the other hand, it is still opt-in (users deciding to move
> coins to the new output type), and this becomes them choosing to give
> miners a Lockdown button, which can presumably be used on shorter notice
> than the ecosystem can agree on a consensus change (even if it's
> pre-planned).
>
> I'd prefer to keep the discussion here just about adding the Tripwire
> and/or Miner Lockdown ideas, rather than MR vs TR, as I think this is
> orthogonal to the distinction between those.
>
> Thoughts?
>
> --
> Pieter
>
> [1]: https://groups.google.com/g/bitcoindev/c/Qy4gwAGTK2w/m/_CjQ8xvdAAAJ
> [2]: https://groups.google.com/g/bitcoindev/c/p8AVEmAtWdA/m/T7UWqgnvAAAJ
> [3]: https://delvingbitcoin.org/t/public-key-recovery-for-ec-leaves-in-p2mr-bip-360/2603
> [4]: https://groups.google.com/g/bitcoindev/c/8O857bRSVV8/m/8nr6I5NIAwAJ
> [5]: https://groups.google.com/g/bitcoindev/c/p8AVEmAtWdA/m/Gona1fr3AgAJ
>
> --
> 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/yHRpA2LEJ2AugT4W2KiWO3ggSims4GuHBkr6rWtE-e1uVC2wh3ZqD4bUDyxXq1iEuPrezhZZeqDoG7uBLNvjbW0sk_UTorI1Pkz6LcKhXRA%3D%40wuille.net.
--
Best regards,
Boris Nagaev
--
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/CAFC_Vt7OfZ-rztFP5D5ycpxe3ZQOJJbY5cHgEk73OMYAmnDBjQ%40mail.gmail.com.
next prev parent reply other threads:[~2026-06-26 9:41 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-25 17:42 [bitcoindev] Giving teeth to expected EC disabling: P2XX(-T)(-ML) Pieter Wuille
2026-06-26 3:40 ` Nagaev Boris [this message]
2026-06-26 11:06 ` Sjors Provoost
2026-06-26 14:10 ` Pieter Wuille
2026-06-26 18:20 ` 'conduition' via Bitcoin Development Mailing List
2026-06-27 4:33 ` Anthony Towns
2026-06-29 2:17 ` Antoine Riard
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=CAFC_Vt7OfZ-rztFP5D5ycpxe3ZQOJJbY5cHgEk73OMYAmnDBjQ@mail.gmail.com \
--to=bnagaev@gmail.com \
--cc=bitcoin-dev@wuille.net \
--cc=bitcoindev@googlegroups.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