From: Sjors Provoost <sjors@sprovoost.nl>
To: Nagaev Boris <bnagaev@gmail.com>, 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: Fri, 26 Jun 2026 13:06:09 +0200 [thread overview]
Message-ID: <3BB9E83D-086E-4F6A-BE15-677D8589EA1E@sprovoost.nl> (raw)
In-Reply-To: <CAFC_Vt7OfZ-rztFP5D5ycpxe3ZQOJJbY5cHgEk73OMYAmnDBjQ@mail.gmail.com>
Hi Boris and Pieter,
I agree that the potential for premature activation is a downside of Miner Lockdown. It could come with a very long window (years) between signalling and activation. That way users who consider it premature can mass migrate back to P2TR, only to return to P2TRv2 / P2TMR at a moment of their choosing.
In the other direction, there's a a positive incentive to not wait too long: the 100 block coinbase maturity makes them more vulnerable to short-range attacks (for P2TRv2, but not P2TMR).
I think it's important that a proposal involving the eventual trimming of its own spending paths, includes the activation mechanism(s) for such trimming. At least some of the mechanisms.
I'm also worried that miners don't want to carry such heavy burden of responsibility, and deal with political pressure (in both directions). In that case they would oppose inclusion of ML in the two-stage proposal, and that would be very useful to learn early on.
- Sjors
> Op 26 jun 2026, om 05:40 heeft Nagaev Boris <bnagaev@gmail.com> het volgende geschreven:
>
> 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.
> [...]
> 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.
[...]
>> 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)
>>
[...]
--
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/3BB9E83D-086E-4F6A-BE15-677D8589EA1E%40sprovoost.nl.
next prev parent reply other threads:[~2026-06-26 11:18 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
2026-06-26 11:06 ` Sjors Provoost [this message]
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=3BB9E83D-086E-4F6A-BE15-677D8589EA1E@sprovoost.nl \
--to=sjors@sprovoost.nl \
--cc=bitcoin-dev@wuille.net \
--cc=bitcoindev@googlegroups.com \
--cc=bnagaev@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