From: Erik Aronesty <erik@q32.com>
To: Pieter Wuille <bitcoin-dev@wuille.net>
Cc: "waxwing/ AdamISZ" <ekaggata@gmail.com>,
Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Giving teeth to expected EC disabling: P2XX(-T)(-ML)
Date: Tue, 18 Aug 2026 16:04:25 -0700 [thread overview]
Message-ID: <CAJowKg+E5YMaWopx7VhMmtMYJ93mYMsDzbdJgVoG+B4=a9KaNQ@mail.gmail.com> (raw)
In-Reply-To: <td8wPWxRVg0rQIdP41uibTvWuIoCvGYpvfX022TaDurf-qu1TMm1TmWogw-JTs4C7Mt-97cvJCBW66z4g-Vc2fsSoo-Qxfm8Lcnd384Uink=@wuille.net>
[-- Attachment #1: Type: text/plain, Size: 4869 bytes --]
FWIW: there is a very long thread about this here:
https://groups.google.com/g/bitcoindev/c/d7o74e-teNo/m/lLKjufQZAgAJ
On Tue, Aug 18, 2026 at 10:30 AM Pieter Wuille <bitcoin-dev@wuille.net>
wrote:
> Hi all,
>
> I'm unconvinced the complexity of a 192-bit canary is worth it. Picking a
> curve and a NUMS point on it are not hard, but very little of
> libsecp256k1's code can be reused (even field arithmetic is optimized
> specifically for the secp256k1 prime). A more generic implementation is
> possible of course, but it's still a pretty big piece of engineering for
> what is IMO very little gain.
>
> There is a pretty fundamental difference between a secp256k1 Tripwire and
> a canary for weaker curves, in that the former isn't intended to be
> predictive. Its purpose is setting a codified upper bound on when ECC
> (within PQC output types) is expected to be disabled. While it's certainly
> possible it's actually triggered by a cooperative CRQC, that's not how I
> expect ECC disabling to happen (instead I expect a community
> consensus-changing effort, effected through Miner Lockdown or otherwise).
> The Tripwire just sets an unambiguous expectation that disabling is
> intended by Q-day.
>
> I don't think the presence of a 192-bit canary changes this expectation
> much. 192-bit ECDLP broken (or breakable) is certainly a legitimate reason
> for panic, but nothing prevents that information from being used at the
> human layer without it needing to have been part of consensus rules.
>
> Relatedly, something I don't know is how "similar" a canary needs to be to
> the real secp256k1 ECDLP for people to bother building/programming/running
> a QC for it. This is of course a question that exists for secp256k1 itself:
> whether a *cooperative* entity with the capability of building a
> secp256k1-ECDLP QRQC would bother doing so. But it's even more tenuous for
> weaker problems, if they're not so much weaker that they're trivial. This
> makes me wonder about using a subgroup of a very related curve: for example
> y^2 = x^3 + 3 (mod 2^256-2^32-977) has a subgroup of order ~2^187.11, which
> would use all the same finite field arithmetic and almost the same
> multiplication logic (only doubling is affected). Keeping the field modulus
> the same does mean the q-bit count is unaffected though, only the gate
> count decreases (proportional to logarithm of group order). Like other
> weaker-curve constructions, I don't think this is worth it, but want to
> throw the idea out there.
>
> I also don't think optimizing for multi-target ECDLP adds much. My
> understanding is that Shor's doesn't benefit from multiple targets? I'm not
> opposed to giving freedom of finding (m,x) such that H(m) = x*G, but I
> don't see why that would encourage a cooperative CRQC to work on breaking
> it.
>
> Regarding using the BIP-341 H itself as canary, I don't think that's a
> problem if the ECDLP break proof is a Schnorr signature (as opposed to
> revealing the DLP itself). But it also makes sense to be as conservative as
> possible here; it may make sense to make a selection of hash functions,
> feed them all as much input as possible (the genesis block is a good idea,
> the existing generator G, maybe a block hash from a time when the
> activation parameters are decided, or even a block hash when the block goes
> live as suggested by Tadge though that adds hash-to-curve logic to
> consensus too), and then XOR (or hash) all hash results together.
>
> From a simplicity standpoint, I think just having a "a UTXO with
> scriptPubKey X is spent" is ideal, because it reuses all existing block and
> transaction validation logic, and just adds a trivial trigger. It's not
> compatible with any weaker curve construction of course, or with AJ's
> H-dependent DLP proof which could enlist non-cooperative CRQC, but I don't
> think that's worth complicating matters for.
>
> Cheers,
>
> --
> Pieter
>
> --
> 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/td8wPWxRVg0rQIdP41uibTvWuIoCvGYpvfX022TaDurf-qu1TMm1TmWogw-JTs4C7Mt-97cvJCBW66z4g-Vc2fsSoo-Qxfm8Lcnd384Uink%3D%40wuille.net
> .
>
--
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/CAJowKg%2BE5YMaWopx7VhMmtMYJ93mYMsDzbdJgVoG%2BB4%3Da9KaNQ%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 5855 bytes --]
next prev parent reply other threads:[~2026-08-18 23:20 UTC|newest]
Thread overview: 22+ 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-07-03 21:23 ` Pieter Wuille
2026-07-04 11:57 ` Sjors Provoost
2026-07-05 21:55 ` Antoine Riard
2026-08-13 3:28 ` waxwing/ AdamISZ
2026-08-14 18:33 ` 'conduition' via Bitcoin Development Mailing List
2026-08-15 14:49 ` waxwing/ AdamISZ
2026-08-15 16:52 ` 'conduition' via Bitcoin Development Mailing List
2026-08-15 18:06 ` waxwing/ AdamISZ
2026-08-16 19:30 ` 'conduition' via Bitcoin Development Mailing List
2026-08-18 14:36 ` waxwing/ AdamISZ
2026-08-18 17:20 ` Pieter Wuille
2026-08-18 23:04 ` Erik Aronesty [this message]
2026-08-19 2:32 ` 'conduition' via Bitcoin Development Mailing List
2026-08-19 15:18 ` waxwing/ AdamISZ
2026-08-19 22:16 ` Pieter Wuille
2026-06-27 4:33 ` Anthony Towns
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='CAJowKg+E5YMaWopx7VhMmtMYJ93mYMsDzbdJgVoG+B4=a9KaNQ@mail.gmail.com' \
--to=erik@q32.com \
--cc=bitcoin-dev@wuille.net \
--cc=bitcoindev@googlegroups.com \
--cc=ekaggata@gmail.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