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