From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 13 Aug 2026 00:02:16 -0700 Received: from mail-oa1-f60.google.com ([209.85.160.60]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wuPSA-00059k-El for bitcoindev@gnusha.org; Thu, 13 Aug 2026 00:02:15 -0700 Received: by mail-oa1-f60.google.com with SMTP id 586e51a60fabf-455e3cdda0dsf1903934fac.1 for ; Thu, 13 Aug 2026 00:02:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1786604528; x=1787209328; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :mime-version:subject:references:in-reply-to:message-id:to:from:date :sender:from:to:cc:subject:date:message-id:reply-to:content-type; bh=J8YtxGYDw4LkENuGwsy7/2uIRC9BeSFc8JjWap3Ceqs=; b=NMn56/QGoSrdaKforTDvyB+/EKx7t+egquDxXtoi2k65wkA0u+AIwLduqtoj6cskwp +nGee5DJu5E3mbXr8xyPsU41nRhVT8Vhs4WifWT+xwV8Gp1IUWJ18B4yrwzPs9jrKJQw DcisQu9JJ4TYgIfcQJtMJZesMcWT7dZbZmO8MVbe3eMCu8cTqGTd5Dhw2lbSLmqegQwS dvpKSqwD17+K+dr2ZYvu5kbCYhEPQaq0aL0dd9kB1l/9w9zcy0p73HYo9u1M4pwb3qfs 9S6L6ZXOw0yzzJOlXjCbZ13SEzIexz9u0cIvrxL3SCZh7QNHPVooYHFGQ1jnTqSO1CVY o3jg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786604528; x=1787209328; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :mime-version:subject:references:in-reply-to:message-id:to:from:date :from:to:cc:subject:date:message-id:reply-to:content-type; bh=J8YtxGYDw4LkENuGwsy7/2uIRC9BeSFc8JjWap3Ceqs=; b=iqZWBUqZkKXTbNw0EvThBY0pxtU7WAWwInqzGQxD6mvjmYY4nS1z8SHVRF7KUnSX8E Y/u3acuWPtx9+8w9W7X37oD6Ygz9usDVkpVg4p3lkKdmi139xzUvpbwny8o4RfLHhu1B lG1BY5PMV95yvu/CcQovJSd87aelVDirl2O/eChdFtZ7wb30N89Dv7EvJwhEtJ3BhF/O a9eoKbhxyJhPEIq2dtuezyH2APlbRYRK4AJAEaJUVNm6PwMlYncDuumQPxvonNK43gA+ 1Y1jM1bCVS+bXHpK2ArtYMAHv1v/oAgQY2WIw/TBbdiC4h/VqmVZybXA7FFVLlrz4nF4 yECw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786604528; x=1787209328; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :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:content-type; bh=J8YtxGYDw4LkENuGwsy7/2uIRC9BeSFc8JjWap3Ceqs=; b=BCc5/OfWrTRuLdKjoF+nLbKmr+hn6HLvNJf4QigpNyQO+jBoPTANJGs81FZuLqa6T4 O04pmJlHxw7r1vGMWiFvlhYwDHkh0N74WxpFIGGyyeM66jUMUcYRJWey6EA0Z9ygio5t Cho9U6cjK3IUKU1/NhjywFb2AHjNq9NSdV1SjQGwgNlKr7H5spSPSLvw8eNK23ekNOaw VNCZhOPutns0TZ4PJTCYy2/KAl49Nkra3bHsxS1BZDgOxvath5SUT59zV2Kon6W/hnn9 rI4S9s+k2ypgw4byos+ybt246YRhUOU8Pj8CrxK924lqykhoE4636Sdultdm/NcIlFtE OzQA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AHgh+Rqu1bSvjzCkU5/3/gNDqQHH/FjJ0vmqMrG7cxabIT3/+dtJYK2C3CZtj9Me4JAbFcrPGfZUeveMf82E@gnusha.org X-Gm-Message-State: AOJu0Yz/WmJHrfrZr1o9JDEXck7XwJnKNYlK2bzCfqrhxLSV0cLmo9A/ wVksDSt1R3PvJNUOea1aTot2HZMZxC4kR+WN56McPUl7wcS4d4bPaGX0 X-Received: by 2002:a05:6871:eb09:b0:456:6097:168e with SMTP id 586e51a60fabf-45e628eebf9mr3454466fac.19.1786604527927; Thu, 13 Aug 2026 00:02:07 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="Aa7YSPScUSyrQvwNMpYNbVeK70GPQEv/iqHFuuZJOxE1ad5+eA==" Received: by 2002:a05:6870:c192:b0:456:5850:365e with SMTP id 586e51a60fabf-45e5a121685ls530320fac.0.-pod-prod-04-us; Thu, 13 Aug 2026 00:02:01 -0700 (PDT) X-Received: by 2002:a05:6808:4fc6:b0:4a4:c12:49d9 with SMTP id 5614622812f47-4b2277a8217mr3989664b6e.3.1786604521050; Thu, 13 Aug 2026 00:02:01 -0700 (PDT) Received: by 2002:a05:690c:c05c:b0:81e:ee9e:9148 with SMTP id 00721157ae682-82325eb7472ms7b3; Wed, 12 Aug 2026 20:28:26 -0700 (PDT) X-Received: by 2002:a05:690c:56c6:b0:81c:872a:5152 with SMTP id 00721157ae682-83476340a16mr10888947b3.30.1786591705768; Wed, 12 Aug 2026 20:28:25 -0700 (PDT) Date: Wed, 12 Aug 2026 20:28:25 -0700 (PDT) From: waxwing/ AdamISZ To: Bitcoin Development Mailing List Message-Id: In-Reply-To: References: <002f2395-7d5d-4cb6-852c-e991aa1f0eb3@app.fastmail.com> Subject: Re: [bitcoindev] Giving teeth to expected EC disabling: P2XX(-T)(-ML) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_591950_682639225.1786591705372" X-Original-Sender: ekaggata@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_591950_682639225.1786591705372 Content-Type: multipart/alternative; boundary="----=_Part_591951_1148772590.1786591705372" ------=_Part_591951_1148772590.1786591705372 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This tripwire idea is interesting. Basically "canary in consensus". I agree it's valuable. In the scenario of adversarial actor(s) gaining=20 access to CQRC first, i.e. no whitehats, only blackhats, obviously nothing= =20 to discuss; touching a NUMS ECDL is the last thing they'll do. So I'm=20 slightly worried that the general userbase will not notice that point,=20 instead thinking it's a solid defense when it ... depends. In the scenario of at least some whitehats, we get wires tripped, or=20 canaries singing. Having it in consensus is nice. The blockchain then does= =20 its job of being an unambiguous signal and we can have all the arguments=20 well ahead of time. [1] On the other hand, we traditionally design such systems adversarially,=20 right, so you could argue that an overfocus on this might be suboptimal -= =20 it might be better to do other things. (Similar comment applies to the 'smaller group canary' - definitely nothing= =20 wrong with it, but it is not in itself a defence unless we strongly believe= =20 whitehats, and *active* whitehats at that, are keeping up). An obvious=20 question to raise: would we consider tripwiring a 192 bit group break of a= =20 similar type (NUMS)? I find that ... plausible? > The BIP341 NUMS point (which I suggest using in this context) is the=20 point whose X coordinate is the SHA256 hash of the generator point G. This= =20 guarantees that the NUMS point cannot predate G (if it did, it would be=20 possible in theory that secp256k1's designers actually chose G in function= =20 of what we call that NUMS point, giving it a DLP known to them). w.r.t. 'This guarantees that the NUMS point cannot predate G' yes based on= =20 SHA2 preimage resistance, but: isn't the real point that we're relying on= =20 SHA-2 not being a naughty function so that you couldn't find G =3D a * B an= d=20 SHA2(G) =3D b*B for some base B in some feasible computation (sans CQRC of= =20 course, as was likely back then!). I have no idea what precise name you=20 give to that property. OK, this is a ridiculous thing to discuss, perhaps,= =20 given when SHA2 and secp256k1 were standardized :) And given the encoding= =20 choices for our BIP341 NUMS (iirc the same as for Elements back in the day?= =20 using uncompressed encoding?) were able to be counted on the fingers of the= =20 hand which the sleeve does not cover :) [1] I take Antoine's point that making it consensus means the miners are=20 involved and there is a non-trivial collusion risk if the stakes are high,= =20 but I can't see how this scenario is *worse* than no tripwire? On Sunday, July 5, 2026 at 4:07:33=E2=80=AFPM UTC-6 Antoine Riard wrote: > Hi Pieter, > > Thanks for the observations. > > When I was saying there is a problem with the game theory, > it's that strikingly, any activation of the tripwire logic > would rely on a "flag" transaction being mined in the chain > for the network nodes starting to enforce at the block N or > N+1 or whatever the EC disabling threshold. > > Any "flag" transaction can be itself re-orged out of the chain > to purely disable the effects of the EC disabling threshold, > therefore make it null and void as an effect. One might see > it as a competing race between a group of "sunsetting" users > and a (majority) coalition of miners in coordination with a > CRQC adversary, where the latter have an interest and the > hashrate capabilities to do a tx-withold [0]. > > In pure terms of satoshi fee denominated calculus, empirically > global miners have won an average of $20 B yearly. If we only > consider that P2PK are going to be frozen by the tripwire effect, > as for most of them it might be assumed they will never move to > a safer format, we talk already about 1.7 M of coins or as of > today valuation $107 B (the information is on the chain and can > be verified). > > That's $107B can "burn" in revenue or income that a CRQC-enabled > miners coalition to constantly reorg-out the "flag" tx out of the > chain. In other terms, something like 5 years of income, and I > kindly do not count all the loss coins that are likely to amount > to a far bigger "tripwire" neutralization budget. > > In the name of what a majority of miners will gracefully let on > the table an opportunity of massive income ? > > Leveraging Shor the exploitation might be even done anonymously > as the mining process is done. Not even certainty, by who the > EC-protected coins could be covertly exfiltrated. > > That's the most striking problem when you think about the math > with any "tripwire" approach, or even an "hourglass" one relying > on a "flag" transaction [1]. I'm ruling out "checkpoints" and > any other trust-the-dev approach, as that's even worst [2]. > > As you're introducing post is resounding, what the miners > are saying now, there are no guarantees on how they would use > their hashrate down the road, potentially 10 or 20 years from now. > > Beyond, and to answer back your point, I still think you can > manage an escape hatch of the "tripwire" effect, it's all depends > how the script tripwire logic is implemented, but if you have > two OP_SUCCESS of different kinds before your EC CHECKSIG, you > can always have a "soft-fork" after the "tripwire" to return=20 > true on the stack, with an EC or hashlock as a success (I agree > using undefined op_success in a script is not safe at all) [3]. > =20 > Best, > Antoine > OTS hash: 4bc91d8dee1625f6e78b27c88bced8e405f25ef6d3d8fd59be8016db5b0fbe6= 6 > > [0] See naumenkog's https://www.bitmex.com/blog/txwithhold-smart-contract= s > [1] This is sad, as the "hourglass" depending how the parameters are chos= en > was a more acceptable trade-off than pure sunsetting. > [2] Given the amounts at stake to sunset, as a group of developers you > would just paint yourself a target, there are more even funds at stake > that Satoshi herself / himself is assumed to have. > [3] There is no security proof in BIP341 on the unforgeability of the > NUMS point, if it binds in the ROM or whatever. > > Le sam. 4 juil. 2026 =C3=A0 13:47, Sjors Provoost a= =20 > =C3=A9crit : > >> >> >> On Fri, Jul 3, 2026, at 23:23, Pieter Wuille wrote: >> >> [...] >> >> > * Just publishing the DLP in a transaction (e.g. OP_RETURN with a=20 >> > specific marker). This is smaller than a full transaction input +=20 >> > signature. >> > >> > * Similarly, but publishing in the coinbase, and requiring relay using= =20 >> > a separate message. Less places a node needs to check, but I'm=20 >> > concerned about the difficulty of testing infrastructure that relay of= =20 >> > such a message works >> >> [...] >> >> > >> > On Saturday, June 27th, 2026 at 12:33 AM, Anthony Towns=20 >> > wrote: >> > >> >> A slight variant of this approach would be to have a 128 byte value= =20 >> "aRsm", such that P =3D N+a*G, N is the BIP-341 NUMS point, and Rs is a= =20 >> BIP340 signature of m by P. That would allow the victim of post-quantum= =20 >> theft via a key-path spend of a BIP341 NUMS IPK to trigger the tripwire,= in=20 >> addition to someone who has direct access to a CRQC. >> > >> > Indeed, I had considered something similar, but see above for why I'm= =20 >> > not convinced supporting non-cooperative CRQCs is that useful. >> > >> > Also, in my view the tripwire isn't really a security feature on itsel= f=20 >> > (it's not expected to trigger...), but more something that sets=20 >> > expectations around the output type for prospective users. >> > >> > In that sense, the question is really whether supporting=20 >> > non-cooperative CRQCs helps set that expectation more than only=20 >> > cooperative ones, which are definitely easier to support. >> > >> >> I think it could make sense to have the tripwire be included in the= =20 >> block via the coinbase witness commitment output, rather than having it = be=20 >> locked to a transaction, so you only having to check the coinbase for th= e=20 >> magic rather than every transaction. That would require a separate P2P= =20 >> message to relay the necessary ECDL-break proof to miners, and would=20 >> probably need stratumv2 or a getblocktemplate update in order for the no= de=20 >> 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=20 >> > fake-tripwires to be supported through the same message which don't=20 >> > require an ECDLP break, and still propagate. And then that needs DoS= =20 >> > protection measures,=20 >> >> I whipped something up last weekend: >> https://github.com/Sjors/bitcoin/pull/121 >> >> It seems straightforward, but maybe I missed something: >> - for test code we use a fake NUMS point, so we can generate "proof"=20 >> without a quantum computer >> - a p2p message floods the proof >> - nodes ignore the message if they already have *any* valid proof >> - verifying p2p proof candidates might need some rate limiting, but it's= =20 >> as cheap as verifying a transaction signature >> - mining code includes the proof in a coinbase op_return, until the=20 >> freeze activates >> - with stratum v2 (and ipc mining clients in general this works out of= =20 >> the box, a small change is needed for getblocktemplate clients) >> - since the proof is not in the header, we can't use the normal bip9=20 >> style header scan to see if the rule activated. Instead the prototype=20 >> stores it in a file along with a merkle inclusion proof, which is read w= hen=20 >> the node restarts. >> >> With this mechanism it doesn't really need to be in the coinbase=20 >> transaction, but that does seem more convenient and miners can censor it= =20 >> anyway. >> >> - Sjors >> >> --=20 >> You received this message because you are subscribed to a topic in the= =20 >> Google Groups "Bitcoin Development Mailing List" group. >> To unsubscribe from this topic, visit=20 >> https://groups.google.com/d/topic/bitcoindev/aWYtPLVPZ3U/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to=20 >> bitcoindev+...@googlegroups.com. >> To view this discussion visit=20 >> https://groups.google.com/d/msgid/bitcoindev/002f2395-7d5d-4cb6-852c-e99= 1aa1f0eb3%40app.fastmail.com >> . >> > --=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/= f6d78499-d551-45ea-89b1-2b9cbd52f5can%40googlegroups.com. ------=_Part_591951_1148772590.1786591705372 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This tripwire idea is interesting. Basically "canary in consensus".
I agree it's valuable. In the scenario of adversarial actor(s= ) gaining access to CQRC first, i.e. no whitehats, only blackhats, obviousl= y nothing to discuss; touching a NUMS ECDL is the last thing they'll do. So= I'm slightly worried that the general userbase will not notice that point,= instead thinking it's a solid defense when it ... depends.

In the scenario of at least some whitehats, we get wires trippe= d, or canaries singing. Having it in consensus is nice. The blockchain then= does its job of being an unambiguous signal and we can have all the argume= nts well ahead of time. [1]

On the other hand, w= e traditionally design such systems adversarially, right, so you could argu= e that an overfocus on this might be suboptimal - it might be better to do = other things.

(Similar comment applies to the 's= maller group canary' - definitely nothing wrong with it, but it is not in i= tself a defence unless we strongly believe whitehats, and *active* whitehat= s at that, are keeping up). An obvious question to raise: would we consider= tripwiring a 192 bit group break of a similar type (NUMS)? I find that ...= plausible?

> The BIP341 NUMS point (which I sugge= st using in this context) is the point whose X coordinate is the SHA256 has= h of the generator point G. This guarantees that the NUMS point cannot pred= ate 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).

w.r.t. 'This guarantees that= the NUMS point cannot predate G' yes based on SHA2 preimage resistance, bu= t: isn't the real point that we're relying on SHA-2 not being a naughty fun= ction so that you couldn't find G =3D a * B and SHA2(G) =3D b*B for some ba= se B in some feasible computation (sans CQRC of course, as was likely back = then!). I have no idea what precise name you give to that property. OK, thi= s is a ridiculous thing to discuss, perhaps, given when SHA2 and secp256k1 = were standardized :) And given the encoding choices for our BIP341 NUMS (ii= rc the same as for Elements back in the day? using uncompressed encoding?) = were able to be counted on the fingers of the hand which the sleeve does no= t cover :)

[1] I take Antoine's point that makin= g it consensus means the miners are involved and there is a non-trivial col= lusion risk if the stakes are high, but I can't see how this scenario is *w= orse* than no tripwire?

On Sunday, July 5, 2026 at 4:07:33=E2= =80=AFPM UTC-6 Antoine Riard wrote:
Hi Pieter,

Thanks for the ob= servations.

When I was saying there is a problem with the game theor= y,
it's that strikingly, any activation of the tripwire logic
wou= ld rely on a "flag" transaction being mined in the chain
for t= he network nodes starting to enforce at the block N or
N+1 or whatever t= he EC disabling threshold.

Any "flag" transaction can be i= tself re-orged out of the chain
to purely disable the effects of the EC = disabling threshold,
therefore make it null and void as an effect. One m= ight see
it as a competing race between a group of "sunsetting"= ; users
and a (majority) coalition of miners in coordination with a
C= RQC adversary, where the latter=C2=A0have an interest and the
hashrate c= apabilities to do a tx-withold [0].

In pure terms of satoshi fee den= ominated calculus, empirically
global miners have won an average of $20 = B yearly. If we only
consider that P2PK are going to be frozen by the tr= ipwire effect,
as for most of them it might be assumed they will never m= ove to
a safer format, we talk already about 1.7 M of coins or as of
= today valuation $107 B (the information is on the chain and can
be verif= ied).

That's $107B can "burn" in revenue or income tha= t a CRQC-enabled
miners coalition to constantly reorg-out the "flag= " tx out of the
chain. In other terms, something like 5 years of in= come, and I
kindly do not count all the loss coins that are likely to am= ount
to a far bigger "tripwire" neutralization budget.

= In the name of what a majority of miners will gracefully let on
the tabl= e an opportunity of massive income ?

Leveraging Shor the exploitatio= n might be even done anonymously
as the mining process is done. Not even= certainty, by who the
EC-protected coins could be covertly exfiltrated.=

That's the most striking problem when you think about the math<= br>with any "tripwire" approach, or even an "hourglass"= one relying
on a "flag" transaction [1]. I'm ruling out &= quot;checkpoints" and
any other trust-the-dev approach, as that'= ;s even worst [2].

As you're introducing post is resounding, wha= t the miners
are saying now, there are no guarantees on how they would u= se
their hashrate down the road, potentially 10 or 20 years from now.
Beyond, and to answer back your point, I still think you can
manage= an escape hatch of the "tripwire" effect, it's all dependshow the script tripwire logic is implemented, but if you have
two OP_S= UCCESS of different kinds before your EC CHECKSIG, you
can always have a= "soft-fork" after the "tripwire" to return
true on= the stack, with an EC or hashlock as a success (I agree
using undefined= op_success in a script is not safe at all) [3].
=C2=A0
Best,
Anto= ine
OTS hash: 4bc91d8dee1625f6e78b27c88bced8e405f25ef6d3d8fd59be8016db5b= 0fbe66

[0] See naumenkog's https://www.bitmex.com/blog= /txwithhold-smart-contracts
[1] This is sad, as the "hourglass&= quot; depending how the parameters are chosen
was a more acceptable trad= e-off than pure sunsetting.
[2] Given the amounts at stake to sunset, as= a group of developers you
would just paint yourself a target, there are= more even funds at stake
that Satoshi herself / himself is assumed to h= ave.
[3] There is no security proof in BIP341 on the unforgeability of t= he
NUMS point, if it binds in the ROM or whatever.

Le=C2=A0sam. 4 juil. 2026 =C3=A0=C2=A013:47, Sjors Provoost &l= t;sj...@sprovoost.nl> a = =C3=A9crit=C2=A0:


On Fri, Jul 3, 2026, at 23:23, Pieter Wuille wrote:

[...]

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

[...]

>
> On Saturday, June 27th, 2026 at 12:33 AM, Anthony Towns
> <a...@erisian.com.au= > wrote:
>
>> A slight variant of this approach would be to have a 128 byte valu= e "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-qu= antum theft via a key-path spend of a BIP341 NUMS IPK to trigger the tripwi= re, in addition to someone who has direct access to a CRQC.
>
> Indeed, I had considered something similar, but see above for why I= 9;m
> not convinced supporting non-cooperative CRQCs is that useful.
>
> Also, in my view the tripwire isn't really a security feature on i= tself
> (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 th= e block via the coinbase witness commitment output, rather than having it b= e 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 mes= sage 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 abl= e 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 <= br> > protection measures,

I whipped something up last weekend:
https= ://github.com/Sjors/bitcoin/pull/121

It seems straightforward, but maybe I missed something:
- for test code we use a fake NUMS point, so we can generate "proof&qu= ot; without a quantum computer
- a p2p message floods the proof
- nodes ignore the message if they already have *any* valid proof
- verifying p2p proof candidates might need some rate limiting, but it'= s as cheap as verifying a transaction signature
- mining code includes the proof in a coinbase op_return, until the freeze = activates
=C2=A0 - with stratum v2 (and ipc mining clients in general this works out = of the box, a small change is needed for getblocktemplate clients)
- since the proof is not in the header, we can't use the normal bip9 st= yle header scan to see if the rule activated. Instead the prototype stores = it in a file along with a merkle inclusion proof, which is read when the no= de restarts.

With this mechanism it doesn't really need to be in the coinbase transa= ction, but that does seem more convenient and miners can censor it anyway.<= br>
- Sjors

--
You received this message because you are subscribed to a topic in the Goog= le Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/bitcoindev/aWYtPLVPZ3U/unsubs= cribe.
To unsubscribe from this group and all its topics, send an email to bitcoindev+...@googlegroups.com. To view this discussion visit https= ://groups.google.com/d/msgid/bitcoindev/002f2395-7d5d-4cb6-852c-e991aa1f0eb= 3%40app.fastmail.com.

--
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/f6d78499-d551-45ea-89b1-2b9cbd52f5can%40googlegroups.com.
------=_Part_591951_1148772590.1786591705372-- ------=_Part_591950_682639225.1786591705372--