From: Anthony Towns <aj@erisian.com.au>
To: Pieter Wuille <bitcoin-dev@wuille.net>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Giving teeth to expected EC disabling: P2XX(-T)(-ML)
Date: Sat, 27 Jun 2026 14:33:23 +1000 [thread overview]
Message-ID: <aj9SkwXqdRbuVZxH@erisian.com.au> (raw)
In-Reply-To: <yHRpA2LEJ2AugT4W2KiWO3ggSims4GuHBkr6rWtE-e1uVC2wh3ZqD4bUDyxXq1iEuPrezhZZeqDoG7uBLNvjbW0sk_UTorI1Pkz6LcKhXRA=@wuille.net>
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/aj9SkwXqdRbuVZxH%40erisian.com.au.
next prev parent reply other threads:[~2026-06-27 9:58 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 [this message]
2026-06-29 2:17 ` Antoine Riard
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=aj9SkwXqdRbuVZxH@erisian.com.au \
--to=aj@erisian.com.au \
--cc=bitcoin-dev@wuille.net \
--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