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 <[email protected]> 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 <[email protected]> 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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/3BB9E83D-086E-4F6A-BE15-677D8589EA1E%40sprovoost.nl.
