Re: [bitcoindev] Giving teeth to expected EC disabling: P2XX(-T)(-ML)

[Pieter Wuille <bitcoin-dev@wuille.net>]

Hi list,

Some responses inline below.

On Friday, June 26th, 2026 at 2:20 PM, conduition <conduition@proton.me> wrote:

> 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.

There are multiple variations of what the tripwire proof could look like, and I don't think the details matter as much. However, it must be part of the chain or it's not available to consensus rules. Just seeing a ECDLP breakage proof is not enough, because enforcing nodes need to be in agreement about which blocks it applies to. And without being in the chain, there is no way to guarantee all nodes see the proof at the same time w.r.t. blocks, and discrepancies will leak to forks.

The options I know of:

* Using a spend of a known-to-be-NUMS transaction output (as my original mail proposed). I like this because it needs no infrastructure, and has no DoS concerns as it's just a normal transaction.

* Just publishing the DLP in a transaction (e.g. OP_RETURN with a specific marker). This is smaller than a full transaction input + signature.

* Similarly, but publishing in the coinbase, and requiring relay using a separate message. Less places a node needs to check, but I'm concerned about the difficulty of testing infrastructure that relay of such a message works.

* Either of the two above options, but with AJ's (sig + msg + tweak) proof form, which could be used to prove P2TR key-path spends with NUMS internal key by unknowing malicious CRQCs. It's neat, but I'm not sure catering to non-cooperative CRQCs is all that relevant, because (a) if thefts are happening, I think it's all too late anyway and (b) Malicious CRQCs aren't likely to go after P2TR outputs first, probably, including for this reason. Maybe it discourages them from stealing P2TR though, which may be a reason to consider it...

> 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.

That is a fair concern, but it's inevitable. Miners are by definition the decider of the ordering of events as far as the consensus rules are concerned. This includes when the trigger happens.

> > 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.

That's a fair concern. A related one is that if the activation of the trigger is at a time with a juicy mempool full of ECC spends, it may encourage miners to not include the trigger, or if one does, for others to reorg it. I think this can partially mitigated by having a delay of something in the order of days between activation and actual enforcement (for both tripwire and miner lockdown).

> 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.

BIP9, with modified parameters, probably? It'd be conditional on the consensus change that introduces the P2XX-ML output type, which would be the real softfork activation. The lockdown just reuses the same signalling infrastructure, but isn't a consensus change. I haven't really thought about what the parameters need to look like.

> 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'm not sure what you mean here.

> 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.

I don't think self-crafted hybrid schemes should be something to cater to, but that approach works, indeed. PQC scripts could also be just a separate script leaf version, which has no ECC opcodes from the start.

> 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 agree that SHRINCS doesn't need hybridization.

On Saturday, June 27th, 2026 at 12:33 AM, Anthony Towns <aj@erisian.com.au> wrote:

> 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.

Indeed, I had considered something similar, but see above for why I'm not convinced supporting non-cooperative CRQCs is that useful.

Also, in my view the tripwire isn't really a security feature on itself (it's not expected to trigger...), but more something that sets expectations around the output type for prospective users.

In that sense, the question is really whether supporting non-cooperative CRQCs helps set that expectation more than only cooperative ones, which are definitely easier to support.

> 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.

I worry this is untestable, really. You'd need things like fake-tripwires to be supported through the same message which don't require an ECDLP break, and still propagate. And then that needs DoS protection measures, and ...

On Sunday, June 28th, 2026 at 10:31 PM, Antoine Riard <antoine.riard@gmail.com> wrote:

> [0] A cryptographically-leaning mind can note the first difficulty here. Quid if it's not a "real" nothing-under-my-sleeve point... Show original message

Due to EC's random self-reducibility, if an attacker has a non-negligible change of finding the DLP of a randomly chosen point, they can do that for any point. It of course needs to be a random point, but hash-to-curve achieve that.

The BIP341 NUMS point (which I suggest using in this context) is the point whose X coordinate is the SHA256 hash of the generator point G. This guarantees that the NUMS point cannot predate G (if it did, it would be possible in theory that secp256k1's designers actually chose G in function of what we call that NUMS point, giving it a DLP known to them).

> 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.

Unfreezing requires a hardfork, and won't be accepted by any existing node that implemented the tripwire logic. After the EC opcodes within the relevant output type are disabled, those spend paths are gone from the perspective of existing nodes.

It's of course always possible to introduce a new output type with ECC opcodes, or new ECC opcodes within existing output types (e.g. using OP_SUCCESSx). This is always an option the ecosystem has (not miners!), but it won't affect coins using the older output type/opcodes, which are the ones that matter here.

-- 
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/G6JS-1KFsfB7MzyRZH42MhcTp4rb_7M9Xg-1xznpwSg9MUjuI9B4ZSfVZ68S-FTaMjGBQhIpPb2E9U346X1xN1jzWoQeL5X_0Ju_j81MSAg%3D%40wuille.net.