From: Antoine Riard <antoine.riard@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Giving teeth to expected EC disabling: P2XX(-T)(-ML)
Date: Sun, 28 Jun 2026 19:17:40 -0700 (PDT) [thread overview]
Message-ID: <5f59804c-6a3b-41e7-9733-6c253353847an@googlegroups.com> (raw)
In-Reply-To: <aj9SkwXqdRbuVZxH@erisian.com.au>
[-- 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 --]
prev parent reply other threads:[~2026-06-29 2:32 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
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 message]
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=5f59804c-6a3b-41e7-9733-6c253353847an@googlegroups.com \
--to=antoine.riard@gmail.com \
--cc=bitcoindev@googlegroups.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