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

["Sjors Provoost" <sjors@sprovoost.nl>]

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 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/002f2395-7d5d-4cb6-852c-e991aa1f0eb3%40app.fastmail.com.