From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 19 Aug 2026 08:36:12 -0700 Received: from mail-oo1-f64.google.com ([209.85.161.64]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wwiKo-0005oK-7Y for bitcoindev@gnusha.org; Wed, 19 Aug 2026 08:36:12 -0700 Received: by mail-oo1-f64.google.com with SMTP id 006d021491bc7-6b146b7da03sf120593eaf.0 for ; Wed, 19 Aug 2026 08:36:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1787153764; x=1787758564; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :mime-version:subject:references:in-reply-to:message-id:to:from:date :sender:from:to:cc:subject:date:message-id:reply-to:content-type; bh=rXgAc7Scdmg4qsqlm41eqZwjq/5FwgLB6qqMAbOkCKk=; b=ICyS7U5aWxHc9O5JY8lNHyjXPmN7uImsSaMBO07lEckBAUwiFHk2Dww19SPSdAtFMq 0cnX3U2z9H80Gzi9EyqfxTQyJB9hUQvCmH+eQXuZq2k4dVYwVLByEUNBRa9NCM+fczj+ 54s/C5KlmZG/QScBVNmW1LcDDawAMBebsexATUNcnXzc91Gg3Eo7B6QnqImnCcnwUrEh yWL4ro6AwI5lmQ5VRESuh3IdJ1VEuFPW56Fsszc37hsL2ase4jsCYyFJRwtuaqMwtqG8 p3Dj347Aaf95VacZs3rFxZeeWTUtK/ncIO3vWkP9akDHUxPU+beeOyKp51bpGjO9aMDA /Msg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787153764; x=1787758564; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :mime-version:subject:references:in-reply-to:message-id:to:from:date :from:to:cc:subject:date:message-id:reply-to:content-type; bh=rXgAc7Scdmg4qsqlm41eqZwjq/5FwgLB6qqMAbOkCKk=; b=fobdod8v2oCSrDkhejntSTW/QIrzLWCweSVYdO6FeZ4ZY76+WXPUcGOasmKb0jBtNr nFjM1Bu2NA14SVR7dll6OqcAL3AFx5d1r1MrFDVsccmA/NtafrUJKNeGafmojCODvd7M 5Zq2rTFT508qD8slgwQYYrlVTPJLxZ+AeV0QneKLJ/bfCSimKeMMzIlrOwz7PhSZU1Nm fFfIab715w3OXfMXG8LGg0QREDXSJZc52BZ/x/dAACvek/4FYibzzW8Cd6pKBT3w/ert lJGV7X/REvYwVzMkXMyhspIvc1BsM8DRO+suKW8KxikxsqVJfjrf8v2P2ir9mS22qX5Y /UWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787153764; x=1787758564; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :mime-version:subject:references:in-reply-to:message-id:to:from:date :x-beenthere:x-gm-message-state:sender:from:to:cc:subject:date :message-id:reply-to:content-type; bh=rXgAc7Scdmg4qsqlm41eqZwjq/5FwgLB6qqMAbOkCKk=; b=iAPKuP+eDZQCg8f3BnlfzT32vxLHg46PHWcNLLbyACkQtieC5lV353MY1h99I9JQIm znxi12KmEsCzU454vYp3+Zb+w9MhVZt1Jqm4trP1K7JBdmyH0cT5op1Uy4fP9xuWkG8X OHdP1yfLsI5A1GxfoQCTK2b3p2V6cik3MQ0dNvL7XaeUE6hhtGe2Ud5siSegjJEbwd3+ Hv9J3O8VlResGWXCjIrn0CM2jPTRIMNchaqXkqOqqI28q+undnRV6aN8MIFVawVaQFHZ PFreOlU/YRNJtA50+ehpWqk5YJrbcWQ6Uhgu94d7z9vHxNYxkBWVSbrbNoCHc9CfpRim 6oLg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AHgh+RoLYrwRSNPbhyQT4mgM3VORWGnaaP/tWeiLur5ylwJsrkkMto0Uz9h81vBffBNjke75t6WfWnoNomCl@gnusha.org X-Gm-Message-State: AOJu0YwsyZZBJdpA62VU1KKEmARtE3WaZvRHIfQ1URnuNhCvhIERjOaF cM6iVz77877KoAiQn39rVtrxzVmTv81ampICKF9+6vCdlvbAQEjcgD5P X-Received: by 2002:a05:6820:1c8c:b0:6b1:2843:1312 with SMTP id 006d021491bc7-6b13bdb91camr5478081eaf.0.1787153763590; Wed, 19 Aug 2026 08:36:03 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ATskLdc83PK12uLZyAVVhlksEnpCEx3JaEOMcRWngM6Sb9HFlw==" Received: by 2002:a05:6820:2ac4:b0:6b0:5edf:6386 with SMTP id 006d021491bc7-6b1483167dbls71338eaf.0.-pod-prod-02-us; Wed, 19 Aug 2026 08:35:58 -0700 (PDT) X-Received: by 2002:a05:6808:3306:b0:496:e0:a46b with SMTP id 5614622812f47-4b2bc883003mr4866076b6e.3.1787153758486; Wed, 19 Aug 2026 08:35:58 -0700 (PDT) Received: by 2002:a05:690c:9203:b0:80b:2194:fea2 with SMTP id 00721157ae682-8445cf2277bms7b3; Wed, 19 Aug 2026 08:18:41 -0700 (PDT) X-Received: by 2002:a05:690c:c15:b0:81e:87ca:4799 with SMTP id 00721157ae682-844e2ed73c4mr24747267b3.23.1787152720439; Wed, 19 Aug 2026 08:18:40 -0700 (PDT) Date: Wed, 19 Aug 2026 08:18:40 -0700 (PDT) From: waxwing/ AdamISZ To: Bitcoin Development Mailing List Message-Id: In-Reply-To: References: <22f8b95d-403c-4a3e-ad64-221faf2ea851n@googlegroups.com> Subject: Re: [bitcoindev] Giving teeth to expected EC disabling: P2XX(-T)(-ML) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_44996_244015058.1787152720081" X-Original-Sender: ekaggata@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: 2.6 (++) ------=_Part_44996_244015058.1787152720081 Content-Type: multipart/alternative; boundary="----=_Part_44997_877819814.1787152720081" ------=_Part_44997_877819814.1787152720081 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi conduition, > Given the polynomial efficiency of Shor, and the massive time/money=20 investment needed to build quantum computers, we have no reason to expect= =20 anyone will build a QC that can break 192-bit curves but *not* 256-bit=20 curves. There is actually incentive *not* to do so, especially if breaking= =20 a 192-bit curve will cause the Bitcoin network (the most ripe target to pay= =20 off QC investors) to react by locking itself down.=20 Well, but this brings me right back to my first comment here (not that it= =20 is *my* comment, it's been said elsewhere in thread): this tripwire concept= =20 is not a defence against an adversary, right; if the first QC is expensive= =20 and difficult (likely), and if they decide to be adversarial, they won't be= =20 tripping any wires. But surely it follows, that they have just as much=20 incentive to not trip the 256 wire as the 192 wire. Anyway I will try to now avoid further nerd sniping (including against=20 myself) talking about smaller order curves; I do agree with the points=20 raised, that it's not a sufficiently practical idea (given secp256k1's most= =20 excellent property, its cofactor of 1, is extremely unhelpful in this=20 particular case! - therefore nice idea, Pieter, with the 'algebraically=20 similar curve but with subgroups', but I'm willing to bet you're right that= =20 that doesn't cut it, either) on more than one axis. Smaller group *canaries* (not tripwires) are still interesting I think. Not= =20 amazing, but maybe quite valuable. > Also found this related paper which proposes an incremental ladder of=20 canaries using NUMS points on a sequence of curves of increasing size:=20 https://arxiv.org/pdf/2508.14011 interesting find, thanks! > If, on the other hand, we had nodes check something almost as simple,=20 like for example "check every 32-byte OP_RETURN to see if it happens to be= =20 the dlog of the NUMS point", then any user can choose to include the proof= =20 in their transactions at relatively little cost. Any miners who want to=20 censor the canary proof will have to also censor any such transactions, and= =20 so they lose out on the potential fee revenue of the entire TX by doing so. Yes that does seem to be better than single utxo. But perhaps the=20 difference isn't that significant in practice? > I'm not sure if this incentive is meaningful when compared to the=20 potential bribes that a miner could be offered by a CRQC, but still it is= =20 worth considering. It does have the down side that it will slow down block= =20 validation slightly (one EC mult per 32-byte OP_RETURN). Maybe this could= =20 be accounted for somehow in the sigops budget? I agree it doesn't seem very reasonable that there's a way to counter such= =20 a huge incentive in *a* miner as one related to a QC break. It also makes me think: that's not how consensus changes usually work, eh.= =20 Giving miners the ability to censor an update seems antithetical. It's also= =20 weirdly the opposite shape to what you want: it activates with the=20 permission of 1 of N miners (weighted by hashrate), which means it's kind= =20 of guaranteed to occur once the proof exists, but could be quite slow. The= =20 counterargument might be: that's not going to happen! Once the proof is=20 public, a miner deliberately not mining it is very transparently a bad=20 actor. Not sure. Seems a bit wobbly but not crazy. Pieter, > Regarding using the BIP-341 H itself as canary, I don't think that's a=20 problem if the ECDLP break proof is a Schnorr signature (as opposed to=20 revealing the DLP itself). But it also makes sense to be as conservative as= =20 possible here; it may make sense to make a selection of hash functions,=20 feed them all as much input as possible (the genesis block is a good idea,= =20 the existing generator G, maybe a block hash from a time when the=20 activation parameters are decided, or even a block hash when the block goes= =20 live as suggested by Tadge though that adds hash-to-curve logic to=20 consensus too), and then XOR (or hash) all hash results together. Good point about signature, I wasn't considering that, earlier. If you=20 publish (R, s) with truly random R=3DkG choice you are not leaking more tha= n=20 what already existed with the pubkey H; that's true if HVZK holds and=20 assuming the ROM (except it has to be "QROM" now, right). However! There might be a non-technical reason to avoid H directly: it's a= =20 bit like toxic waste in powers-of-tau and similar: suppose a whitehat=20 organization is targeting a tripwire. If that dlog knowledge is exposed (in= =20 the process of creating a valid signature) it has to be destroyed=20 "trustfully", since it'll allow spending of all kinds of coins[1]. This=20 comment is only relevant of course if there is a CRQC which costs 2 months= =20 and $100m to run, if it's easy to find a specific dlog whenever, then=20 nothing to talk about. So yeah I would go with the abundance of caution, myself; don't see how it= =20 hurts. [1] Uh not actually sure about that. There was a +rG tweak suggested in=20 BIP341 for better privacy. Don't know how widely it was used (curious, in= =20 codebases I looked at, it wasn't). Silent Payments BIP352 explicitly carves= =20 out H which, I dunno if that proves anything, but it's an example of people= =20 tacitly assuming no tweaking happens. If the tweaking was used it would at= =20 least limit how much risk exists with H, though not remove it. On Tuesday, August 18, 2026 at 8:37:02=E2=80=AFPM UTC-6 conduition wrote: > Oh wait, it's much simpler (not perhaps in character, but concretely): we= =20 > don't need to talk about some general ZKP system here, right. If we all= =20 > agree on a 192 bit curve, and a NUMS point on that curve, then in the=20 > OP_RETURN (say), we just need to put the point's dlog and consensus nodes= =20 > only have to do a single scalar multiplication on that curve to verify. > > Exactly. Also, the canary proof need not be the NUMS discrete log itself,= =20 > it could also be a signature proving knowledge of the dlog without=20 > revealing it outright. Dlog exposure is simpler and faster to verify;=20 > Signature allows the first QC to identify itself later. (IDK if useful) > > > Right, so: the QCAP thread was about a canary rather than a full tripwire > > Oh I misunderstood. So to be clear, a "canary" is just a social signal=20 > that should push consensus to activate a soft fork, whereas a "tripwire" = is=20 > an unattended system that automatically triggers a change to consensus=20 > rules. > > While it's certainly possible it's actually triggered by a cooperative=20 > CRQC, that's not how I expect ECC disabling to happen (instead I expect a= =20 > community consensus-changing effort, effected through Miner Lockdown or= =20 > otherwise). The Tripwire just sets an unambiguous expectation that=20 > disabling is intended by Q-day. > > In the absence of evidence, I expect this fork to be highly contentious o= r=20 > delayed until hard evidence is available.=20 > > I don't think the presence of a 192-bit canary changes this expectation= =20 > much. 192-bit ECDLP broken (or breakable) is certainly a legitimate reaso= n=20 > for panic, but nothing prevents that information from being used at the= =20 > human layer without it needing to have been part of consensus rules. > > > I agree but for a different reason on top. Given the polynomial efficienc= y=20 > of Shor, and the massive time/money investment needed to build quantum=20 > computers, we have no reason to expect anyone will build a QC that can=20 > break 192-bit curves but *not* 256-bit curves. There is actually=20 > incentive *not* to do so, especially if breaking a 192-bit curve will=20 > cause the Bitcoin network (the most ripe target to pay off QC investors) = to=20 > react by locking itself down.=20 > Think of it this way: If you have the mans to build a stable 900=20 > logical-qubit quantum-computer, why not spend the extra time and money to= =20 > build a 1200 logical-qubit quantum computer? Is a 1.5x factor improvement= =20 > really so hard at this point? If you do expend the effort, then at least= =20 > you stand a chance to make some money (e.g. by decrypting old internet=20 > traffic on behalf of the NSA). > From the google paper: > > Given broad progress across multiple hardware architectures, the safe ass= umption=20 > is that there may be little time between the breaking of 256-bit ECDLP an= d=20 > the breaking of 1024-bit ECDLP. > > I think I'm coming to the conclusion that a 256-bit ST-ECDLP tripwire is= =20 > the way to go, because at least then the canary is unambiguously dead, an= d=20 > it's time to stop using secp256k1, whereas 192-bit curves leave a shred o= f=20 > doubt. > > This makes me wonder about using a subgroup of a very related curve: for= =20 > example y^2 =3D x^3 + 3 (mod 2^256-2^32-977) has a subgroup of order=20 > ~2^187.11, which would use all the same finite field arithmetic and almos= t=20 > the same multiplication logic (only doubling is affected). Keeping the=20 > field modulus the same does mean the q-bit count is unaffected though, on= ly=20 > the gate count decreases (proportional to logarithm of group order). Like= =20 > other weaker-curve constructions, I don't think this is worth it, but wan= t=20 > to throw the idea out there. > > > Really interesting idea there. Small correction: I believe Shor's space= =20 > (qubit) requirements are dominated primarily by the group order that we a= re=20 > searching for the dlog within, not by the size of the field used for the= =20 > the elliptic curve group operation. I'm pretty sure the field size would= =20 > affect runtime complexity (gate count), but not qubit count requirements.= =20 > (Happy to be corrected). If I'm correct, a group order of approx 2^187=20 > would need approx 842 qubits (at least) to break. > > Still, as previously discussed, I'm unsure if a canary which is only=20 > *slightly* harder to break would be meaningful. It'd be nice if we could= =20 > find some problem which quantum computers of, say, 150 qubits could do, b= ut=20 > which classical computers cannot (feasibly) solve. Then we might have a= =20 > reasonably predictive canary which could be solved by cooperative. > > Also found this related paper which proposes an incremental ladder of=20 > canaries using NUMS points on a sequence of curves of increasing size:=20 > https://arxiv.org/pdf/2508.14011 > > I also don't think optimizing for multi-target ECDLP adds much. > > > Strongly agree. > > From a simplicity standpoint, I think just having a "a UTXO with=20 > scriptPubKey X is spent" is ideal, because it reuses all existing block a= nd=20 > transaction validation logic, and just adds a trivial trigger. > > > I would like to make a case that we should expend the extra effort and no= t=20 > bind the canary to a specific UTXO. I will point to Antoine's game theory= =20 > arguments about reorgs and miner collusion with CRQCs.=20 > > If we tie the canary to a specific UTXO, or even to any UTXO with a=20 > specific script, then this makes miner censorship of the canary proof ver= y=20 > easy: Just block spends of that UTXO (or of any UTXO unlocking the chosen= =20 > script). > > If, on the other hand, we had nodes check something almost as simple, lik= e=20 > for example "check every 32-byte OP_RETURN to see if it happens to be the= =20 > dlog of the NUMS point", then any user can choose to include the proof in= =20 > their transactions at relatively little cost. Any miners who want to cens= or=20 > the canary proof will have to also censor any such transactions, and so= =20 > they lose out on the potential fee revenue of the entire TX by doing so. > > In the extreme case, if every transaction in the mempool contained the=20 > canary proof as an OP_RETURN, then censoring miners would receive no fee= =20 > revenue at all - they would have to mine empty blocks. > > I'm not sure if this incentive is meaningful when compared to the=20 > potential bribes that a miner could be offered by a CRQC, but still it is= =20 > worth considering. It does have the down side that it will slow down bloc= k=20 > validation slightly (one EC mult per 32-byte OP_RETURN). Maybe this could= =20 > be accounted for somehow in the sigops budget? > > regards, > conduition > > > On Tuesday, August 18th, 2026 at 1:30 PM, Pieter Wuille=20 > bitco...@wuille.net wrote: > > Hi all, > > I'm unconvinced the complexity of a 192-bit canary is worth it. Picking a= =20 > curve and a NUMS point on it are not hard, but very little of=20 > libsecp256k1's code can be reused (even field arithmetic is optimized=20 > specifically for the secp256k1 prime). A more generic implementation is= =20 > possible of course, but it's still a pretty big piece of engineering for= =20 > what is IMO very little gain. > > There is a pretty fundamental difference between a secp256k1 Tripwire and= =20 > a canary for weaker curves, in that the former isn't intended to be=20 > predictive. Its purpose is setting a codified upper bound on when ECC=20 > (within PQC output types) is expected to be disabled. While it's certainl= y=20 > possible it's actually triggered by a cooperative CRQC, that's not how I= =20 > expect ECC disabling to happen (instead I expect a community=20 > consensus-changing effort, effected through Miner Lockdown or otherwise).= =20 > The Tripwire just sets an unambiguous expectation that disabling is=20 > intended by Q-day. > > I don't think the presence of a 192-bit canary changes this expectation= =20 > much. 192-bit ECDLP broken (or breakable) is certainly a legitimate reaso= n=20 > for panic, but nothing prevents that information from being used at the= =20 > 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 t= o=20 > the real secp256k1 ECDLP for people to bother building/programming/runnin= g=20 > a QC for it. This is of course a question that exists for secp256k1 itsel= f:=20 > whether a *cooperative* entity with the capability of building a=20 > secp256k1-ECDLP QRQC would bother doing so. But it's even more tenuous fo= r=20 > weaker problems, if they're not so much weaker that they're trivial. This= =20 > makes me wonder about using a subgroup of a very related curve: for examp= le=20 > y^2 =3D x^3 + 3 (mod 2^256-2^32-977) has a subgroup of order ~2^187.11, w= hich=20 > would use all the same finite field arithmetic and almost the same=20 > multiplication logic (only doubling is affected). Keeping the field modul= us=20 > the same does mean the q-bit count is unaffected though, only the gate=20 > count decreases (proportional to logarithm of group order). Like other=20 > weaker-curve constructions, I don't think this is worth it, but want to= =20 > throw the idea out there. > > I also don't think optimizing for multi-target ECDLP adds much. My=20 > understanding is that Shor's doesn't benefit from multiple targets? I'm n= ot=20 > opposed to giving freedom of finding (m,x) such that H(m) =3D x*G, but I= =20 > don't see why that would encourage a cooperative CRQC to work on breaking= =20 > it. > > Regarding using the BIP-341 H itself as canary, I don't think that's a=20 > problem if the ECDLP break proof is a Schnorr signature (as opposed to=20 > revealing the DLP itself). But it also makes sense to be as conservative = as=20 > possible here; it may make sense to make a selection of hash functions,= =20 > feed them all as much input as possible (the genesis block is a good idea= ,=20 > the existing generator G, maybe a block hash from a time when the=20 > activation parameters are decided, or even a block hash when the block go= es=20 > live as suggested by Tadge though that adds hash-to-curve logic to=20 > consensus too), and then XOR (or hash) all hash results together. > > From a simplicity standpoint, I think just having a "a UTXO with=20 > scriptPubKey X is spent" is ideal, because it reuses all existing block a= nd=20 > transaction validation logic, and just adds a trivial trigger. It's not= =20 > compatible with any weaker curve construction of course, or with AJ's=20 > H-dependent DLP proof which could enlist non-cooperative CRQC, but I don'= t=20 > think that's worth complicating matters for. > > Cheers, > > -- > Pieter > > -- > > > You received this message because you are subscribed to a topic in the=20 > Google Groups "Bitcoin Development Mailing List" group. > To unsubscribe from this topic, visit=20 > https://groups.google.com/d/topic/bitcoindev/aWYtPLVPZ3U/unsubscribe. > To unsubscribe from this group and all its topics, send an email to=20 > bitcoindev+...@googlegroups.com. > > To view this discussion visit=20 > https://groups.google.com/d/msgid/bitcoindev/td8wPWxRVg0rQIdP41uibTvWuIoC= vGYpvfX022TaDurf-qu1TMm1TmWogw-JTs4C7Mt-97cvJCBW66z4g-Vc2fsSoo-Qxfm8Lcnd384= Uink%3D%40wuille.net > . > > --=20 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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= baff534c-a392-4af7-8264-998c3390fe84n%40googlegroups.com. ------=_Part_44997_877819814.1787152720081 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi conduition,

>=C2=A0Given the polynomial efficien= cy of Shor, and the massive time/money investment needed to build quantum c= omputers, we have no reason to expect anyone will build a QC that can break= 192-bit curves but=C2=A0not=C2=A0256-bit curves. There is actually incentive= =C2=A0not=C2=A0to do so, especially if breaking a 192-bit curve will cause the = Bitcoin network (the most ripe target to pay off QC investors) to react by = locking itself down.=C2=A0

Well, but this brings me right back to my first comment here = (not that it is *my* comment, it's been said elsewhere in thread): this tri= pwire concept is not a defence against an adversary, right; if the first QC= is expensive and difficult (likely), and if they decide to be adversarial,= they won't be tripping any wires. But surely it follows, that they have ju= st as much incentive to not trip the 256 wire as the 192 wire.
=

=
Anyway I will try t= o now avoid further nerd sniping (including against myself) talking about s= maller order curves; I do agree with the points raised, that it's not a suf= ficiently practical idea (given secp256k1's most excellent property, its co= factor of 1, is extremely unhelpful in this particular case! - therefore ni= ce idea, Pieter, with the 'algebraically similar curve but with subgroups',= but I'm willing to bet you're right that that doesn't cut it, either) on m= ore than one axis.

Smaller group *canaries* (not tripwires) are still interesting = I think. Not amazing, but maybe quite valuable.

>=C2=A0Also found this= related paper which proposes an incremental ladder of canaries using NUMS = points on a sequence of curves of increasing size:=C2=A0https://arxiv.org/pdf/2508.14011
interesting find, thanks!

>=C2=A0If, on the other hand, we had nodes= check something almost as simple, like for example "check every 32-byte OP= _RETURN to see if it happens to be the dlog of the NUMS point", then any us= er can choose to include the proof in their transactions at relatively litt= le cost. Any miners who want to censor the canary proof will have to also c= ensor any such transactions, and so they lose out on the potential fee reve= nue of the entire TX by doing so.

Yes that does seem to be better than single utxo. But = perhaps the difference isn't that significant in practice?

<= div>>=C2=A0I'm not sure = if this incentive is meaningful when compared to the potential bribes that = a miner could be offered by a CRQC, but still it is worth considering. It d= oes have the down side that it will slow down block validation slightly (on= e EC mult per 32-byte OP_RETURN). Maybe this could be accounted for somehow= in the sigops budget?

I agree it doesn't seem very reasonable that there's a way to cou= nter such a huge incentive in *a* miner as one related to a QC break.

It also makes me t= hink: that's not how consensus changes usually work, eh. Giving miners the = ability to censor an update seems antithetical. It's also weirdly the oppos= ite shape to what you want: it activates with the permission of 1 of N mine= rs (weighted by hashrate), which means it's kind of guaranteed to occur onc= e the proof exists, but could be quite slow. The counterargument might be: = that's not going to happen! Once the proof is public, a miner deliberately = not mining it is very transparently a bad actor. Not sure. Seems a bit wobb= ly but not crazy.

Pieter,
> Regarding using the BIP-3= 41 H itself as canary, I don't think that's a problem if the ECDLP break pr= oof 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 poss= ible (the genesis block is a good idea, the existing generator G, maybe a b= lock 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 res= ults together.

Good point about signature, I wasn't considering = that, earlier. If you publish (R, s) with truly random R=3DkG choice you ar= e not leaking more than what already existed with the pubkey H; that's true= if HVZK holds and assuming the ROM (except it has to be "QROM" now, right)= .

However! There might be a non-technical reason to av= oid H directly: it's a bit like toxic waste in powers-of-tau and similar: s= uppose a whitehat organization is targeting a tripwire. If that dlog knowle= dge is exposed (in the process of creating a valid signature) it has to be = destroyed "trustfully", since it'll allow spending of all kinds of coins[1]= . This comment is only relevant of course if there is a CRQC which costs 2 = months and $100m to run, if it's easy to find a specific dlog whenever, the= n nothing to talk about.

So yeah I would go with the abundance o= f caution, myself; don't see how it hurts.

[1] Uh not actually sure about = that. There was a +rG tweak suggested in BIP341 for better privacy. Don't k= now how widely it was used (curious, in codebases I looked at, it wasn't). = Silent Payments BIP352 explicitly carves out H which, I dunno if that prove= s anything, but it's an example of people tacitly assuming no tweaking happ= ens. If the tweaking was used it would at least limit how much risk exists = with H, though not remove it.

On Tuesday, August 18, 2026 at 8:37:02=E2=80= =AFPM UTC-6 conduition wrote:

Oh wait, it's much simpler (not perhaps in character, but concretely= ): we don't need to talk about some general ZKP system here, right. If = we all agree on a 192 bit curve, and a NUMS point on that curve, then in th= e OP_RETURN (say), we just need to put the point's dlog and consensus n= odes only have to do a single scalar multiplication on that curve to verify= .

Exactly. Also, the canary proof need not be the NUMS discrete log itself, i= t could also be a signature proving knowledge of the dlog without revealing= it outright. Dlog exposure is simpler and faster to verify; Signature allo= ws the first QC to identify itself later. (IDK if useful)


Right, so: the QCAP thread was about a canary ra= ther than a full tripwire
Oh = I misunderstood. So to be clear, a "canary" is just a social sign= al that should push consensus to activate a soft fork, whereas a "trip= wire" is an unattended system that automatically triggers a change to = consensus rules.

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 M= iner Lockdown or otherwise). The Tripwire just sets an unambiguous expectat= ion that disabling is intended by Q-day.
<= /div>
In the absence of evidence, I expect this fork to be = highly contentious or delayed until hard evidence is available.

I don't think the = presence of a 192-bit canary changes this expectation much. 192-bit ECDLP b= roken (or breakable) is certainly a legitimate reason for panic, but nothin= g prevents that information from being used at the human layer without it n= eeding to have been part of consensus rules.
<= /span>
I agree but for a different reason= on top. Given the polynomial efficiency of Shor, and the massive time/mone= y investment needed to build quantum computers, we have no reason to expect= anyone will build a QC that can break 192-bit curves but not=C2=A02= 56-bit curves. There is actually incentive not=C2=A0to do so, especi= ally if breaking a 192-bit curve will cause the Bitcoin network (the most r= ipe target to pay off QC investors) to react by locking itself down.=C2=A0<= /span>
Think of it t= his way: If you have the mans to build a stable 900 logical-qubit quantum-c= omputer, why not spend the extra time and money to build a 1200 logical-qub= it quantum computer? Is a 1.5x factor improvement really so hard at this po= int? If you do expend the effort, then at least you stand a chance to make = some money (e.g. by decrypting old internet traffic on behalf of the NSA).<= /div>
From the google pape= r:
Given broad progress across= multiple hardware architectures, the safe assumption is that there = may be little time between the breaking of 256-bit ECDLP and the breaking o= f 1024-bit=C2=A0ECDLP.
I think I'm coming to the conclusion t= hat a 256-bit ST-ECDLP tripwire is the way to go, because at least then the= canary is unambiguously dead, and it's time to stop using secp256k1, w= hereas 192-bit curves leave a shred of doubt.
This makes me wonder about using a subgroup of a very related curve: = for example y^2 =3D 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 th= e same multiplication logic (only doubling is affected). Keeping the field = modulus the same does mean the q-bit count is unaffected though, only the g= ate 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.

<= div style=3D"margin-top:14px;margin-bottom:14px">
Really interest= ing idea there. Small correction: I believe Shor's space (qubit) requir= ements are dominated primarily by the group order that we are searching for= the dlog within, not by the size of the field used for the the elliptic cu= rve group operation. I'm pretty sure the field size would affect runtim= e complexity (gate count), but not qubit count requirements. (Happy to be c= orrected). If I'm correct, a group order of approx 2^187 would need app= rox 842 qubits (at least) to break.

Still, as previously discussed, I'm unsure if a canary which is o= nly slightly=C2=A0harder to break would be meaningful. It'd be n= ice if we could find some problem which quantum computers of, say, 150 qubi= ts could do, but which classical computers cannot (feasibly) solve. Then we= might have a reasonably predictive canary which could be solved by coopera= tive.

Also found this related paper w= hich proposes an incremental ladder of canaries using NUMS points on a sequ= ence of curves of increasing size:=C2=A0https://arxiv.org/pdf/2508.14011

I also don&#= 39;t think optimizing for multi-target ECDLP adds much.

Strongly agree.

From a simplicity standpoin= t, I think just having a "a UTXO with scriptPubKey X is spent" is= ideal, because it reuses all existing block and transaction validation log= ic, and just adds a trivial trigger.

I would like to make a case that we should expend the extra effort = and not bind the canary to a specific UTXO. I will point to Antoine's g= ame theory arguments about reorgs and miner collusion with CRQCs.=C2=A0

If we tie the canary to a s= pecific UTXO, or even to any UTXO with a specific script, then this makes m= iner censorship of the canary proof very easy: Just block spends of that UT= XO (or of any UTXO unlocking the chosen script).
If, on the other hand, we had nodes check somethin= g almost as simple, like for example "check every 32-byte OP_RETURN to= see if it happens to be the dlog of the NUMS point", then any user ca= n choose to include the proof in their transactions at relatively little co= st. Any miners who want to censor the canary proof will have to also censor= any such transactions, and so they lose out on the potential fee revenue o= f the entire TX by doing so.

<= span>In the extreme case, if every transaction in the mempool contained the= canary proof as an OP_RETURN, then censoring miners would receive no fee r= evenue at all - they would have to mine empty blocks.

I'm not sure if this incentive is meaning= ful when compared to the potential bribes that a miner could be offered by = a CRQC, but still it is worth considering. It does have the down side that = it will slow down block validation slightly (one EC mult per 32-byte OP_RET= URN). Maybe this could be accounted for somehow in the sigops budget?

regards,<= /span>
conduitio= n


On Tuesday, August 18th, 2026 at 1:30 PM, Pieter Wuille bitco...@wuille.net wrote:

Hi all,

I'm unconvinced the complexity of a 192-bit canary is worth it. Pick= ing a curve and a NUMS point on it are not hard, but very little of libsecp= 256k1's code can be reused (even field arithmetic is optimized specific= ally 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 I= MO very little gain.

There is a pretty fundamental difference between a secp256k1 Tripwire an= d a canary for weaker curves, in that the former isn't intended to be p= redictive. Its purpose is setting a codified upper bound on when ECC (withi= n PQC output types) is expected to be disabled. While it's certainly po= ssible it's actually triggered by a cooperative CRQC, that's not ho= w I expect ECC disabling to happen (instead I expect a community consensus-= changing effort, effected through Miner Lockdown or otherwise). The Tripwir= e 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 expectat= ion much. 192-bit ECDLP broken (or breakable) is certainly a legitimate rea= son 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 "simila= r" a canary needs to be to the real secp256k1 ECDLP for people to both= er building/programming/running a QC for it. This is of course a question t= hat exists for secp256k1 itself: whether a cooperative entity with= the capability of building a secp256k1-ECDLP QRQC would bother doing so. B= ut it's even more tenuous for weaker problems, if they're not so mu= ch weaker that they're trivial. This makes me wonder about using a subg= roup of a very related curve: for example y^2 =3D x^3 + 3 (mod 2^256-2^32-9= 77) 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 logarith= m 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 u= nderstanding 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) =3D 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&#= 39;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 activati= on 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 sc= riptPubKey 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= 9;s H-dependent DLP proof which could enlist non-cooperative CRQC, but I do= n't think that's worth complicating matters for.

Cheers,

--
Pieter

--


You received this message because you are subscribed to a topic in the Goog= le Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/bitcoindev/aWYtPLVPZ3U/unsubscribe.<= br> To unsubscribe from this group and all its topics, send an email to bitcoindev+...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/baff534c-a392-4af7-8264-998c3390fe84n%40googlegroups.com.
------=_Part_44997_877819814.1787152720081-- ------=_Part_44996_244015058.1787152720081--