From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 18 Aug 2026 19:37:13 -0700 Received: from mail-oo1-f62.google.com ([209.85.161.62]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wwWAx-0003na-H7 for bitcoindev@gnusha.org; Tue, 18 Aug 2026 19:37:12 -0700 Received: by mail-oo1-f62.google.com with SMTP id 006d021491bc7-6a17dafd042sf665913eaf.2 for ; Tue, 18 Aug 2026 19:37:10 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1787107023; cv=pass; d=google.com; s=arc-20260327; b=MUDy4IVwF5TdAHCWC5p8GtMOAadjNNH6l5ix5ebkiOFJeLKDAFeFZS5vN8d8AJJij5 MLqAJv+pSSxeDDSARM2i57xWJj79KylE00eyRFGfjdI5gNrbk5XebaRLuslCzAUUukwM wHYJm/E69sJYCw0xAtHoISZWYxnXCQlx3ASEf0Y6muPYQRILorSqDdjdTGVxhODJLRFN fBkYEuFLshFWu2lFz1MIcO3Sg5i5zgDHpNBIb5A5vQJuohpXDnRMS7oSg/1Oszm+LqnD sAoVuHcvkkpUJoOlKVL04R+vHod1r5RsXrnhQTpWUu+u7z+4K86Y8584+mw+d/48/Wgc enJg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:mime-version:feedback-id :references:in-reply-to:message-id:subject:cc:from:to:date :dkim-signature; bh=bra8jOxCPp+Dofz3ddVcdrH5kFFsiQH9c0QwTLLKdjA=; fh=tMBjfb57u5ZdAdGAD+8kA9x33Rp56/TwJ1j2ZuqNjBw=; b=WWZmzwMJrjS8ald/wsfmlcXeFv5HTMKhxSjWkzXYIFraLNOHXg5NyzWd2QDObp71uC MQP7VsSF3pdO+DuyeH/EoXP9YDIB2LL0aMl7+IVbu6dJwlCHe4iyrQG1sEgTlLHF2fCK BWRe1yHeO9qL5h1RqdU6D6RG9DWPiNWxQugy2d/HYSiEv0j8dczD0QtiQGeRoqlDu6k8 JwvZwkq4PyZMkxOegacm3Y8lT+VU2woXTgGGvSdEO3KE+gyMIICB6hjq+arrzgEbuCBM c7iuU0wcTRkNvc8Te+d0HiJiPxIiWfSzI9cfQv2+TvBxPi3YLCrjY2wGJnQA6viyRbGe ac2g==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=3xwrfmmr7zgnffkxmn7rd7tvgi.protonmail header.b=eMD7DJKh; spf=pass (google.com: domain of conduition@proton.me designates 109.224.244.26 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1787107023; x=1787711823; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:content-type :mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:from:to:cc:subject:date:message-id:reply-to :content-type; bh=bra8jOxCPp+Dofz3ddVcdrH5kFFsiQH9c0QwTLLKdjA=; b=yc5Xg2VezMBSMUVa4Wfvc0KumfHruqtmivPgZdZDelspYIMv5dZOMugaIkgRoVHfdi WL7xKTsXR5gpR7QBM0kFHpYKdyoxwiLonrjibTVah49tTL7BWG/kfbP/jX1bD/HbgBMm yOQSU/G16UQruy+YzqJC4wHZhBct3aoeZAAh5RRueREMEjwIBT8Yzqpm+AtqgIlsELzG TcC/giOWNj5oy3FC5RzHlCOUIB6iSYHiOv0jA3KG2ujO9tGBiKbVVFU5QUQeMmsUKNnQ dOYbGp1G0nrZ1r+QNejKJm2s5jJS408DJ/qfUr8ri8d0qZln/zm6B6xZFao/HNFJgXsK mpYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787107023; x=1787711823; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:content-type :mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:x-beenthere:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to:content-type; bh=bra8jOxCPp+Dofz3ddVcdrH5kFFsiQH9c0QwTLLKdjA=; b=SFER82n37rzA0FVInBPKZGXahix0Z65m6/wSqSmM24qdQhq41iU3Aeq/kn9CV2RHpT qN30sUHZX2tLj87NqHotuTQknT6Sb+sMwlyk6VsMP3/3NNhc8Hc57jg5LTl06VT8dl7u gfc4nVe30EYO9lG354aHxFY4wNWzz9nZ58wyWPq6ngoV8cqTp85oKlL6rsZoqhTaT6eX J2jAUHKPep48U57BS5QHGjNP49F2BYniNjxuiIBZ76VsjGmsKQD94qcoggPG2SJaBaSr MhSStINjz9PoE9EidvA4dG5i5Ywl1/My9+oPuzSz4HV9N/I6n8v3RpqLD/qYkJfOSWZ9 YcZA== X-Forwarded-Encrypted: i=2; AHgh+RrHVV9zEmQaoAL8UmgfW8QuAlq/10ozVwzIviGHQyyMXDWfjKg7gZCg5YyC1ADOpH38Oxph0G/i+cxK@gnusha.org X-Gm-Message-State: AOJu0YxVd2dPHUwxs1ce2JVktPHd3pZg3xTYXFvbz4bnisI0ZBiwLHv/ EPZvDhmxLNzMFw2ZqM/cRrkziSFe7wSEPoGdTHzisIFd44ITL5H2bQr7 X-Received: by 2002:a05:6820:c87:b0:6aa:f172:3094 with SMTP id 006d021491bc7-6b13c317834mr1894080eaf.10.1787107022585; Tue, 18 Aug 2026 19:37:02 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ATskLddTLZr5goK247ZTZjQQP3ZeYFpnKmoyx7iheztxosEbsA==" Received: by 2002:a05:6871:c8c3:b0:454:e0fd:42f0 with SMTP id 586e51a60fabf-45e5cd5d84cls5974034fac.2.-pod-prod-01-us; Tue, 18 Aug 2026 19:36:57 -0700 (PDT) X-Forwarded-Encrypted: i=2; AHgh+RoQMvTtenmiwHWJIcUnPGihxAJFOikDrrTYXV3bBV4ACV3IU61tLRyBkLJXKCu4vaF5a988HieLgR5p@googlegroups.com X-Received: by 2002:a05:6808:244c:b0:4a4:a930:1f76 with SMTP id 5614622812f47-4b2bcb0366cmr1108774b6e.11.1787107017008; Tue, 18 Aug 2026 19:36:57 -0700 (PDT) Received: by 2002:a05:6808:8905:10b0:4ab:3e9a:a867 with SMTP id 5614622812f47-4b2b548152amsb6e; Tue, 18 Aug 2026 19:32:36 -0700 (PDT) X-Forwarded-Encrypted: i=2; AHgh+RpQo706qBEsHM0rVl1c1KVlU2VuUewOjiM20NOMz9N4ErUQAqvlOdj+d+fQXGJevQlFUs1KQhWU6IvK@googlegroups.com X-Received: by 2002:a05:6808:5290:b0:4b2:8d7b:41b8 with SMTP id 5614622812f47-4b2bcc254ccmr1145608b6e.18.1787106755582; Tue, 18 Aug 2026 19:32:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1787106755; cv=none; d=google.com; s=arc-20260327; b=kQ1l7ZbHnH458BQmqIqsSeICrrDZs8yCtM9D9FJx7UPqVOwff4D+JqQk56O4M6rEPY LOECDS07FCoSA9ECBYvZrzk5oePLjXPpx+EQMXNWZAQrjnXO1xah7GMoGyKXP1SBkNPT hgAjqflZauZ6l5LH/tH9RhGJ0HaRmJtIryk3jZ6GAYfhhSZBkUtOnRbQBGEqZO9ml8q9 KcHBjtIHN39FXloIBfncGHeQ6SD6CQ0DzX3B/BKtr5Qg/0wBWMe1Ik053GZg3YtX+hCq I6wfdpFus3raldt6IEvsrbda+IAMSZ4EePPtxzilLC1tPGbDsWC6EddFgOdlcSdoOVn2 UEzA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:dkim-signature; bh=drzQlQEbqVf2M84cRJ2jXu5BUOqJLvQmoGUt/X7PEjY=; fh=Cr6pMxgOj/lu8/hIwNXq+1eUXQwk3W5ldj1SLFVbnAY=; b=UzYvIP0QNVqYrbChDtEj10hjPRqx3oFljoUrGAyyPiYzjhYxaMj3wXhV1OJ7anqxzK KI6N88Ogtsnd9o9R4hAjkRjyP1gJW5Zzb1yJ5gv+AojIOlvY/IF6gH9pIBgIoPjHWfqC EVPe3KlnIUDT9EDi8S4NWt2RyYTh8omAhecHa+oUCdLw2HjAyTMSzqpTaEdNPWQ5/zch rIVXHk2RjJIRmlEcc8czwW5drHc+OS87IkLV7V7BH55XeMJ4IzAj+WsrwzzchfltB+2Y LfKO3nzg3Seei7xC8ZwvRY5Lo2RIx8IoNvYOInU3ZedtPQ+ou1K5Ft6KFQcTY4cUeWPC X+SQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=3xwrfmmr7zgnffkxmn7rd7tvgi.protonmail header.b=eMD7DJKh; spf=pass (google.com: domain of conduition@proton.me designates 109.224.244.26 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me Received: from mail-24426.protonmail.ch (mail-24426.protonmail.ch. [109.224.244.26]) by gmr-mx.google.com with ESMTPS id 5614622812f47-4b2ad734443si66057b6e.3.2026.08.18.19.32.34 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 18 Aug 2026 19:32:35 -0700 (PDT) Received-SPF: pass (google.com: domain of conduition@proton.me designates 109.224.244.26 as permitted sender) client-ip=109.224.244.26; Date: Wed, 19 Aug 2026 02:32:26 +0000 To: Pieter Wuille From: "'conduition' via Bitcoin Development Mailing List" Cc: waxwing/ AdamISZ , Bitcoin Development Mailing List Subject: Re: [bitcoindev] Giving teeth to expected EC disabling: P2XX(-T)(-ML) Message-ID: In-Reply-To: References: <22f8b95d-403c-4a3e-ad64-221faf2ea851n@googlegroups.com> Feedback-ID: 72003692:user:proton X-Pm-Message-ID: d30552406172d10cee5f484527b76b3d628b9ed9 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------f410809a874bc5579610713f24bed2d1c405b78feff2c23df94a3f3db37cb346"; charset=utf-8 X-Original-Sender: conduition@proton.me X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=3xwrfmmr7zgnffkxmn7rd7tvgi.protonmail header.b=eMD7DJKh; spf=pass (google.com: domain of conduition@proton.me designates 109.224.244.26 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me X-Original-From: conduition Reply-To: conduition 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.1 (++) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------f410809a874bc5579610713f24bed2d1c405b78feff2c23df94a3f3db37cb346 Content-Type: multipart/mixed;boundary=---------------------21ccdcc27e0963ae4e2dcaf2e0a7afa5 -----------------------21ccdcc27e0963ae4e2dcaf2e0a7afa5 Content-Type: multipart/alternative;boundary=---------------------7827fb6207658ba30f2a1fdaa8636465 -----------------------7827fb6207658ba30f2a1fdaa8636465 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" > 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 ag= ree on a 192 bit curve, and a NUMS point on that curve, then in the OP_RETU= RN (say), we just need to put the point's dlog and consensus nodes only hav= e 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 rather than a full tripwire Oh I misunderstood. So to be clear, a "canary" is just a social signal that= should push consensus to activate a soft fork, whereas a "tripwire" is an = unattended system that automatically triggers a change to consensus rules. > While it's certainly possible it's actually triggered by a cooperative CR= QC, that's not how I expect ECC disabling to happen (instead I expect a com= munity consensus-changing effort, effected through Miner Lockdown or otherw= ise). The Tripwire just sets an unambiguous expectation that disabling is i= ntended by Q-day. 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 m= uch. 192-bit ECDLP broken (or breakable) is certainly a legitimate reason f= or panic, but nothing prevents that information from being used at the huma= n layer without it needing to have been part of consensus rules. I agree but for a different reason on top. Given the polynomial efficiency = of Shor, and the massive time/money investment needed to build quantum comp= uters, we have no reason to expect anyone will build a QC that can break 19= 2-bit curves but not=C2=A0256-bit curves. There is actually incentive not= =C2=A0to do so, especially if breaking a 192-bit curve will cause the Bitco= in network (the most ripe target to pay off QC investors) to react by locki= ng itself down.=C2=A0 Think of it this way: If you have the mans to build a stable 900 logical-qu= bit quantum-computer, why not spend the extra time and money to build a 120= 0 logical-qubit quantum computer? Is a 1.5x factor improvement really so ha= rd at this point? If you do expend the effort, then at least you stand a ch= ance to make some money (e.g. by decrypting old internet traffic on behalf = of the NSA). >From the google paper: > Given broad progress across multiple hardware architectures, the safe ass= umption is that there may be little time between the breaking of 256-bit EC= DLP and the breaking of 1024-bit=C2=A0ECDLP. I think I'm coming to the conclusion that a 256-bit ST-ECDLP tripwire is th= e way to go, because at least then the canary is unambiguously dead, and it= 's time to stop using secp256k1, whereas 192-bit curves leave a shred of do= ubt. > 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 the sa= me multiplication logic (only doubling is affected). Keeping the field modu= lus the same does mean the q-bit count is unaffected though, only the gate = count decreases (proportional to logarithm of group order). Like other weak= er-curve constructions, I don't think this is worth it, but want to throw t= he idea out there. Really interesting idea there. Small correction: I believe Shor's space (qu= bit) requirements are dominated primarily by the group order that we are se= arching for the dlog within, not by the size of the field used for the the = elliptic curve group operation. I'm pretty sure the field size would affect= runtime complexity (gate count), but not qubit count requirements. (Happy = to be corrected). If I'm correct, a group order of approx 2^187 would need = approx 842 qubits (at least) to break. Still, as previously discussed, I'm unsure if a canary which is only slight= ly=C2=A0harder to break would be meaningful. It'd be nice if we could find = some problem which quantum computers of, say, 150 qubits could do, but whic= h classical computers cannot (feasibly) solve. Then we might have a reasona= bly predictive canary which could be solved by cooperative. Also found this related paper which proposes an incremental ladder of canar= ies using NUMS points on a sequence of curves of increasing size:=C2=A0http= s://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 scriptPu= bKey X is spent" is ideal, because it reuses all existing block and transac= tion validation logic, 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 game theory a= rguments about reorgs and miner collusion with CRQCs.=C2=A0 If we tie the canary to a specific UTXO, or even to any UTXO with a specifi= c script, then this makes miner censorship of the canary proof very easy: J= ust block spends of that UTXO (or of any UTXO unlocking the chosen script). If, 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 d= log of the NUMS point", then any user can choose to include the proof in th= eir transactions at relatively little cost. Any miners who want to censor t= he canary proof will have to also censor any such transactions, and so 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 cana= ry proof as an OP_RETURN, then censoring miners would receive no fee revenu= e at all - they would have to mine empty blocks. I'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 cons= idering. It does have the down side that it will slow down block validation= slightly (one EC mult per 32-byte OP_RETURN). Maybe this could be accounte= d for somehow in the sigops budget? regards, conduition On Tuesday, August 18th, 2026 at 1:30 PM, Pieter Wuille bitcoin-dev@wuille.= net wrote: > Hi all, >=20 > 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 littl= e gain. >=20 > 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 predic= tive. 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 di= sabling to happen (instead I expect a community consensus-changing effort, = effected through Miner Lockdown or otherwise). The Tripwire just sets an un= ambiguous expectation that disabling is intended by Q-day. >=20 > I don't think the presence of a 192-bit canary changes this expectation m= uch. 192-bit ECDLP broken (or breakable) is certainly a legitimate reason f= or panic, but nothing prevents that information from being used at the huma= n layer without it needing to have been part of consensus rules. >=20 > Relatedly, something I don't know is how "similar" a canary needs to be t= o the real secp256k1 ECDLP for people to bother building/programming/runnin= g a QC for it. This is of course a question that exists for secp256k1 itsel= f: 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 pr= oblems, if they're not so much weaker that they're trivial. This makes me w= onder 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 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 construc= tions, I don't think this is worth it, but want to throw the idea out there= . >=20 > I also don't think optimizing for multi-target ECDLP adds much. My unders= tanding is that Shor's doesn't benefit from multiple targets? I'm not oppos= ed to giving freedom of finding (m,x) such that H(m) =3D x*G, but I don't s= ee why that would encourage a cooperative CRQC to work on breaking it. >=20 > Regarding using the BIP-341 H itself as canary, I don't think that's a pr= oblem if the ECDLP break proof is a Schnorr signature (as opposed to reveal= ing the DLP itself). But it also makes sense to be as conservative as possi= ble here; it may make sense to make a selection of hash functions, feed the= m all as much input as possible (the genesis block is a good idea, the exis= ting generator G, maybe a block hash from a time when the activation parame= ters are decided, or even a block hash when the block goes live as suggeste= d by Tadge though that adds hash-to-curve logic to consensus too), and then= XOR (or hash) all hash results together. >=20 > From a simplicity standpoint, I think just having a "a UTXO with scriptPu= bKey X is spent" is ideal, because it reuses all existing block and transac= tion 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 wo= rth complicating matters for. >=20 > Cheers, >=20 > -- > Pieter >=20 > -- > You received this message because you are subscribed to a topic in the Go= ogle Groups "Bitcoin Development Mailing List" group. > To unsubscribe from this topic, visit https://groups.google.com/d/topic/b= itcoindev/aWYtPLVPZ3U/unsubscribe. > To unsubscribe from this group and all its topics, send an email to bitco= indev+unsubscribe@googlegroups.com. > To view this discussion visit https://groups.google.com/d/msgid/bitcoinde= v/td8wPWxRVg0rQIdP41uibTvWuIoCvGYpvfX022TaDurf-qu1TMm1TmWogw-JTs4C7Mt-97cvJ= CBW66z4g-Vc2fsSoo-Qxfm8Lcnd384Uink%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/= FhcVTVM6flM4OpPCZpaGbC3msQG9kG48uvyz6T4qdNv8iAq-clhoMmNmRWSSWs78hug3KZSsKG3= Mi2lZIzo5PFY-WvbvxdA0Ssj-G2HCz2o%3D%40proton.me. -----------------------7827fb6207658ba30f2a1fdaa8636465 Content-Type: multipart/related;boundary=---------------------284ae3bc13313fd93821db012ac9074c -----------------------284ae3bc13313fd93821db012ac9074c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Oh wait, it's much simpler (not perhaps in character, but concretely): w= e don't need to talk about some general ZKP system here, right. If we all a= gree on a 192 bit curve, and a NUMS point on that curve, then in the OP_RET= URN (say), we just need to put the point's dlog and consensus nodes only ha= ve 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: t= he QCAP thread was about a canary rather than a full tripwire
Oh I misunder= stood. So to be clear, a "canary" is just a social signal that should push = consensus to activate a soft fork, whereas a "tripwire" is an unattended sy= stem that automatically triggers a change to consensus rules.
<= div style=3D"margin-top: 14px; margin-bottom: 14px;">
While it's certainly pos= sible it's actually triggered by a cooperative CRQC, that's not how I expec= t ECC disabling to happen (instead I expect a community consensus-changing = effort, effected through Miner Lockdown or otherwise). The Tripwire just se= ts 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 certa= inly a legitimate reason for panic, but nothing prevents that information f= rom being used at the human layer without it needing to have been part of c= onsensus rules.

I agree but for a different reason = on top. Given the polynomial efficiency of Shor, and the massive time/money= 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 25= 6-bit curves. There is actually incentive not to do so, especia= lly if breaking a 192-bit curve will cause the Bitcoin network (the most ri= pe target to pay off QC investors) to react by locking itself down. 
Think of i= t this way: If you have the mans to build a stable 900 logical-qubit quantu= m-computer, why not spend the extra time and money to build a 1200 logical-= qubit quantum computer? Is a 1.5x factor improvement really so hard at this= point? If you do expend the effort, then at least you stand a chance to ma= ke some money (e.g. by decrypting old internet traffic on behalf of the NSA= ).
From the goog= le paper:
= 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 of 1024-bit ECDLP.
I thi= nk I'm coming to the conclusion that a 256-bit ST-ECDLP tripwire is the way= to go, because at least then the canary is unambiguously dead, and it's ti= me to stop using secp256k1, whereas 192-bit curves leave a shred of doubt.<= /div>
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 thr= ow the idea out there.

<= div>Really interesting idea there. Small correction: I believe Shor's= space (qubit) requirements are dominated primarily by the group order that= we are searching for the dlog within, not by the size of the field used fo= r the the elliptic curve group operation. I'm pretty sure the field size wo= uld affect runtime complexity (gate count), but not qubit count requirement= s. (Happy to be corrected). If I'm correct, a group order of approx 2^187 w= ould need approx 842 qubits (at least) to break.
Still, as previously discussed, I'm unsure if a canary w= hich is only slightly harder to break would be meaningful. It'd= be nice if we could find some problem which quantum computers of, say, 150= qubits could do, but which classical computers cannot (feasibly) solve. Th= en we might have a reasonably predictive canary which could be solved by co= operative.

Also found this related pa= per which proposes an incremental ladder of canaries using NUMS points on a= sequence of curves of increasing size: https://arxiv.org/pdf/2508.14011

I also don't think optimizing for multi-target ECDLP adds much.

Strongly ag= ree.

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 vali= dation logic, 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 specifi= c UTXO. I will point to Antoine's game theory arguments about reorgs and mi= ner collusion with CRQCs. 

If we tie the canary to a specific UTXO, or even to any UTXO with a= specific script, then this makes miner censorship of the canary proof very= easy: Just block spends of that UTXO (or of any UTXO unlocking the chosen = script).

If, on the othe= r hand, we had nodes check something almost as simple, like for example "ch= eck every 32-byte OP_RETURN to see if it happens to be the dlog of the NUMS= point", then any user can choose to include the proof in their transaction= s at relatively little cost. Any miners who want to censor the canary proof= will have to also censor any such transactions, and so they lose out on th= e potential fee revenue of the entire TX by doing so.

In the extreme case, if every transaction in = the mempool contained the canary proof as an OP_RETURN, then censoring mine= rs would receive no fee revenue at all - they would have to mine empty bloc= ks.

I'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 does hav= e the down side that it will slow down block validation slightly (one EC mu= lt per 32-byte OP_RETURN). Maybe this could be accounted for somehow in the= sigops budget?

regards,
conduition


On Tuesday, August 18th, 2026 at 1:30 PM, 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 libsecp256k= 1'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 litt= le 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 predi= ctive. Its purpose is setting a codified upper bound on when ECC (within PQ= C output types) is expected to be disabled. While it's certainly possible i= t's actually triggered by a cooperative CRQC, that's not how I expect ECC d= isabling to happen (instead I expect a community consensus-changing effort,= effected through Miner Lockdown or otherwise). The Tripwire just sets an u= nambiguous 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 hum= an 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/runni= ng a QC for it. This is of course a question that exists for secp256k1 itse= lf: 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 =3D x^3 + 3 (mod 2^256-2^32-977) has a subgroup of order ~2^187.11, wh= ich would use all the same finite field arithmetic and almost the same mult= iplication logic (only doubling is affected). Keeping the field modulus the= same does mean the q-bit count is unaffected though, only the gate count d= ecreases (proportional to logarithm of group order). Like other weaker-curv= e 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 under= standing is that Shor's doesn't benefit from multiple targets? I'm not oppo= sed 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's a p= roblem if the ECDLP break proof is a Schnorr signature (as opposed to revea= ling the DLP itself). But it also makes sense to be as conservative as poss= ible here; it may make sense to make a selection of hash functions, feed th= em all as much input as possible (the genesis block is a good idea, the exi= sting generator G, maybe a block hash from a time when the activation param= eters are decided, or even a block hash when the block goes live as suggest= ed by Tadge though that adds hash-to-curve logic to consensus too), and the= n XOR (or hash) all hash results together.

From a simplicity standpoint, I think just having a "a UTXO with scriptP= ubKey X is spent" is ideal, because it reuses all existing block and transa= ction validation logic, and just adds a trivial trigger. It's not compatibl= e with any weaker curve construction of course, or with AJ's H-dependent DL= P proof which could enlist non-cooperative CRQC, but I don't think that's w= orth 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/top= ic/bitcoindev/aWYtPLVPZ3U/unsubscribe.
To unsubscribe from this group and all its topics, 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 &= 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/bitcoindev/FhcVTV= M6flM4OpPCZpaGbC3msQG9kG48uvyz6T4qdNv8iAq-clhoMmNmRWSSWs78hug3KZSsKG3Mi2lZI= zo5PFY-WvbvxdA0Ssj-G2HCz2o%3D%40proton.me.
-----------------------284ae3bc13313fd93821db012ac9074c-- -----------------------7827fb6207658ba30f2a1fdaa8636465-- -----------------------21ccdcc27e0963ae4e2dcaf2e0a7afa5 Content-Type: application/pgp-keys; filename="publickey - conduition@proton.me - 0x474891AD.asc"; name="publickey - conduition@proton.me - 0x474891AD.asc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="publickey - conduition@proton.me - 0x474891AD.asc"; name="publickey - conduition@proton.me - 0x474891AD.asc" LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgp4ak1FWkRub0tSWUpLd1lCQkFI YVJ3OEJBUWRBcnBZYWFjZDgwcXdocmNaQW9VbW9NSHNWS21iZWlPZUEKcFhXbk1ybFdPZkxOSzJO dmJtUjFhWFJwYjI1QWNISnZkRzl1TG0xbElEeGpiMjVrZFdsMGFXOXVRSEJ5CmIzUnZiaTV0WlQ3 Q2pBUVFGZ29BUGdXQ1pEbm9LUVFMQ1FjSUNaQjRLV3p0aFBhenhRTVZDQW9FRmdBQwpBUUlaQVFL YkF3SWVBUlloQkVkSWthMENNdHJMZGcxM2EzZ3BiTzJFOXJQRkFBQTZhQUVBM1RmNHdqSVoKYnox K0diS0h4K09WQytNUXlVdi84RStoWUpjTE5QZnA0NEFBLzNiak5OTXN4WHdJTGZEM0xManNVVWFo CitBV2JyblVjVUFqQ2R1d3hUT01LempnRVpEbm9LUklLS3dZQkJBR1hWUUVGQVFFSFFDSXYxZW5J MU5MbAo3Zm55RzlVWk1wQ3ZsdG5vc0JrTmhQUVZxT3BXL3RKSkF3RUlCOEo0QkJnV0NBQXFCWUpr T2VncENaQjQKS1d6dGhQYXp4UUtiREJZaEJFZElrYTBDTXRyTGRnMTNhM2dwYk8yRTlyUEZBQUFR TFFEL2NCR2kwUDdwCkZTTkl2N1B6OVpkeUNVQjhzTy90dWZkV3NjQkNZK2ZMYTV3QkFNK0hTL3Jp S014RGt0TkhLakRGc2EvUgpEVDFxUGNBYXZCaXc2dDZ4Ti9jRgo9Y3d5eAotLS0tLUVORCBQR1Ag UFVCTElDIEtFWSBCTE9DSy0tLS0tCg== -----------------------21ccdcc27e0963ae4e2dcaf2e0a7afa5-- --------f410809a874bc5579610713f24bed2d1c405b78feff2c23df94a3f3db37cb346 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wrsEARYKAG0FgmqFFakJEHgpbO2E9rPFRRQAAAAAABwAIHNhbHRAbm90YXRp b25zLm9wZW5wZ3Bqcy5vcmdc8HIOL4bL+op1jRLKDt89WLgFLChDUnFiK1dT gJURjhYhBEdIka0CMtrLdg13a3gpbO2E9rPFAACitQEA9mgjl84mK7aMcddz sFyMmoYCPAqwadBF6U3FSGayGBYA/2e4AkRORENlO+E26ULiFCWXh61SJ0HA ojLaLBg8HUoK =xG5+ -----END PGP SIGNATURE----- --------f410809a874bc5579610713f24bed2d1c405b78feff2c23df94a3f3db37cb346--