From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 19 Aug 2026 15:18:53 -0700 Received: from mail-oo1-f57.google.com ([209.85.161.57]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wwocX-0006dx-1k for bitcoindev@gnusha.org; Wed, 19 Aug 2026 15:18:53 -0700 Received: by mail-oo1-f57.google.com with SMTP id 006d021491bc7-6ab0ed783aesf324760eaf.1 for ; Wed, 19 Aug 2026 15:18:52 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1787177927; cv=pass; d=google.com; s=arc-20260327; b=q4kDxnsNbB3WLB+IDoJB1YyU0Fv9KQyOBTeEp+KkkMkPqLcE7F8X9yRCgakr22OJqE joB6fzlw4MKQ4t2r8y+vikx5DwSb1bO0cvP9s0eKlM+u+Es/UjbY/DDOAN3l7j/HLmrM ZDwMbpIGtCEIB9KXHIoNgiVFEZhCUso6x1nNdshV+aanMogyDSSTYflA5TYbHWc7hVHg 2XvVp5MKXiyazutaXPZQGJA8J3iLM75HiK6eFbpnybLsP90pjR9YhhFe5xnC492uVIb4 chUiu/m2U8yZXUmCUc3qZoptEjT2Fu2SYULKmKJq1qQHD9Vlcx8vRUYu/Wi/4yfHjm4y j2SQ== 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:content-transfer-encoding :mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:sender:dkim-signature; bh=VYdLGDfY7dVFTIU0EbeiHZpnh6XF62ux3NHr5MdWzBk=; fh=ZX08dxQsDGwMjlkXOQzDjMJ8xkTqfn2Rvec9u4Hv0sQ=; b=njQA2qdizP1edzSx4WAmWCdL+2AcsgMtsJLx4jhV+SMPCn90GjhGmcM0vTV+xSYWcW V1tH22QVQk6yOfG4c/Uq4ij1JTIC/09/4qSBf7X1gEPX+RPWYYoZX4lL84Ff0VelKxMp Z/1AqXpt1Yy/A+aFUYaM/6z0/SHyy3VkOPNTxB5BGDKZmAOjqhl9u/axwxrJL4K0fEFb Smq0DsWM7nHwpGJkKNBzE04pdaUuE0SidfZyWB/48f5OPdNgaOePodkkmAxL3QeBgYPs wOy1YFATwQqLysWPR4fJfE/qxCfCM8mQJbMOTO72kWKMwdLmZTQEcFzZMCymEy8qlE7B b5BA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@wuille.net header.s=protonmail header.b=OrB0mGeH; spf=pass (google.com: domain of bitcoin-dev@wuille.net designates 185.70.43.20 as permitted sender) smtp.mailfrom=bitcoin-dev@wuille.net; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=wuille.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1787177927; x=1787782727; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-transfer-encoding:content-type :mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:sender:from:to:cc:subject:date:message-id:reply-to :content-type; bh=VYdLGDfY7dVFTIU0EbeiHZpnh6XF62ux3NHr5MdWzBk=; b=UJDsuyftslXwmCspGTG1IkEUuPY1F9M8XeO/KrwM/HVmFB0K4VYKj8iQmu5VWL98zW Ny/X2dsxACLClMugUUIxdn13y41l0kWfYo78HLm+CxryyyAaHlDkl1AI9xqN5vN0YxFk Mfymq4HcEOOAhO55Z3oty4txtjbSquIrzwkRCb3jgqURhb/SO12mEGUb+tc9m31FashS JqR4D2wmvqg3K6nVAPsvyUMZJLykk7IRcDpL/TixD9Yl6450voSkBSvmORmV/xdBqkNU +L6FXg3ou+I4ch76ESn6D9wmwlngYwWG1Y6IO/G2rwFF5Z9JzVVkS4hkAU8iSxOdfcAk eTkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787177927; x=1787782727; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-transfer-encoding:content-type :mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:x-beenthere:x-gm-message-state:sender:from:to:cc :subject:date:message-id:reply-to:content-type; bh=VYdLGDfY7dVFTIU0EbeiHZpnh6XF62ux3NHr5MdWzBk=; b=PkEAyACRCaAql4Gzhyc9T91h/tTi4H9K+TkIQadZYB9sGEHZR2KSvc+uoTQoDs86Rg uRY+YPj08sFY6beJ4LRrql8ak87QdcqTZgP4j5MSOeV5YcbSsyHmLuWyZFqs1doZVR6Z F839oULFbIoh15xg/3PKufPeMAfTxLfhX0HNxfgJ9amJz55C/cuUyO5RsBLNJnsp7lVw AAqizkHl5DdT0jUm6wY8It9JfUPuPoei12WnoHCxUNxoMGcSZLBQ35UzIRi9NBf6uuf2 pq4uWl4h/XSZwGZhQUTqJ2lLCBu4GA0Z2mCX8ddv7S4r+mtvWE+KTU19uD64PxlJeUR1 9Dag== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AHgh+Rruq5euB0VOzULbVlB72f1J5/Ubtu0TTjawmJvelt8zfy2pxUieIxglsqfwII1c+pfOX8/ONznqFhGq@gnusha.org X-Gm-Message-State: AOJu0Yxq/iJlMkErIcOJXqKJyw02Ej4krsPhhFNa3etL99Z+aCP871bN j+ILtImAVkBel/DjdORGVTSnlwdG3rDewDPx6jzmQOZp3D+BnGz6aiDL X-Received: by 2002:a05:6820:1625:b0:6ae:4959:e1ba with SMTP id 006d021491bc7-6b1491b943bmr2054763eaf.10.1787177926903; Wed, 19 Aug 2026 15:18:46 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ATskLdcLMHAKB1YOtz5Z0S1IfSMmX0pT8Ni4xrSI1ackJL5DZw==" Received: by 2002:a05:6871:888d:20b0:45e:ecb5:9948 with SMTP id 586e51a60fabf-462ef80c01als563463fac.1.-pod-prod-00-us-canary; Wed, 19 Aug 2026 15:18:42 -0700 (PDT) X-Forwarded-Encrypted: i=2; AHgh+RoTuiHppI/ZiwM16hYi8UXxDOlVEAebysnB0FYyjqb8ePHtELO+aAbFogXUxhYpfBQbXrJH117ypxco@googlegroups.com X-Received: by 2002:a05:6808:c1b8:b0:495:ca1b:7865 with SMTP id 5614622812f47-4b2cdcc4f55mr2600503b6e.11.1787177922465; Wed, 19 Aug 2026 15:18:42 -0700 (PDT) Received: by 2002:a05:600c:6d8b:b0:495:6266:d77a with SMTP id 5b1f17b1804b1-499a8208617ms5e9; Wed, 19 Aug 2026 15:16:56 -0700 (PDT) X-Forwarded-Encrypted: i=2; AHgh+RpNBSeDnJ8MAxQyH985FsFuii6pgG4QIinbsoaVEDKLeWMELbIMnDreV4XP2YTQZzI1bJnAEhFT1neS@googlegroups.com X-Received: by 2002:a05:600c:4ec9:b0:495:4d5c:903e with SMTP id 5b1f17b1804b1-499aa167256mr138047275e9.7.1787177814609; Wed, 19 Aug 2026 15:16:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1787177814; cv=none; d=google.com; s=arc-20260327; b=M/rCEfY444aaB+fyKR0PUn+ADQnEDINOWwo4Ss/vVupkoUnUEF4ZvyA1OjHzs/Ev/p O2/x3S3lvhR2aQKBFvfO7nTH4QesR0cRfm70VGw4ZmOjjcpq4coNkCdhxcRAYnGtejdO Zxrg//exYx2QFVWbgQ5FYopAX29OBeTn3E8VSGEp0B8XIbgQCxus8Ot9nZG1E8YlZca/ 3gluEmfPeEgPf3HNwouHxCfomoPX0N+LE41BcYfptG5kvXGB41BBWlVYxvCZGW/OlMxa rmsqHV8Bwsj4W/7hG4MVjpuFVEGbVQNPVfA8JelaNevq2japcWv3vElkC1DQgIWVmg6J kqZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=content-transfer-encoding:mime-version:feedback-id:references :in-reply-to:message-id:subject:cc:from:to:date:dkim-signature; bh=AIfJA3IGtZOsJCES9Vwb3HULiwggQZFYn1S6xRG+oV4=; fh=mSljahHorGHNGPgiSjq/TDne+rVeDDAZHRLKW83nuLw=; b=UXm91sOfgVPL3EHMM6yD2BBmqjP4bZmVaBzR7nqOUDCrTgX3yfVv9nfLP1qI7xI6xv p/8uROB+PHhZYyCfcLBTqrx1gqrmPoHjK7049HBR46absgNR5CRwy2AkEzl0bxSgCjb5 g8ARKujH8KeuDl6Ur7iWX+xB8AnYJeyVaaWcqJrlTKsYqzm549k+diPtYQzNzJWvb7Ao gLSzn3K+Vnts/QXAKFQstXqgByklvRQ+yX+0NbPWuU05fgwVYLWlsMZjpVfIkOK9KIzh CM154sL9Zju8fVwC09RPpbJ7RjPbTwfZodak8qQx8g1eIpHDkwARTlM+Qt0HFxGgtbdq PDlA==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@wuille.net header.s=protonmail header.b=OrB0mGeH; spf=pass (google.com: domain of bitcoin-dev@wuille.net designates 185.70.43.20 as permitted sender) smtp.mailfrom=bitcoin-dev@wuille.net; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=wuille.net Received: from mail-4320.protonmail.ch (mail-4320.protonmail.ch. [185.70.43.20]) by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-499b2129fa5si19535e9.1.2026.08.19.15.16.54 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 Aug 2026 15:16:54 -0700 (PDT) Received-SPF: pass (google.com: domain of bitcoin-dev@wuille.net designates 185.70.43.20 as permitted sender) client-ip=185.70.43.20; Date: Wed, 19 Aug 2026 22:16:51 +0000 To: conduition From: Pieter Wuille 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: 19463299:user:proton X-Pm-Message-ID: 6f7790a1493ffe6edc840991bfef487616250508 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Original-Sender: bitcoin-dev@wuille.net X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@wuille.net header.s=protonmail header.b=OrB0mGeH; spf=pass (google.com: domain of bitcoin-dev@wuille.net designates 185.70.43.20 as permitted sender) smtp.mailfrom=bitcoin-dev@wuille.net; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=wuille.net 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.3 (++) Hi,=C2=A0 On Tuesday, August 18th, 2026 at 10:32 PM, conduition wrote: > Oh I misunderstood. So to be clear, a "canary" is just a social signal th= at should push consensus to activate a soft fork, whereas a "tripwire" is a= n unattended system that automatically triggers a change to consensus rules= . I like that terminology. > > 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 c= ommunity consensus-changing effort, effected through Miner Lockdown or othe= rwise). The Tripwire just sets an unambiguous expectation that disabling is= intended by Q-day. >=20 > In the absence of evidence, I expect this fork to be highly contentious o= r delayed until hard evidence is available. I don't disagree, but I also do expect hard evidence to become available, u= nless we're actually taking about scenario where a CRQC appears out of nowh= ere, and in that case there are really no good outcomes. > I agree but for a different reason on top. Given the polynomial efficienc= y of Shor, and the massive time/money investment needed to build quantum co= mputers, we have no reason to expect anyone will build a QC that can break = 192-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-= qubit quantum-computer, why not spend the extra time and money to build a 1= 200 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 make some money (e.g. by decrypting old internet traffic on behal= f of the NSA). You seem to be talking about an adversarial CRQC here? Those won't trigger = any tripwire, nor publish any canaries. There is a pretty weird philosophical point here: as far as I'm aware, at t= his point, there isn't really any application for CRQC-capable hardware exc= ept breaking classical cryptography. So beyond scientific curiosity, the on= ly incentive to build one is either adversarial, or to prove it's possible = to build one before one lands in adversarial hands. And the better migrated= the world is (including Bitcoin...) for PQC, the lower the incentives for = both get. > I think 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 time to stop using secp256k1, whereas 192-bit curves leave a shred of = doubt. Agreed. > 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 for the th= e elliptic curve group operation. I'm pretty sure the field size would affe= ct runtime complexity (gate count), but not qubit count requirements. (Happ= y to be corrected). If I'm correct, a group order of approx 2^187 would nee= d approx 842 qubits (at least) to break. My friendly neighborhood LLM believes the qubit count is primarily a functi= on of the field size (to represent curve coordinates), while the gate count= grows with larger with the group (because point multiplication needs more = additions), but I am by no means an expert. > Still, as previously discussed, I'm unsure if a canary which is only slig= htly=C2=A0harder to break would be meaningful. It'd be nice if we could fin= d some problem which quantum computers of, say, 150 qubits could do, but wh= ich classical computers cannot (feasibly) solve. Then we might have a reaso= nably predictive canary which could be solved by cooperative. Agreed. > > From a simplicity standpoint, I think just having a "a UTXO with script= PubKey X is spent" is ideal, because it reuses all existing block and trans= action validation logic, and just adds a trivial trigger. >=20 > I would like to make a case that we should expend the extra effort and no= t bind the canary to a specific UTXO. I will point to Antoine's game theory= arguments about reorgs and miner collusion with CRQCs.=C2=A0 >=20 > If we tie the canary to a specific UTXO, or even to any UTXO with a speci= fic 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= ). I hadn't considered that. But if miners are actively blocking a security fe= ature (as this effectively is), I think we're in UASF territory already. > If, on the other hand, we had nodes check something almost as simple, lik= e for example "check 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 transactions at relatively little cost. Any miners who want to censor= the canary proof will have to also censor any such transactions, and so th= ey lose out on the potential fee revenue of the entire TX by doing so. I think this is pretty unrealistic. Most user software won't have the abili= ty to include a tripwire in an OP_RETURN (this includes all kinds of higher= -level / layer-two constructions that need cooperation to build transaction= s). It further also relies on this happening at a time when fee income is s= ubstantial. > I'm not sure if this incentive is meaningful when compared to the potenti= al bribes that a miner could be offered by a CRQC, but still it is worth co= nsidering. It does have the down side that it will slow down block validati= on slightly (one EC mult per 32-byte OP_RETURN). Maybe this could be accoun= ted for somehow in the sigops budget? Yeah, these concerns are why I like just triggering on a scriptPubKey, beca= use all cost accounting is dealt with already. That said, I don't think thi= s is a particularly strong point; if there are good reasons to do the trigg= er through an OP_RETURN, there are probably fairly easy ways of doing that = too. On Wednesday, August 19th, 2026 at 11:36 AM, waxwing/ AdamISZ wrote: > Smaller group *canaries* (not tripwires) are still interesting I think. N= ot amazing, but maybe quite valuable. Agreed. I think formalized or not, this will effectively be how the ecosyst= em decides it's time to disable ECC. > Good point about signature, I wasn't considering that, earlier. If you pu= blish (R, s) with truly random R=3DkG choice you are not leaking more than = what already existed with the pubkey H; that's true if HVZK holds and assum= ing the ROM (except it has to be "QROM" now, right). Right. > However! There might be a non-technical reason to avoid H directly: it's = a bit like toxic waste in powers-of-tau and similar: suppose a whitehat org= anization is targeting a tripwire. If that dlog knowledge is exposed (in th= e 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 onl= y relevant of course if there is a CRQC which costs 2 months and $100m to r= un, if it's easy to find a specific dlog whenever, then nothing to talk abo= ut. >=20 > So yeah I would go with the abundance of caution, myself; don't see how i= t hurts. Yeah. I think the important choice is whether to cater to adversarially-construct= ed proofs or not. I believe we should not, but: If yes: use AJ's construction of providing BIP-340 signature on point of th= e form rG+H with arbitrary r, and arbitrary message. This is incompatible w= ith using UTXO trigger, and needs H (or derivation from H). If no: no reason to specifically use H, or even support multiple targets. J= ust pick an "as random as possible" fixed point, are require spending a scr= iptPubKey with it, or publishing its DLP, or publishing a signature for it. Cheers, --=20 Pieter --=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/= Bx0LA0afwRjPIcEol98t7ztodzX7mIBeA1kGLV-rAicu4IuGBkME3A-UzBC5KJOawIciVn1CW3b= CILlyVpMJU_MAgqV5OBjSFQiZrX60fb4%3D%40wuille.net.