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

[Antoine Riard <antoine.riard@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 7714 bytes --]

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

Best,
Antoine
OTS hash: 4bc91d8dee1625f6e78b27c88bced8e405f25ef6d3d8fd59be8016db5b0fbe66

[0] See naumenkog's https://www.bitmex.com/blog/txwithhold-smart-contracts
[1] This is sad, as the "hourglass" depending how the parameters are chosen
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 à 13:47, Sjors Provoost <sjors@sprovoost.nl> a écrit :

>
>
> 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
> > <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,
>
> 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"
> 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
>   - 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 style
> 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 node
> restarts.
>
> With this mechanism it doesn't really need to be in the coinbase
> transaction, but that does seem more convenient and miners can censor it
> anyway.
>
> - Sjors
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Bitcoin Development Mailing List" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/bitcoindev/aWYtPLVPZ3U/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/002f2395-7d5d-4cb6-852c-e991aa1f0eb3%40app.fastmail.com
> .
>

-- 
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/CALZpt%2BFMHG3yoOCXPfMhS%3DKFF9bn%2BrCi9NL836GDRp1CKTBXRA%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 9401 bytes --]