* [bitcoindev] Giving teeth to expected EC disabling: P2XX(-T)(-ML)
@ 2026-06-25 17:42 Pieter Wuille
2026-06-26 3:40 ` Nagaev Boris
2026-06-27 4:33 ` Anthony Towns
0 siblings, 2 replies; 7+ messages in thread
From: Pieter Wuille @ 2026-06-25 17:42 UTC (permalink / raw)
To: Bitcoin Development Mailing List
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoindev] Giving teeth to expected EC disabling: P2XX(-T)(-ML)
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
2026-06-26 14:10 ` Pieter Wuille
2026-06-27 4:33 ` Anthony Towns
1 sibling, 2 replies; 7+ messages in thread
From: Nagaev Boris @ 2026-06-26 3:40 UTC (permalink / raw)
To: Pieter Wuille; +Cc: Bitcoin Development Mailing List
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoindev] Giving teeth to expected EC disabling: P2XX(-T)(-ML)
2026-06-26 3:40 ` Nagaev Boris
@ 2026-06-26 11:06 ` Sjors Provoost
2026-06-26 14:10 ` Pieter Wuille
1 sibling, 0 replies; 7+ messages in thread
From: Sjors Provoost @ 2026-06-26 11:06 UTC (permalink / raw)
To: Nagaev Boris, Pieter Wuille; +Cc: Bitcoin Development Mailing List
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoindev] Giving teeth to expected EC disabling: P2XX(-T)(-ML)
2026-06-26 3:40 ` Nagaev Boris
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
1 sibling, 1 reply; 7+ messages in thread
From: Pieter Wuille @ 2026-06-26 14:10 UTC (permalink / raw)
To: Nagaev Boris; +Cc: Bitcoin Development Mailing List
Hi Boris,
See responses inline below.
On Friday, June 26th, 2026 at 5:41 AM, Nagaev Boris wrote:
> 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.
I agree that's a concern, but of course, if this happens, no coins are
lost, just inefficient to access. As Sjors mentions, it's possible for
users to move back to P2TR temporarily, but that of course goes counter to
the CRQC-protection goal, and if it happens at scale, chain capacity
problems may cause chaos.
Adding the ability to revert is a possibility, but I'm not sure it's all
that much better than realizing there is also the possibility of adding a
new P2TRv3 / P2MRv2 / ... that is in a pre-lockdown state?
> 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?
I agree with Antoine that it necessarily must disable all usage of EC
inside the new output type, so that includes taproot key path spending (if
present), and making any execution of an OP_CHECK* opcode with a non-empty
signature for an EC pubkey cause the transaction to be invalid. Anything
else falls short of the goal of making it possible for users to keep
sharing public keys. This should be the case for all disabling, whether
through Tripwire, Miner Lockdown, or a future softfork.
> 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?
My thinking is that hybrid signature schemes, if desired, should be dealt
with at the opcode level, and not the script level. That is, there would be
(only) an OP_CHECKHYBRIDECSQISIGN opcode, not an expectation to use both
OP_CHECKSIG and OP_CHECKSQISIGN. My reason for this is that I think the
question of what level of security is appropriate (i.e., whether schemes
should be protected with a layer of EC hybridity) should be a consensus
decision, not an individual one.
Thinking about it, maybe that means it makes sense to completely separate
PQC scripts and (pure-)EC scripts at the script leaf level, by having
separate script leaf versions for them. That rules out some potentially
useful ways of using conditionals that have PQC and pure-EC branches, but
those do seem pretty error prone (as mixing the two within one execution
trace would be unusable post EC-disabling).
Practically, my thinking is that due to the low cryptographic assumptions
needed for hash-based schemes, those wouldn't need hybridization with EC
(though the statefulness of some variants is worrying). I don't think
schemes relying on other assumptions feel ready in terms of confidence for
adding to Bitcoin to me, but that can change.
Cheers,
--
Pieter
--
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/A54QKCjvV0Tnk26mHFZrbAKPHdYh6Ol1XWTetB3y1skuSaoLtBZnvNlYD2hSqQtp6oYt85rqvK4w-JMsDJOm3nPrYgkN94E9jlxxCPZsKZw%3D%40wuille.net.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoindev] Giving teeth to expected EC disabling: P2XX(-T)(-ML)
2026-06-26 14:10 ` Pieter Wuille
@ 2026-06-26 18:20 ` 'conduition' via Bitcoin Development Mailing List
0 siblings, 0 replies; 7+ messages in thread
From: 'conduition' via Bitcoin Development Mailing List @ 2026-06-26 18:20 UTC (permalink / raw)
To: Pieter Wuille; +Cc: Nagaev Boris, Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 10903 bytes --]
Hi Pieter,
Thanks for voicing this, I'm generally very supporting of the tripwire idea. It's an easy win for any PQ output type.
I have a few comments on the specifics.
> 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.
Mining an on-chain spend isn't the only option. The signature by (or discrete log of) the NUMS point is itself a sufficient and succinct proof that EC spending ought to be disabled. We don't need a trustless "honeypot"/"reward"/"bounty" for the CRQC, since we're already assuming the CRQC is cooperative. We don't need the "tripwire proof" to be included on-chain except for posterity (i.e. nodes bootstrapping after Q-day, to know when to enact the new consensus rules retroactively). All a validator node today needs is to see the signature/discrete log of the NUMS point, anywhere, at any time, to know that EC spending ought to be disabled immediately.
It could be in an OP_RETURN, it could be a new field in a block, it could be a simple P2P message or just seeing a TX containing the tripwire proof appear in the mempool. Maybe requiring the tripwire proof to be mined is simple to implement for validators, but relying on that alone runs the risk of miners censoring or purposefully delaying the inclusion of the tripwire proof in a block. So it might be worth the extra complexity engineering of a more highly reactive solution.
I'm not sure what the best option here is yet, but I just wanted to point out the tripwire doesn't have to be a UTXO spend, and we should discuss more options and their trade-offs.
> Miner Lockdown (P2XX-ML): allow a hashrate majority/threshold to trigger the disabling, allowing a faster reaction time to urgent CRQC threats.
I'll echo the others' concerns here about early activation, and add that miners may actually be incentivized to trigger this activation early if given the chance, since doing so will massively pump their fee revenue (though perhaps at a cost to the price of Bitcoin itself). This could be more of a concern as the subsidy drops lower and miners with sunk cost seek to recoup their up-front hardware investment.
Generally I think this is a good idea though, and might be worth the risk especially because, as you stated, early activation will not confiscate any meaningful amount of coins. But it should also be possible for nodes to reject a bad-faith early activation.
The more important question is, how do you propose to technically achieve this? How does "majority hashpower" enact the disabling? My fear is that the reaction time will actually be very slow, because for us to measure "majority hashpower" we typically measure this over an epoch of many blocks. Otherwise a random minority miner could luck their way into a few blocks that signal for EC disabling, and so trigger the fork early.
The activation window would need to be spread out, and the further it is spread out the less time miners have to react, if they even react at all.
> I agree with Antoine that it necessarily must disable all usage of EC inside the new output type, so that includes taproot key path spending (if present), and making any execution of an OP_CHECK* opcode with a non-empty signature for an EC pubkey cause the transaction to be invalid. Anything else falls short of the goal of making it possible for users to keep sharing public keys. This should be the case for all disabling, whether through Tripwire, Miner Lockdown, or a future softfork.
This will confiscate coins held in hybrid scripts and in multisigs whose parties use different sig-schemes, e.g. <ec_pubkey> CHECKSIG <pq_pubkey> CHECKSIG.
I would suggest to enforce the disabling by running spend validation as normal, but failing at the end if EC-checksig operations have occurred without any PQ-checksig ops. This also implicitly disables P2TR-style key-spending and Boris' EC recovery scheme in P2TRH and P2MR, because such spends wouldn't involve a PQ signature.
> My thinking is that hybrid signature schemes, if desired, should be dealt with at the opcode level, and not the script level. That is, there would be (only) an OP_CHECKHYBRIDECSQISIGN opcode, not an expectation to use both OP_CHECKSIG and OP_CHECKSQISIGN.
>
> Practically, my thinking is that due to the low cryptographic assumptions needed for hash-based schemes, those wouldn't need hybridization with EC (though the statefulness of some variants is worrying).
In the SHRINCS proposal we elect not to introduce a hybrid EC+PQ signature scheme, for a few reasons:
- Complexity & fragility. A hybrid scheme necessitates a brand new Schnorr signature scheme because combiners like Bird-of-Prey don't use Schnorr as a black-box. Expands the scope of implementation a lot.
- Lack of value. Strong unforgability (one of the main selling points of hybridization) is not security-critical because witnesses don't affect TXIDs anymore. At best a hybrid scheme would provide a minor ~5%-10% improvement in witness size over a naive scripting approach, and this is still less efficient than keeping keys compartmentalized in isolated spending paths.
- Redundancy. Deploying SHRINCS as a standalone opcode is already needed for post-Q-day spending, so taking that opcode as a-given, users will already have access to hybridization techniques by using hybrid scripts.
- Security. Standalone SHRINCS uses fewer cryptographic assumptions than BIP340. Adding Schnorr hybridization thus hedges only against implementation flaws or state reuse, both of which can be effectively mitigated against.
We thus concluded that deploying a hybrid scheme doesn't seem to offer much unique value, and comes at the expense of great risk and effort in adding a new checksig algorithm, which very few people will use anyway since they have much cheaper options (separate leaf scripts).
I suspect hybrid script users will exist, but will likely be limited to major custodians, high-security vaults, and other such address-reusers. Dedicated hybrid signature algorithms may be desirable in the future with other signature schemes, but I doubt we'll be doing this with SHRINCS anytime soon.
regards,
conduition
On Friday, June 26th, 2026 at 8:14 AM, Pieter Wuille <bitcoin-dev@wuille.net> wrote:
> Hi Boris,
>
> See responses inline below.
>
> On Friday, June 26th, 2026 at 5:41 AM, Nagaev Boris wrote:
>
> > 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.
>
> I agree that's a concern, but of course, if this happens, no coins are
> lost, just inefficient to access. As Sjors mentions, it's possible for
> users to move back to P2TR temporarily, but that of course goes counter to
> the CRQC-protection goal, and if it happens at scale, chain capacity
> problems may cause chaos.
>
> Adding the ability to revert is a possibility, but I'm not sure it's all
> that much better than realizing there is also the possibility of adding a
> new P2TRv3 / P2MRv2 / ... that is in a pre-lockdown state?
>
> > 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?
>
> I agree with Antoine that it necessarily must disable all usage of EC
> inside the new output type, so that includes taproot key path spending (if
> present), and making any execution of an OP_CHECK* opcode with a non-empty
> signature for an EC pubkey cause the transaction to be invalid. Anything
> else falls short of the goal of making it possible for users to keep
> sharing public keys. This should be the case for all disabling, whether
> through Tripwire, Miner Lockdown, or a future softfork.
>
> > 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?
>
> My thinking is that hybrid signature schemes, if desired, should be dealt
> with at the opcode level, and not the script level. That is, there would be
> (only) an OP_CHECKHYBRIDECSQISIGN opcode, not an expectation to use both
> OP_CHECKSIG and OP_CHECKSQISIGN. My reason for this is that I think the
> question of what level of security is appropriate (i.e., whether schemes
> should be protected with a layer of EC hybridity) should be a consensus
> decision, not an individual one.
>
> Thinking about it, maybe that means it makes sense to completely separate
> PQC scripts and (pure-)EC scripts at the script leaf level, by having
> separate script leaf versions for them. That rules out some potentially
> useful ways of using conditionals that have PQC and pure-EC branches, but
> those do seem pretty error prone (as mixing the two within one execution
> trace would be unusable post EC-disabling).
>
> Practically, my thinking is that due to the low cryptographic assumptions
> needed for hash-based schemes, those wouldn't need hybridization with EC
> (though the statefulness of some variants is worrying). I don't think
> schemes relying on other assumptions feel ready in terms of confidence for
> adding to Bitcoin to me, but that can change.
>
> Cheers,
>
> --
> Pieter
>
> --
> 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/A54QKCjvV0Tnk26mHFZrbAKPHdYh6Ol1XWTetB3y1skuSaoLtBZnvNlYD2hSqQtp6oYt85rqvK4w-JMsDJOm3nPrYgkN94E9jlxxCPZsKZw%3D%40wuille.net.
>
--
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/Jj-Ozzq4OMo2XaP_Drftu_n7gmEHWC_Dw2bToW9hI8vId-BN3y4hmQSaHh5JY1xTonTyBWKa17vzNH4GMYTkM-CiFw5ZNwRFATdc3OE_lLk%3D%40proton.me.
[-- Attachment #1.2: publickey - conduition@proton.me - 0x474891AD.asc --]
[-- Type: application/pgp-keys, Size: 649 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 343 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoindev] Giving teeth to expected EC disabling: P2XX(-T)(-ML)
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-27 4:33 ` Anthony Towns
2026-06-29 2:17 ` Antoine Riard
1 sibling, 1 reply; 7+ messages in thread
From: Anthony Towns @ 2026-06-27 4:33 UTC (permalink / raw)
To: Pieter Wuille; +Cc: Bitcoin Development Mailing List
On Thu, Jun 25, 2026 at 05:42:35PM +0000, Pieter Wuille wrote:
> * 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.
A slight variant of this approach would be to have a 128 byte value
"aRsm", such that P = N+a*G, N is the BIP-341 NUMS point, and Rs is a
BIP340 signature of m by P. That would allow the victim of post-quantum
theft via a key-path spend of a BIP341 NUMS IPK to trigger the tripwire,
in addition to someone who has direct access to a CRQC.
I think it could make sense to have the tripwire be included in the
block via the coinbase witness commitment output, rather than having it
be locked to a transaction, so you only having to check the coinbase for
the magic rather than every transaction. That would require a separate
P2P message to relay the necessary ECDL-break proof to miners, and would
probably need stratumv2 or a getblocktemplate update in order for the node
to be able to tell pools to actually include that info in the coinbase.
> * Miner Lockdown (P2XX-ML): allow a hashrate majority/threshold to trigger
> the disabling, allowing a faster reaction time to urgent CRQC threats.
> 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.
Some potential ways of making that less dangerous:
* Have it require a 100% signalling threshold, instead of 90%/95%
* Have it have a longer signalling period (4032 blocks?)
* Have it be continually soft-forked out (URSF-style):
a) 100% signalling activates it, at any time
b) as at 2026-07-01, 100% signalling is invalid prior to 2026-12-31
c) as at 2026-10-01, 100% signalling is invalid prior to 2026-03-31
d) as at 2027-01-01, 100% signalling is invalid prior to 2026-06-30
e) as at 2027-04-01, danger signs! 100% signalling remains valid after
2026-06-30
f) as at 2027-07-01, signalling actually starts
(alternatively, if three to six months lead time was too long,
a secondary soft-fork could be done on as soon as the danger
signs appear that indepdently disables EC spends immediately,
and also forces 100% signalling from 2027-07-01 for backwards
compatibility)
Cheers,
aj
--
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/aj9SkwXqdRbuVZxH%40erisian.com.au.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoindev] Giving teeth to expected EC disabling: P2XX(-T)(-ML)
2026-06-27 4:33 ` Anthony Towns
@ 2026-06-29 2:17 ` Antoine Riard
0 siblings, 0 replies; 7+ messages in thread
From: Antoine Riard @ 2026-06-29 2:17 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 6106 bytes --]
Hi Pieter,
Thanks for your work on this subject.
While I was reading your explanation of the technical idea of
disabling EC paths, notably of miner lockdown, it came to my
mind, that I'm not confident that what you're proposing can
even be made technically robust.
If I'm understanding correctly your proposal, e.g for the tripwire
idea, a well-constructed nothing-under-my-sleeve point would be
picked up [0] and then used as an automatic trigger to disable the
new output type (e.g P2MR).
The real problem is more while the restriction would be introduced
as a soft fork, i.e restraining the validity space of the consensus
information space with new verification rules, due to the numerous
hooks introduced by P2TR (the annex, the leaves versioning, etc)
re-employed directly by P2MR.
Based on those hooks, I could see how a majority collective of miners
could re-introduce a soft-fork to re-enable the validity of the
EC-disabled paths to allow the coins to be spent by a CQRC actor,
(or whatever a cartel of CRQC actors lobbying a collective of miners).
Saying that we should just assume the 51% of miners acting for the
long term interest of the network at all times is a not a serious
security assumption. It might have to be some astute designed soft-fork
with a layer of indirection to re-introduce the coins, but frankly
I don't see how you can prevent massive "unfreeze" at a latter chain
"time" of the activation of your tripwire idea, if you can assume
that a (even transient) majority of miners might act in coordination with
a cartel of CQRCs.
I did echo in the past my opposition to "freeze" the coins on the mail
thread you're mentioning, so of course I might look on your proposal
with a more adversarial lense. I do note at least the idea to make the EC
disable wrapped in P2MR only, somehow that would be introducing an opt-in
mechanism for the users and not applying the tripwire disablement to users
who do not agree with this consensus rule for their coins.
Back to the central point, in a consensus world where there are many
upgradeability consensus rules, and as you're observing yourself we
cannot predict what would a collective of miners in the future, I do
not see how a EC "forever" disable path can be implemented robustly.
There is something that doesn't work in terms of game theory.
If the miners are economically rational actors, and it's technically
possible to design a soft-fork to re-introduce the "freeze" coins
why the miners are not going to collude with CRQC actors, if a CQRC
machine ever becomes a reality...
Best,
Antoine
OTS hash: 0c4f7a46103facb2e7e49586d7e8a267be3c7cb611db5961f306aaea19c332ac
[0] A cryptographically-leaning mind can note the first difficulty
here. Quid if it's not a "real" nothing-under-my-sleeve point...
Le Saturday, June 27, 2026 à 10:58:42 AM UTC+1, Anthony Towns a écrit :
> On Thu, Jun 25, 2026 at 05:42:35PM +0000, Pieter Wuille wrote:
> > * 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.
>
> A slight variant of this approach would be to have a 128 byte value
> "aRsm", such that P = N+a*G, N is the BIP-341 NUMS point, and Rs is a
> BIP340 signature of m by P. That would allow the victim of post-quantum
> theft via a key-path spend of a BIP341 NUMS IPK to trigger the tripwire,
> in addition to someone who has direct access to a CRQC.
>
> I think it could make sense to have the tripwire be included in the
> block via the coinbase witness commitment output, rather than having it
> be locked to a transaction, so you only having to check the coinbase for
> the magic rather than every transaction. That would require a separate
> P2P message to relay the necessary ECDL-break proof to miners, and would
> probably need stratumv2 or a getblocktemplate update in order for the node
> to be able to tell pools to actually include that info in the coinbase.
>
> > * Miner Lockdown (P2XX-ML): allow a hashrate majority/threshold to
> trigger
> > the disabling, allowing a faster reaction time to urgent CRQC threats.
>
> > 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.
>
> Some potential ways of making that less dangerous:
>
> * Have it require a 100% signalling threshold, instead of 90%/95%
> * Have it have a longer signalling period (4032 blocks?)
> * Have it be continually soft-forked out (URSF-style):
> a) 100% signalling activates it, at any time
> b) as at 2026-07-01, 100% signalling is invalid prior to 2026-12-31
> c) as at 2026-10-01, 100% signalling is invalid prior to 2026-03-31
> d) as at 2027-01-01, 100% signalling is invalid prior to 2026-06-30
> e) as at 2027-04-01, danger signs! 100% signalling remains valid after
> 2026-06-30
> f) as at 2027-07-01, signalling actually starts
> (alternatively, if three to six months lead time was too long,
> a secondary soft-fork could be done on as soon as the danger
> signs appear that indepdently disables EC spends immediately,
> and also forces 100% signalling from 2027-07-01 for backwards
> compatibility)
>
> Cheers,
> aj
>
--
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/5f59804c-6a3b-41e7-9733-6c253353847an%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 7073 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2026-06-29 2:32 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox