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