From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 28 Jun 2026 19:32:02 -0700 Received: from mail-oo1-f59.google.com ([209.85.161.59]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1we1mz-0002DD-C9 for bitcoindev@gnusha.org; Sun, 28 Jun 2026 19:32:02 -0700 Received: by mail-oo1-f59.google.com with SMTP id 006d021491bc7-6a150c6c233sf3134543eaf.1 for ; Sun, 28 Jun 2026 19:32:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1782700315; x=1783305115; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=mRhYyEppj15Lnh+4Bcm4j+EEa4FEpDr1pPtyyUsYxA4=; b=bKliETvrf27I5kIGiwlRkSPHmpk8pf9bGosA8cMhTvkYVSJVgZEo9teDqJazAmtRUQ bRnYQgUaKYvAEmRlp3WVG9XHl2AKRQS4dzxpVsxaVIsGuzfwnLKZFNh9Kuo2O2bJ6s+c ZWHuKChdJ9NB6kdomA8bZnKry+IIXu51JoK1A1zVfL4PE8qGDM/LyPmz0bsj27M8e7dh jiyhyXAdTAMCMUdPKBH1aCIETXnQCOcUBXbV5j9NzNH97D3WOQ4mVRHft0KFvtCZNR7I WtcSPCkk9N0PntLxUHPgH01q0G5lLZksEc1pmjgGiUATnYTSqUN+no1SVG/2f7RFQfWR RxHA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1782700315; x=1783305115; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=mRhYyEppj15Lnh+4Bcm4j+EEa4FEpDr1pPtyyUsYxA4=; b=OhXdUS/psf6j35vmnRmLZxe9XhgXMG1VHW7mzgEG8uLSpno7qyrK8pauu6+ri41hzi hJH7UZh6dXSwRZvRSp9fFZCxjdRSIwUEKyUfyxk+wA53LcxA+ep3hjSFUgxGjoZODvoi oFQgT6rh8dSbj3LYK+uLhFwCdPmp5QdIve9rhYMiEBH9sV42hoP4dYMq5TaoPFzYw/hf 8NbQI5S5JhhPgaOHNL/kxd5RDNTyptZfEEBYWVMpUux1q752yZ/egCN5NoQtD5789s8D 9Tf0OKIHfbmlUZ1vw1LFIswXsTZQZuFMwfNxDFXL9R1YtVndv7Yekd0tkGSi5dJqlpyN vqHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782700315; x=1783305115; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=mRhYyEppj15Lnh+4Bcm4j+EEa4FEpDr1pPtyyUsYxA4=; b=isoAWqn9Rg4PjOgHHnpDoxD01ZZ6SYtmBmL7wRZpZEWXrzjx6yop1yZ8blSEWzhEQi xYCFI64qjhkI4ZKS2FW5J2ycEvAS+xfXq0tD/qDnsX2ftnhrqBF4I/LBUd0uOpioBuea OvdDqT0MUFC1ZQK/vD+Hv6CIwqUZ5y/c2iK6AbiGzMba+tfOClHjitJZpLYyedxkuFP1 rR65mk7m9C4n5HHwdY55hkxKkv1EnyFG+wbF6ef7+YligiJZSgF1+xBNJT+1jUe6jLxC gA2eUczTSbHgNToj3sduYDg/e4OUGVWbQiJqFG0N80V966g9wxJhUZ7hNGLaGOMt4Z/c 3kqg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AFNElJ9uANsWmWVaHPeSGEaSXapV8T7ajNfYNbX+Bb7mLbHxm+ydZ+3I4nYM3v+6CRQI8Ez3JITQNxlf0ovD@gnusha.org X-Gm-Message-State: AOJu0Yz8kyH7WrTBWo0OVx5rRGE1b5tel7JFAvMuUpW1vuvfqTdVXxFw 11V9JhkkGbGlULJ820kEPyNH1fRyJe0eiO1/AisRQAUXV0IIn1MiDljX X-Received: by 2002:a05:6820:4c01:b0:6a1:2f76:9672 with SMTP id 006d021491bc7-6a12f769b45mr10921058eaf.13.1782700314858; Sun, 28 Jun 2026 19:31:54 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AX0PUUfWa1TKxjXJiCwBbznx6CiLo+8ubgC80uV08njRuMz2QA==" Received: by 2002:a05:6870:8093:b0:448:7b8c:24ee with SMTP id 586e51a60fabf-4487b8c2737ls568667fac.0.-pod-prod-05-us; Sun, 28 Jun 2026 19:31:48 -0700 (PDT) X-Received: by 2002:a05:6808:2203:b0:495:3690:accf with SMTP id 5614622812f47-4953690b456mr4211035b6e.17.1782700308654; Sun, 28 Jun 2026 19:31:48 -0700 (PDT) Received: by 2002:a05:690c:c01c:b0:809:cfd1:4c3a with SMTP id 00721157ae682-80ba3a02c8ams7b3; Sun, 28 Jun 2026 19:17:41 -0700 (PDT) X-Received: by 2002:a05:690c:6707:b0:80e:1ad2:afc3 with SMTP id 00721157ae682-80e1ad2c0e3mr38371777b3.15.1782699461100; Sun, 28 Jun 2026 19:17:41 -0700 (PDT) Date: Sun, 28 Jun 2026 19:17:40 -0700 (PDT) From: Antoine Riard To: Bitcoin Development Mailing List Message-Id: <5f59804c-6a3b-41e7-9733-6c253353847an@googlegroups.com> In-Reply-To: References: Subject: Re: [bitcoindev] Giving teeth to expected EC disabling: P2XX(-T)(-ML) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_29840_1235817600.1782699460701" X-Original-Sender: antoine.riard@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: 2.6 (++) ------=_Part_29840_1235817600.1782699460701 Content-Type: multipart/alternative; boundary="----=_Part_29841_2101799214.1782699460701" ------=_Part_29841_2101799214.1782699460701 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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)=20 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 =C3=A0 10:58:42=E2=80=AFAM UTC+1, Anthony Towns = a =C3=A9crit : > 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]). > >=20 > > Specifically, as part of the softfork definition, a NUMS point is > > picked. Whenever a transaction is mined whose input contains a successf= ul > > " 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 =3D 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 nod= e > to be able to tell pools to actually include that info in the coinbase. > > > * Miner Lockdown (P2XX-ML): allow a hashrate majority/threshold to=20 > 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= =20 > 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 id= ea > > 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 > --=20 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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= 5f59804c-6a3b-41e7-9733-6c253353847an%40googlegroups.com. ------=_Part_29841_2101799214.1782699460701 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Pieter,

Thanks for your work on this subject.

Whil= e 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 co= nfident that what you're proposing can
even be made technically robust= .

If I'm understanding correctly your proposal, e.g for the trip= wire
idea, a well-constructed nothing-under-my-sleeve point would bepicked 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 va= lidity space of the consensus
information space with new verification = rules, due to the numerous
hooks introduced by P2TR (the annex, the le= aves 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 c= artel of CRQC actors lobbying a collective of miners).

Saying th= at we should just assume the 51% of miners acting for the
long term in= terest of the network at all times is a not a serious
security assumpt= ion. It might have to be some astute designed soft-fork
with a layer o= f indirection to re-introduce the coins, but frankly
I don't see how y= ou can prevent massive "unfreeze" at a latter chain
"time" of the acti= vation 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 t= he mail
thread you're mentioning, so of course I might look on your pr= oposal
with a more adversarial lense. I do note at least the idea to m= ake the EC
disable wrapped in P2MR only, somehow that would be introdu= cing an opt-in
mechanism for the users and not applying the tripwire d= isablement to users
who do not agree with this consensus rule for thei= r coins.

Back to the central point, in a consensus world where t= here are many
upgradeability consensus rules, and as you're observing = yourself we
cannot predict what would a collective of miners in the fu= ture, 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 "freez= e" coins
why the miners are not going to collude with CRQC actors, if = a CQRC
machine ever becomes a reality...

Best,
Antoine=
OTS hash: 0c4f7a46103facb2e7e49586d7e8a267be3c7cb611db5961f306aaea19c= 332ac

[0] A cryptographically-leaning mind can note the first di= fficulty
here. Quid if it's not a "real" nothing-under-my-sleeve point= ...
= Le Saturday, June 27, 2026 =C3=A0 10:58:42=E2=80=AFAM UTC+1, Anthony Towns = a =C3=A9crit=C2=A0:
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 tri= gger
> (suggested by Tadge Dryja[4]).
>=20
> Specifically, as part of the softfork definition, a NUMS point i= s
> picked. Whenever a transaction is mined whose input contains a s= uccessful
> "<NUMS> OP_CHECKSIG", EC opcodes/paths are disab= led 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 =3D N+a*G, N is the BIP-341 NUMS point, a= nd 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 fo= r
the magic rather than every transaction. That would require a separate
P2P message to relay the necessary ECDL-break proof to miners, and woul= d
probably need stratumv2 or a getblocktemplate update in order for the n= ode
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 th= reats.

> The same is true
> for the Miner Lockdown idea. I'm a bit more hesitant about tha= t, as it may
> be empowering the (collective of) miners too much. They always hav= e the
> ability to just disallow EC spends of course, but the Miner Lockdo= wn 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 af= ter
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 &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/5f59804c-6a3b-41e7-9733-6c253353847an%40googlegroups.com.
------=_Part_29841_2101799214.1782699460701-- ------=_Part_29840_1235817600.1782699460701--