From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 15 Aug 2026 09:54:20 -0700 Received: from mail-ot1-f57.google.com ([209.85.210.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 1wvHeD-0007m9-VH for bitcoindev@gnusha.org; Sat, 15 Aug 2026 09:54:20 -0700 Received: by mail-ot1-f57.google.com with SMTP id 46e09a7af769-7ee1e335245sf1880248a34.1 for ; Sat, 15 Aug 2026 09:54:17 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1786812852; cv=pass; d=google.com; s=arc-20260327; b=IDBk0KL7k4OjI7RrvF7nUg7pmdw0Z99NYkix03h2iYFsr6bwy+m3Yws3GgRUGB9Abn lCXb+nhkTgNuQod8oIdUwxMLQvh/zkamF0EJGgw/GTkrGLyKhjzfPq3X8dJ8fA4fiFQ6 atlTlfvRHU3OeU1oWVzBsrmF3sXFnUYpV2+MR89uR9axqxeQAyaWOgoyGIJBSAjEX5xi Y9HDM4UAlYECIeAkIh+OX/MVoIetRNQejZoZbYEWbf+qYmBStGZZ0U8goyUpMwdPgaLR BcewzhP/WdVQynkX9LGI19yzo+OOdVYizOZpfowMmq5LT5d1k10H2p0oBLkcp20oWDar gGtQ== 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=VGHZe7yz8VSpaYHf0INw8uu0oTv3OgCUlNlBn9ReiYE=; fh=tzwLN0NhKaNc4Q/zUW1grrgYBLH90hDe4RXnXcZZGw4=; b=JW1Z6pcziEqD3AJC3TsV6bphBtfTIOe9m/oY4RHs7+zVmp/JVLggbtZ4GC+npg/iJY rabKSrE+QdIRzgCNhNGBffQgmyzayFBIJPhG/AMGlNKLofDKTr6GgCjUup2qm49klRip bMaQk5t2jlTWb53U4hm2mbzyD/AWS4kdMfliQfXLmu+37jtCssjsUUI1RF/EVMlwnl8n ddB+4Vn7JclPjFEUCmytgAsfVPMeysdG708c1EHkW4PyFZKVO8YuldlmHaZ2jHhcmPyo YwibfDbLtLgPcIds2VIDPFV1xVYjSeGiRVkgn7P+vk1S0NGpwYHDwVDhdTjsTz+8/XWP 8JdA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=3yi7q7dcajd4rn5uy37hzdvswu.protonmail header.b=gTID88R2; spf=pass (google.com: domain of conduition@proton.me designates 109.224.244.24 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=1786812852; x=1787417652; 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=VGHZe7yz8VSpaYHf0INw8uu0oTv3OgCUlNlBn9ReiYE=; b=BTdWaYC6DVZ7PhYnQ4PaYynVOL+lzjaFPa7oWPGmL/Op6kfxB+y4kF38CH4Lbscszs 6VoR3ImO1OKCXy/AiQaBSzc0qaXj2sAh6KVFbcwFr4pguLu48KOsHkZAk8SA8pBio/cH 0TDctmkjVa0hqEz4rvYonzsUD4IbZqJ0RFs/bo/3yolGwPddZq84LpUCJfZs0oP1X8VH O76R/S1jEe69sHQ4uqyFJb4LwfSCvWfpZZabf2LbTUz5F2C/M+FRPjs+y6jo+K7lgpD4 H7QvGIFBVxtDIw2DKSJj9q43QVUZ76DCdUYh8QZVRQ59ARGhIyKvkkogetDnPdOjcmRz tkSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786812852; x=1787417652; 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=VGHZe7yz8VSpaYHf0INw8uu0oTv3OgCUlNlBn9ReiYE=; b=Kpbyj06LKjpbIOa7GiCfiw4YoMfwYb4UvPlnZLUCpB/lCHeYVMKZFmmUuk90rFBWQD WF/Ybtte3P+CGR2Af3wkq8ix47XxWjLjiOVgSIQcP+y9p42/wMHHuH+b8YKjARyRU6LT P25lYwMVPsYC5U9HIwva2aEhYIxBOJ8K8dg9OB0a3Y86p+7XokzGHlkWjaP/Knwb9Bdt awHLFFC9qZ6bo6l04HErwsJ3IVnodY+XWaDJOb2pKwriPxll5b2KM1qWRUaud47WlzYs u6mH1xYdntzNLf4b6nWaW7d+IYD3hEYGTK2BeHteCxuwyg4FJz54nAbQqgExJ7eEP49X 1OMw== X-Forwarded-Encrypted: i=2; AHgh+Rrkc7joXc8UGxppa/A0IFk2Q7m6JNLBdMykG7rNGMnU1xZcTB2tHRTpzUlzyON0Jkz+MY/xxNBzE9IV@gnusha.org X-Gm-Message-State: AOJu0YwUK8tlPbCAidc/YYhOaHlijpQxbGpRnJVecQ4WgeL959MA+bbi zv4PgToWGUl0UGMltP4AE4cUf8r+Vv7/lTPEznJ1JxXboiJ9LRhSsoNi X-Received: by 2002:a05:6820:c3c3:20b0:6b0:dd66:3f2b with SMTP id 006d021491bc7-6b0dd664423mr6732826eaf.19.1786812851325; Sat, 15 Aug 2026 09:54:11 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ATskLdd+SJX+fDv9Mmy9DLUqB/f32pHyET+Z0s9m7b5uQj6ghQ==" Received: by 2002:a05:6871:7403:b0:45e:435c:5ea with SMTP id 586e51a60fabf-45e5c043ed0ls2014828fac.1.-pod-prod-06-us; Sat, 15 Aug 2026 09:54:05 -0700 (PDT) X-Received: by 2002:a05:6809:184:10b0:4a4:c608:5088 with SMTP id 5614622812f47-4b241bbf3d0mr8477059b6e.13.1786812845426; Sat, 15 Aug 2026 09:54:05 -0700 (PDT) Received: by 2002:a05:6808:1dcc:b0:495:e116:a399 with SMTP id 5614622812f47-4b197189d26msb6e; Sat, 15 Aug 2026 09:52:20 -0700 (PDT) X-Received: by 2002:a05:6a00:c94:b0:845:dde9:ab62 with SMTP id d2e1a72fcca58-84fde2e8fb0mr13619323b3a.19.1786812738989; Sat, 15 Aug 2026 09:52:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1786812738; cv=none; d=google.com; s=arc-20260327; b=QGsj5+T3b7dJZz65VL7ZVQ2RhxLW2JQEvcqeXj98LZtemxCdTc6LlwkLEEOWQ/Kop9 MPhJ0FPiASpHDlTR0d5qsppF4+d7vYrkX4sXoEOwsHXcPSnYaorQEuelcKFFJeuqsLri ZHfHnVPXTUCfvQ3BmL9fARPzrARi3SHsAsQkKZlNM8wpY0nZjl43gc5el086nZv5AYtO J0Q2ft3eJuIQmyripxqtP9knGasbJ1Fhr8qG2m0Fn4D1XMjFePKkPFiir/8usmo9i5Gg Rfnya5/CDK9pXQKyh9n550hsZdHylPANi6TrBi5ZKalitd9NFebferWjp6GJnvaFUdZi LSjw== 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=r8qczEg8V1mLIauGkahByb2dZ4e3nl89+JNEX22/dOU=; fh=zwD6MnSx31+wTUYXvjlRY9wKEAVfUFCZok1hjFoWcUg=; b=N5jzyMdU4Vgb3SY8qE4JWBouyWtcoL6OkIRVeC/zyAx+4fHsbmH+Tu7UAh/kVBSCrk jHMDKswyV3+Tz9171p5abNTroT2PDSRfL/vQg2Jne2IxDHs4+gi4e1XSev/m41OIgyP9 +MEXzY4KZJ0uFOktB5H/whDgPu6KsUtQ5FzIsbksSUquhswQddvhILvTEil8zh3K4XRW 5ctoJgsSpsZVj2UIGko7mB+55G41QmRcu18oaeeDKZF5WZ/p8Fx0LGkZVvnPrKGYrZ2d /qCWoVnj84YoAQFD7dgrtPSlkzHDsXv+24AaAMvEoijTFKhYiWfg3J4E6TklcibL0p1f YQKg==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=3yi7q7dcajd4rn5uy37hzdvswu.protonmail header.b=gTID88R2; spf=pass (google.com: domain of conduition@proton.me designates 109.224.244.24 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me Received: from mail-24424.protonmail.ch (mail-24424.protonmail.ch. [109.224.244.24]) by gmr-mx.google.com with ESMTPS id 41be03b00d2f7-cc095a2e3f7si139535a12.6.2026.08.15.09.52.18 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 15 Aug 2026 09:52:18 -0700 (PDT) Received-SPF: pass (google.com: domain of conduition@proton.me designates 109.224.244.24 as permitted sender) client-ip=109.224.244.24; Date: Sat, 15 Aug 2026 16:52:10 +0000 To: waxwing/ AdamISZ From: "'conduition' via Bitcoin Development Mailing List" Cc: Bitcoin Development Mailing List Subject: Re: [bitcoindev] Giving teeth to expected EC disabling: P2XX(-T)(-ML) Message-ID: In-Reply-To: References: <002f2395-7d5d-4cb6-852c-e991aa1f0eb3@app.fastmail.com> Feedback-ID: 72003692:user:proton X-Pm-Message-ID: 1e9f6b93aa5b229eaba77c74d23c300d229dea76 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------8ba59bb4e9fb112f07aae8e17671626382eb35a33d96f3b29e40519a04c00889"; 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=3yi7q7dcajd4rn5uy37hzdvswu.protonmail header.b=gTID88R2; spf=pass (google.com: domain of conduition@proton.me designates 109.224.244.24 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) --------8ba59bb4e9fb112f07aae8e17671626382eb35a33d96f3b29e40519a04c00889 Content-Type: multipart/mixed;boundary=---------------------fe33818c330c4d07c0a2b1d04a0c0112 -----------------------fe33818c330c4d07c0a2b1d04a0c0112 Content-Type: multipart/alternative;boundary=---------------------c80a2821565cf2119d292d6615b55da9 -----------------------c80a2821565cf2119d292d6615b55da9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" > This is relevant because the hypothetical evil curve-generator who is try= ing to poison the future H=3DSHA2(G) has an easier time in doing so, than a= future canary-solver who obviously cannot try different values of G :) Ah sorry, I thought you were talking about canary solvers, didn't realize y= ou were talking about curve designers. Agreed then, but still seems unlikel= y that G was chosen this way:=C2=A0https://bitcoin.stackexchange.com/questi= ons/58784/how-were-the-secp256k1-base-point-coordinates-decided If we have any doubt about that, we could tweak the hash function with some= data that is newer than G but still unbiased, e.g. the hash of the genesis= block, or the hash of the first block in which the canary goes live (idea = credit: Tadge Dryja). > interesting point is that Shor can target any specific dlog problem, righ= t. So I do think the ST is the correct version of the problem? Yes, I believe so. I don't know of any way to batch Shor's algorithm in a m= ulti-target attack that is any more efficient than a trivial one-by-one att= ack, so using MT-ECDLP seems like it only serves to makes classical attacks= (or Grover's search) easier. regards, conduition On Saturday, August 15th, 2026 at 10:14 AM, waxwing/ AdamISZ wrote: > > A 192-bit curve i think should be reasonable as a canary, but consider = this: If someone already has a QC that breaks 192-bit ECC, how long until t= hey build one which breaks 256-bit ECC? A day, a week, a year? No way of kn= owing. If the delay is too long, users may see the canary as a false-positi= ve, and migrate back to vulnerable addresses, and they might even be right.= 192-bit canaries are vulnerable to classical attack with work approximatel= y 2^96. We should bear in mind the possibility that such a canary could be = activated possibly very early, well before Q-day, possibly even in the abse= nce of any quantum computers. >=20 > Agreed that is unlikely a big delta, in the nature of these things (QCs),= between 192 and 256. Including that it's obvious that going very much belo= w 192 means classical attack and therefore bad idea. Which is why I said 19= 2 and not sub 160. What's not obvious is that 192 is worse than 256 here. I= t may only give us a small amount of extra time, but it won't give us negat= ive extra time. So the tradeoff is, presumably, whether the additional comp= lexity (which is a bit tricky from what I recall [1], but there will defini= tely be experts out there who can clean it up) is worth it. > The idea of 'people will think it a false positive', disagree, I think th= e whole tripwire idea is likely a *bit* vulnerable to genpop misunderstandi= ng as I said in my previous post, but this particular thing I don't see it:= a 192 bit being broken is *very* likely to cause an appropriate level of p= anic. >=20 > > Anyone can find G =3D a * B. Just generate a key and invert your secret= key. >=20 > > P =3D a * G > > G =3D a**-1 * P >=20 > > The hard part is then finding some b such that b*G =3D SHA256(G). >=20 > You slightly missed my point here, I think? The idea is that if you set u= p two sides that are both sample-able, you can birthday. Like, you keep sam= pling a on one side and b on the other. Build tables of both sides. Then al= l you have to do is check whether SHA2 of the LHS ever matches the RHS. Thi= s gives you a square root style speedup a la birthday attack. Contrast with= if you just fix G, then keep searching for matches: no square root speedup= . This is relevant because the hypothetical evil curve-generator who is try= ing to poison the future H=3DSHA2(G) has an easier time in doing so, than a= future canary-solver who obviously cannot try different values of G :) >=20 > About your single-target vs multi-target distinction: interesting point i= s that Shor can target any specific dlog problem, right. So I do think the = ST is the correct version of the problem? But actually I am quite unsure an= d unclear about those ST, MT, LMT distinctions you're making; specifically = I mean, I am very unsure about how they differ in costs. >=20 > As for characterizing the problem, I think it's fair to say: if you assum= ed SHA2 was a proper random oracle then we have with SHA2(enc(G)), somethin= g that's very tightly equivalent to ECDLP, which is what we want. If we wan= t to pay attention to the fact that SHA2 is an actual hash function and not= an RO, then I think there's some statement like "assuming SHA2 has no stru= cture "matching" secp256k1, then it's tightly equivalent to ECDLP on secp25= 6k1" which is obviously horrendously vague, but would not be very easy to w= rite down properly. >=20 > Another observation, probably it already exists up-thread: we obviously d= on't want to *literally* use BIP341's H on a 256 bit tripwire, because then= a Shor-break directly steals a bunch of coins, so what should we use? Mayb= e SHA2(SHA2(enc(G)) ? >=20 >=20 > [1] https://delvingbitcoin.org/t/qcap-a-bitcoin-native-quantum-canary-ale= rt/2498/9 > On Friday, August 14, 2026 at 12:34:54=E2=80=AFPM UTC-6 conduition wrote: >=20 > > > An obvious question to raise: would we consider tripwiring a 192 bit = group break of a similar type (NUMS)? I find that ... plausible? > >=20 > >=20 > > A 192-bit curve i think should be reasonable as a canary, but consider = this: If someone already has a QC that breaks 192-bit ECC, how long until t= hey build one which breaks 256-bit ECC? A day, a week, a year? No way of kn= owing. If the delay is too long, users may see the canary as a false-positi= ve, and migrate back to vulnerable addresses, and they might even be right.= 192-bit canaries are vulnerable to classical attack with work approximatel= y 2^96. We should bear in mind the possibility that such a canary could be = activated possibly very early, well before Q-day, possibly even in the abse= nce of any quantum computers. > >=20 > > Ideally we want a short gap between "192-bit is broken" and "256-bit is= broken", but not so short as to make the 192-bit canary effectively fungib= le with a 256-bit canary (because then it's less likely to be activated bef= ore theft occurs). > >=20 > >=20 > > > w.r.t. 'This guarantees that the NUMS point cannot predate G' yes bas= ed on SHA2 preimage resistance, but: isn't the real point that we're relyin= g on SHA-2 not being a naughty function so that you couldn't find G =3D a *= B and SHA2(G) =3D b*B for some base B in some feasible computation (sans C= QRC of course, as was likely back then!). I have no idea what precise name = you give to that property. OK, this is a ridiculous thing to discuss, perha= ps, given when SHA2 and secp256k1 were standardized :) And given the encodi= ng choices for our BIP341 NUMS (iirc the same as for Elements back in the d= ay? using uncompressed encoding?) were able to be counted on the fingers of= the hand which the sleeve does not cover :) > >=20 > >=20 > > Anyone can find `G =3D a * B`. Just generate a key and invert your secr= et key. > >=20 > > `P =3D a * G` > > G =3D a**-1 * P > >=20 > > The hard part is then finding some b such that `b*G =3D SHA256(G).` > >=20 > > --------- > >=20 > > If we reflect on the requirement that `G` is fixed, we see `SHA256(G)` = is also fixed as a pseudorandom challenge point. The reason for using SHA25= 6 instead of, say, picking an arbitary point by committee or using digits o= f pi or some other trickery, is that hash outputs are supposed to be random= and so `SHA256(G)` is (assumably) a random ECDLP challenge. This matches t= he classical definition of ECDLP more tightly: Given an arbitrary point `P`= , find `p` such that `P =3D p * G`. The assumption is that if an attacker c= an factor an honestly-sampled challenge point, they can factor any point. S= HA256 is just a stand-in for the "honestly-sampled" part. > > However, the following two tasks are actually very different: > >=20 > >=20 > > 1. Given G, find scalar `a` such that `a*G =3D lift_x(SHA256(G))`. > > 2. Given G, find scalar `a` and message `m` such that `a*G =3D lift_x(= SHA256(m))`. > >=20 > >=20 > > In the case of task 1, if we assume SHA256 output is random, then this = is more tightly equivalent to ECDLP, because the point we're trying to fact= or is a fixed target, as is the one sampled honestly by the ECDLP security = game. > >=20 > > In the case of task 2, the attacker can sample arbitrary messages to cr= eate multiple target points, and the attacker wins if they succeed in facto= ring any of them. The attacker can attack all those target points concurren= tly if they want, and they get a speedup from doing so. > >=20 > > So I believe it is worth disambiguating canaries between the two cases,= because they are different security notions. The first (1) I would call si= ngle-target ECDLP (ST-ECDLP), and the second (2) I would call multi-target = ECDLP (MT-ECDLP). > >=20 > > It's pretty clear that MT-ECDLP is easier to break, because attackers c= an make progress against more than one target concurrently, and breaking an= y one is sufficient to win the security game. > >=20 > > For example, say I sample 2 different messages `m1` and `m2`, and compu= te ECDLP target points `T1 =3D lift_x(SHA256(m1))` and `T2 =3D lift_x(SHA25= 6(m2))`. Then if I sample a random scalar `r` and compute `R =3D r*G`, I ha= ve two potential chances of success: `R =3D=3D T1` OR `R =3D=3D T2`. I can = scale up this advantage by generating more targets, `T3`, `T4`, ... and so = on. > >=20 > > MT-ECDLP also admits a more efficient basic unit of computation in brut= e force attacks (including Grover) by using hashes instead of EC point mult= iplications. If I instead start by picking scalar `t` and fix the target po= int `T =3D t*G`, then I can run a brute-force preimage search on SHA256 unt= il I find `m` such that `SHA256(m) =3D=3D x(T)`. This can also be scaled up= using a multi-target attack [1]. > >=20 > > With ST-ECDLP, we have only a single fixed message `m =3D G`, and so th= e attacker can't use those multi-target cheat codes. They can parallelize, = use pollard-rho or Shor or other algorithms, but they have only a single ta= rget point that they must break to win the game. > >=20 > > The method Pieter suggested using for the canary construction is equiva= lent to single-target ECDLP. > >=20 > > I've heard others (e.g. Tadge in this thread) previously suggest using = a script like `OP_SHA256 OP_CHECKSIG` as a canary, where any spend of such = a script would trigger the canary. This would be multi-target ECDLP. > >=20 > > I'm not sure which is better. > >=20 > >=20 > > - ST-ECDLP is less likely to be triggered early or mistakenly, and is= more tightly equivalent to ECDLP. > > =20 > >=20 > > - MT-ECDLP is more reflective of how real-world attackers behave on B= itcoin (e.g. with thousands-to-millions of public keys available to attack = in parallel, and breaking even one is considered unacceptable). > >=20 > >=20 > >=20 > > I'm slightly leanings towards a construction like Pieter's, featuring S= T-ECDLP, just because I'm not sure what other tricks could be used to poten= tially trigger MT-ECDLP classically or quantumly. > >=20 > > We could also engineer a compromise between the two, where we limit the= number of targets. For example, define the game like this: > >=20 > >=20 > > Given `G`, find scalar `a` and 32-bit integer `i` such that `a*G =3D li= ft_x(SHA256(G || i))`. > >=20 > >=20 > > Then the adversary can only attack against at most 2^32 unique target p= oints, and those targets are fixed forever, for any adversary. This is an e= asier problem than ST-ECDLP, but harder than MT-ECDLP. Maybe call it limite= d multi-target ECDLP (LMT-ECDLP)? > >=20 > >=20 > > regards, > > conduition > >=20 > >=20 > > [1]: First, generate a bunch of target points. Sample scalar `t` and co= mpute `T0 =3D t * G`, T1 =3D T0 + T0, and T2 =3D T1 + T1, and T3 =3D T2 + T= 2, etc. Why double each point? point doubling is cheaper than addition or m= ultiplication, and still covers the whole curve. Then we run a multi-target= SHA256 preimage search over all targets [x(T0), x(T1), x(T2), x(T3), ...].= If we have n targets and curve order N, then each message hash has an `n/N= ` chance of success. If we find a valid message `m`, such that `SHA256(m) = =3D=3D x(R_i)` for some target index `i`, then we have found `T_i =3D t * 2= **i * G =3D lift_x(SHA256(m))`. > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > On Thursday, August 13th, 2026 at 2:02 AM, waxwing/ AdamISZ wrote: > >=20 > > > This tripwire idea is interesting. Basically "canary in consensus". > > > I agree it's valuable. In the scenario of adversarial actor(s) gainin= g access to CQRC first, i.e. no whitehats, only blackhats, obviously nothin= g to discuss; touching a NUMS ECDL is the last thing they'll do. So I'm sli= ghtly worried that the general userbase will not notice that point, instead= thinking it's a solid defense when it ... depends. > > >=20 > > > In the scenario of at least some whitehats, we get wires tripped, or = canaries singing. Having it in consensus is nice. The blockchain then does = its job of being an unambiguous signal and we can have all the arguments we= ll ahead of time. [1] > > >=20 > > > On the other hand, we traditionally design such systems adversarially= , right, so you could argue that an overfocus on this might be suboptimal -= it might be better to do other things. > > >=20 > > > (Similar comment applies to the 'smaller group canary' - definitely n= othing wrong with it, but it is not in itself a defence unless we strongly = believe whitehats, and *active* whitehats at that, are keeping up). An obvi= ous question to raise: would we consider tripwiring a 192 bit group break o= f a similar type (NUMS)? I find that ... plausible? > > > > The BIP341 NUMS point (which I suggest using in this context) is th= e point whose X coordinate is the SHA256 hash of the generator point G. Thi= s guarantees that the NUMS point cannot predate G (if it did, it would be p= ossible in theory that secp256k1's designers actually chose G in function o= f what we call that NUMS point, giving it a DLP known to them). > > >=20 > > > w.r.t. 'This guarantees that the NUMS point cannot predate G' yes bas= ed on SHA2 preimage resistance, but: isn't the real point that we're relyin= g on SHA-2 not being a naughty function so that you couldn't find G =3D a *= B and SHA2(G) =3D b*B for some base B in some feasible computation (sans C= QRC of course, as was likely back then!). I have no idea what precise name = you give to that property. OK, this is a ridiculous thing to discuss, perha= ps, given when SHA2 and secp256k1 were standardized :) And given the encodi= ng choices for our BIP341 NUMS (iirc the same as for Elements back in the d= ay? using uncompressed encoding?) were able to be counted on the fingers of= the hand which the sleeve does not cover :) > > >=20 > > > [1] I take Antoine's point that making it consensus means the miners = are involved and there is a non-trivial collusion risk if the stakes are hi= gh, but I can't see how this scenario is *worse* than no tripwire? > > >=20 > > > On Sunday, July 5, 2026 at 4:07:33=E2=80=AFPM UTC-6 Antoine Riard wro= te: > > >=20 > > > > Hi Pieter, > > > >=20 > > > > Thanks for the observations. > > > >=20 > > > > When I was saying there is a problem with the game theory, > > > > it's that strikingly, any activation of the tripwire logic > > > > would rely on a "flag" transaction being mined in the chain > > > > for the network nodes starting to enforce at the block N or > > > > N+1 or whatever the EC disabling threshold. > > > >=20 > > > > Any "flag" transaction can be itself re-orged out of the chain > > > > to purely disable the effects of the EC disabling threshold, > > > > therefore make it null and void as an effect. One might see > > > > it as a competing race between a group of "sunsetting" users > > > > and a (majority) coalition of miners in coordination with a > > > > CRQC adversary, where the latter have an interest and the > > > > hashrate capabilities to do a tx-withold [0]. > > > >=20 > > > > In pure terms of satoshi fee denominated calculus, empirically > > > > global miners have won an average of $20 B yearly. If we only > > > > consider that P2PK are going to be frozen by the tripwire effect, > > > > as for most of them it might be assumed they will never move to > > > > a safer format, we talk already about 1.7 M of coins or as of > > > > today valuation $107 B (the information is on the chain and can > > > > be verified). > > > >=20 > > > > That's $107B can "burn" in revenue or income that a CRQC-enabled > > > > miners coalition to constantly reorg-out the "flag" tx out of the > > > > chain. In other terms, something like 5 years of income, and I > > > > kindly do not count all the loss coins that are likely to amount > > > > to a far bigger "tripwire" neutralization budget. > > > >=20 > > > > In the name of what a majority of miners will gracefully let on > > > > the table an opportunity of massive income ? > > > >=20 > > > > Leveraging Shor the exploitation might be even done anonymously > > > > as the mining process is done. Not even certainty, by who the > > > > EC-protected coins could be covertly exfiltrated. > > > >=20 > > > > That's the most striking problem when you think about the math > > > > with any "tripwire" approach, or even an "hourglass" one relying > > > > on a "flag" transaction [1]. I'm ruling out "checkpoints" and > > > > any other trust-the-dev approach, as that's even worst [2]. > > > >=20 > > > > As you're introducing post is resounding, what the miners > > > > are saying now, there are no guarantees on how they would use > > > > their hashrate down the road, potentially 10 or 20 years from now. > > > >=20 > > > > Beyond, and to answer back your point, I still think you can > > > > manage an escape hatch of the "tripwire" effect, it's all depends > > > > how the script tripwire logic is implemented, but if you have > > > > two OP_SUCCESS of different kinds before your EC CHECKSIG, you > > > > can always have a "soft-fork" after the "tripwire" to return > > > > true on the stack, with an EC or hashlock as a success (I agree > > > > using undefined op_success in a script is not safe at all) [3]. > > > >=20 > > > > Best, > > > > Antoine > > > > OTS hash: 4bc91d8dee1625f6e78b27c88bced8e405f25ef6d3d8fd59be8016db5= b0fbe66 > > > >=20 > > > > [0] See naumenkog's https://www.bitmex.com/blog/txwithhold-smart-co= ntracts > > > > [1] This is sad, as the "hourglass" depending how the parameters ar= e chosen > > > > was a more acceptable trade-off than pure sunsetting. > > > > [2] Given the amounts at stake to sunset, as a group of developers = you > > > > would just paint yourself a target, there are more even funds at st= ake > > > > that Satoshi herself / himself is assumed to have. > > > > [3] There is no security proof in BIP341 on the unforgeability of t= he > > > > NUMS point, if it binds in the ROM or whatever. > > > >=20 > > > >=20 > > > > Le sam. 4 juil. 2026 =C3=A0 13:47, Sjors Provoost a =C3=A9crit : > > > >=20 > > > > >=20 > > > > >=20 > > > > > On Fri, Jul 3, 2026, at 23:23, Pieter Wuille wrote: > > > > >=20 > > > > > [...] > > > > >=20 > > > > > > * Just publishing the DLP in a transaction (e.g. OP_RETURN with= a > > > > > > specific marker). This is smaller than a full transaction input= + > > > > > > signature. > > > > > > > > > > > > * Similarly, but publishing in the coinbase, and requiring rela= y using > > > > > > a separate message. Less places a node needs to check, but I'm > > > > > > concerned about the difficulty of testing infrastructure that r= elay of > > > > > > such a message works > > > > >=20 > > > > > [...] > > > > >=20 > > > > > > > > > > > > On Saturday, June 27th, 2026 at 12:33 AM, Anthony Towns > > > > > > wrote: > > > > > > > > > > > >> A slight variant of this approach would be to have a 128 byte = value "aRsm", such that P =3D N+a*G, N is the BIP-341 NUMS point, and Rs is= a BIP340 signature of m by P. That would allow the victim of post-quantum = theft via a key-path spend of a BIP341 NUMS IPK to trigger the tripwire, in= addition to someone who has direct access to a CRQC. > > > > > > > > > > > > Indeed, I had considered something similar, but see above for w= hy I'm > > > > > > not convinced supporting non-cooperative CRQCs is that useful. > > > > > > > > > > > > Also, in my view the tripwire isn't really a security feature o= n itself > > > > > > (it's not expected to trigger...), but more something that sets > > > > > > expectations around the output type for prospective users. > > > > > > > > > > > > In that sense, the question is really whether supporting > > > > > > non-cooperative CRQCs helps set that expectation more than only > > > > > > cooperative ones, which are definitely easier to support. > > > > > > > > > > > >> I think it could make sense to have the tripwire be included i= n the block via the coinbase witness commitment output, rather than having = it be locked to a transaction, so you only having to check the coinbase for= the magic rather than every transaction. That would require a separate P2P= message to relay the necessary ECDL-break proof to miners, and would proba= bly need stratumv2 or a getblocktemplate update in order for the node to be= able to tell pools to actually include that info in the coinbase. > > > > > > > > > > > > I worry this is untestable, really. You'd need things like > > > > > > fake-tripwires to be supported through the same message which d= on't > > > > > > require an ECDLP break, and still propagate. And then that need= s DoS > > > > > > protection measures, > > > > >=20 > > > > > I whipped something up last weekend: > > > > > https://github.com/Sjors/bitcoin/pull/121 > > > > >=20 > > > > > It seems straightforward, but maybe I missed something: > > > > > - for test code we use a fake NUMS point, so we can generate "pro= of" without a quantum computer > > > > > - a p2p message floods the proof > > > > > - nodes ignore the message if they already have *any* valid proof > > > > > - verifying p2p proof candidates might need some rate limiting, b= ut it's as cheap as verifying a transaction signature > > > > > - mining code includes the proof in a coinbase op_return, until t= he freeze activates > > > > > - with stratum v2 (and ipc mining clients in general this works o= ut of the box, a small change is needed for getblocktemplate clients) > > > > > - since the proof is not in the header, we can't use the normal b= ip9 style header scan to see if the rule activated. Instead the prototype s= tores it in a file along with a merkle inclusion proof, which is read when = the node restarts. > > > > >=20 > > > > > With this mechanism it doesn't really need to be in the coinbase = transaction, but that does seem more convenient and miners can censor it an= yway. > > > > >=20 > > > > > - Sjors > > > >=20 > > > > > -- > > > > > You received this message because you are subscribed to a topic i= n the Google Groups "Bitcoin Development Mailing List" group. > > > > > To unsubscribe from this topic, visit https://groups.google.com/d= /topic/bitcoindev/aWYtPLVPZ3U/unsubscribe. > > > > > To unsubscribe from this group and all its topics, send an email = to bitcoindev+...@googlegroups.com. > > > > > To view this discussion visit https://groups.google.com/d/msgid/b= itcoindev/002f2395-7d5d-4cb6-852c-e991aa1f0eb3%40app.fastmail.com. > > >=20 > > > -- > >=20 > > > You received this message because you are subscribed to the Google Gr= oups "Bitcoin Development Mailing List" group. > > > To unsubscribe from this group and stop receiving emails from it, sen= d an email to bitcoindev+...@googlegroups.com. > > > To view this discussion visit https://groups.google.com/d/msgid/bitco= indev/f6d78499-d551-45ea-89b1-2b9cbd52f5can%40googlegroups.com. >=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= email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit https://groups.google.com/d/msgid/bitcoinde= v/fd947d7c-86fd-407c-98aa-0a63b8be28fan%40googlegroups.com. --=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/= irB0rm4rUG6GyaLnf1vUsNFW8BBJXAuh8-FIJ_s75xjgFgbOuTdaEGQ30PYzjtawVv5UVIC5xs7= Uq_Cm9BPSyC73A-xGwT5J2oYsKE8QiPE%3D%40proton.me. -----------------------c80a2821565cf2119d292d6615b55da9 Content-Type: multipart/related;boundary=---------------------3f17c28dc3fd80ec3c95e9a5cd959e03 -----------------------3f17c28dc3fd80ec3c95e9a5cd959e03 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This is relevant because the hypothetical evil curve-generator who is tr= ying to poison the future H=3DSHA2(G) has an easier time in doing so, than = a future canary-solver who obviously cannot try different values of G :)

Ah sorry, I thought you were talki= ng about canary solvers, didn't realize you were talking about curve design= ers. Agreed then, but still seems unlikely that G was chosen this way: = ;https://bitcoin.stack= exchange.com/questions/58784/how-were-the-secp256k1-base-point-coordinates-= decided

If we have any doubt ab= out that, we could tweak the hash function with some data that is newer tha= n G but still unbiased, e.g. the hash of the genesis block, or the hash of = the first block in which the canary goes live (idea credit: Tadge Dryja).

in= teresting point is that Shor can target any specific dlog problem, right. S= o I do think the ST is the correct version of the problem?

Yes, I believe so= . I don't know of any way to batch Shor's algorithm in a multi-target attac= k that is any more efficient than a trivial one-by-one attack, so using MT-= ECDLP seems like it only serves to makes classical attacks (or Grover's sea= rch) easier.

conduition

On Saturday, August 15th, 2026 at 10:14 AM, waxwing/ AdamISZ <ek= aggata@gmail.com> wrote:
> A 192-bit = curve i think should be reasonable as a canary, but consider this: If someo= ne already has a QC that breaks 192-bit ECC, how long until they build one = which breaks 256-bit ECC? A day, a week, a year? No way of knowing. If the = delay is too long, users may see the canary as a false-positive, and migrat= e back to vulnerable addresses, and they might even be right. 192-bit canaries are vulnerable t= o classical attack with work approximately 2^96. We should bear in mind the= possibility that such a canary could be activated possibly very early, wel= l before Q-day, possibly even in the absence of any quantum computers.

Agreed that is unlikely a big delta, in the nature of t= hese things (QCs), between 192 and 256. Including that it's obvious that go= ing very much below 192 means classical attack and therefore bad idea. Whic= h is why I said 192 and not sub 160. What's not obvious is that 192 is wors= e than 256 here. It may only give us a small amount of extra time, but it w= on't give us negative extra time. So the tradeoff is, presumably, whether t= he additional complexity (which is a bit tricky from what I recall [1], but= there will definitely be experts out there who can clean it up) is worth i= t.

The idea of 'people will think it a false posit= ive', disagree, I think the whole tripwire idea is likely a *bit* vulnerabl= e to genpop misunderstanding as I said in my previous post, but this partic= ular thing I don't see it: a 192 bit being broken is *very* likely to cause= an appropriate level of panic.

> Anyone can find G =3D a * B=E2=80=8B. Just generate a key and invert your secret key.
=

> P =3D a * G=E2=80=8B
> G =3D a**-1 * P

> The hard part is then finding some b such that b*G =3D SHA= 256(G).

You slightly missed my point here= , I think? The idea is that if you set up two sides that are both sample-ab= le, you can birthday. Like, you keep sampling a on one side and b on the ot= her. Build tables of both sides. Then all you have to do is check whether S= HA2 of the LHS ever matches the RHS. This gives you a square root style spe= edup a la birthday attack. Contrast with if you just fix G, then keep searc= hing for matches: no square root speedup. This is relevant because the hypo= thetical evil curve-generator who is trying to poison the future H=3DSHA2(G= ) has an easier time in doing so, than a future canary-solver who obviously= cannot try different values of G :)

About your single-target vs multi-target disti= nction: interesting point is that Shor can target any specific dlog problem= , right. So I do think the ST is the correct version of the problem? But ac= tually I am quite unsure and unclear about those ST, MT, LMT distinctions y= ou're making; specifically I mean, I am very unsure about how they differ i= n costs.

As for characterizing the problem, I thin= k it's fair to say: if you assumed SHA2 was a proper random oracle then we = have with SHA2(enc(G)), something that's very tightly equivalent to ECDLP, = which is what we want. If we want to pay attention to the fact that SHA2 is= an actual hash function and not an RO, then I think there's some statement= like "assuming SHA2 has no structure "matching" secp256k1, then it's tight= ly equivalent to ECDLP on secp256k1" which is obviously horrendously vague,= but would not be very easy to write down properly.

Another observation, probably it already exists up-thread: we obviously d= on't want to *literally* use BIP341's H on a 256 bit tripwire, because then= a Shor-break directly steals a bunch of coins, so what should we use? Mayb= e SHA2(SHA2(enc(G)) ?


On Friday, August 14, 2026 at 12:34:54=E2=80=AFP= M UTC-6 conduition wrote:
An obvious qu= estion to raise: would we consider tripwiring a 192 bit group break of a si= milar type (NUMS)? I find that ... plausible?

A 192-bit curve i think should be reaso= nable as a canary, but consider this: If someone already has a QC that brea= ks 192-bit ECC, how long until they build one which breaks 256-bit ECC? A d= ay, a week, a year? No way of knowing. If the delay is too long, users may = see the canary as a false-positive, and migrate back to vulnerable addresse= s, and they might even be right. 192-bit canaries are vulnerable to classic= al attack with work approximately 2^96. We should bear in mind the possibil= ity that such a canary could be activated possibly very early, well before = Q-day, possibly even in the absence of any quantum computers.
<= div style=3D"font-family:Arial,sans-serif;font-size:14px">
Ideally we want a short= gap between "192-bit is broken" and "256-bit is broken", but not so short = as to make the 192-bit canary effectively fungible with a 256-bit canary (b= ecause then it's less likely to be activated before theft occurs).

w.r.t. 'This guarantees that the NU= MS point cannot predate G' yes based on SHA2 preimage resistance, but: isn'= t the real point that we're relying on SHA-2 not being a naughty function s= o that you couldn't find G =3D a * B and SHA2(G) =3D b*B for some base B in= some feasible computation (sans CQRC of course, as was likely back then!).= I have no idea what precise name you give to that property. OK, this is a = ridiculous thing to discuss, perhaps, given when SHA2 and secp256k1 were st= andardized :) And given the encoding choices for our BIP341 NUMS (iirc the = same as for Elements back in the day? using uncompressed encoding?) were ab= le to be counted on the fingers of the hand which the sleeve does not cover= :)

Anyone can find G =3D a * B=E2=80=8B. Just generate= a key and invert your secret key.

P =3D a * G=E2=80=8B
G =3D a**-1 * P

The hard part is then finding some = b such that b*G =3D SHA256(G).

---------

If we reflect on the requirement that G=E2=80=8B is fixed, we see SHA256(G)=E2=80=8B is also fixed= as a pseudorandom challenge point. The reason for using SHA256 instead of,= say, picking an arbitary point by committee or using digits of pi or some = other trickery, is that hash outputs are supposed to be random and so SHA256(G)=E2=80=8B is (assumably) a random ECDLP challenge. This ma= tches the classical definition of ECDLP more tightly: Given an arbitrary po= int P=E2=80=8B, find p=E2=80=8B such that P= =3D p * G=E2=80=8B. The assumption is that if an attacker can facto= r an honestly-sampled challenge point, they can factor any point. SHA256 is= just a stand-in for the "honestly-sampled" part.
However,= the following two tasks are actually very different:

  1. Given G, find scalar a=E2=80=8B such that <= code>a*G =3D lift_x(SHA256(G))=E2=80=8B.
  2. Given G, find scalar a=E2=80=8B and mes= sage m=E2=80=8B such that a*G =3D lift_x(SHA256(m))=E2=80=8B.

In the case of task 1, if w= e assume SHA256 output is random, then this is more tightly equivalent to E= CDLP, because the point we're trying to factor is a fixed target, as is the= one sampled honestly by the ECDLP security game.

= In the case of task 2, the attacker can sample arbitrary messages to create= multiple target points, and the attacker wins if they succeed in fa= ctoring any of them. The attacker can attack all those target points concur= rently if they want, and they get a speedup from doing so.

So I believe it is worth disambiguating canaries between the two c= ases, because they are different security notions. The first (1) I would ca= ll single-target ECDLP (ST-ECDLP), and the second (2) I would call <= i>multi-target ECDLP (MT-ECDLP).

It's pretty c= lear that MT-ECDLP is easier to break, because attackers can make progress = against more than one target concurrently, and breaking any one is sufficie= nt to win the security game.

For example, say I sa= mple 2 different messages m1=E2=80=8B and m2=E2= =80=8B, and compute ECDLP target points T1 =3D lift_x(SHA256(m1))=E2=80=8B and T2 =3D lift_x(SHA256(m2))=E2=80=8B. Then if I= sample a random scalar r=E2=80=8B and compute R =3D r*G= =E2=80=8B, I have two potential chances of success: R =3D=3D T= 1=E2=80=8B OR R =3D=3D T2=E2=80=8B. I can scale up this= advantage by generating more targets, T3=E2=80=8B, T4=E2=80=8B, ... and so on.

MT-ECDLP also admit= s a more efficient basic unit of computation in brute force attacks (includ= ing Grover) by using hashes instead of EC point multiplications. If I inste= ad start by picking scalar t=E2=80=8B and fix the target point= T =3D t*G=E2=80=8B, then I can run a brute-force preimage sea= rch on SHA256 until I find m=E2=80=8B such that SHA256(m= ) =3D=3D x(T)=E2=80=8B. This can also be scaled up using a multi-tar= get attack [1].

With ST-ECDLP, we have only a sing= le fixed message m =3D G=E2=80=8B, and so the attacker can't u= se those multi-target cheat codes. They can parallelize, use pollard-rho or= Shor or other algorithms, but they have only a single target point that th= ey must break to win the game.

The method Pieter s= uggested using for the canary construction is equivalent to single-targe= t ECDLP.

I've heard others (e.g. Tadge in this thread) previously suggest using a script like OP_= SHA256 OP_CHECKSIG=E2=80=8B as a canary, where any spend of such a s= cript would trigger the canary. This would be multi-target ECDLP.

I'm not sure which is better.

<= div>
  • ST-ECDLP is less likely to be triggered early or= mistakenly, and is more tightly equivalent to ECDLP.
=
  • MT-ECDLP is more reflective of how real-w= orld attackers behave on Bitcoin (e.g. with thousands-to-millions of public= keys available to attack in parallel, and breaking even one is considered = unacceptable).

= I'm slightly leanings towards a construction like Pieter's, featuring ST-EC= DLP, just because I'm not sure what other tricks could be used to potential= ly trigger MT-ECDLP classically or quantumly.

We could also engineer a compromise between the two, where we limit the n= umber of targets. For example, define the game like this:
<= div>
Given G=E2=80=8B, find scalar = a=E2=80=8B=E2=80=8B and 32-bit integer i=E2=80=8B= =E2=80=8B such that a*G =3D lift_x(SHA256(G || i))=E2=80=8B=E2= =80=8B.

Then the adversary ca= n only attack against at most 2^32 unique target points, and those targets = are fixed forever, for any adversary. This is an easier problem than ST-ECD= LP, but harder than MT-ECDLP. Maybe call it limited multi-target ECDLP (= LMT-ECDLP)?


regard= s,
conduition


[1]: First, generate a bunch of target points. Sample scalar t=E2=80=8B and compute T0 =3D t * G=E2=80=8B, T1 =3D T0= + T0, and T2 =3D T1 + T1, and T3 =3D T2 + T2=E2=80=8B, etc. Why double eac= h point? point doubling is cheaper than addition or multiplication, and sti= ll covers the whole curve. Then we run a multi-target SHA256 preimage searc= h over all targets [x(T0), x(T1), x(T2), x(T3), ...]=E2=80=8B. If we have n= =E2=80=8B targets and curve order N=E2=80=8B, then each message hash has an= n/N=E2=80=8B=E2=80=8B chance of success. If we find a valid m= essage m=E2=80=8B, such that SHA256(m) =3D=3D x(R_i)=E2=80=8B for some target index i=E2=80=8B, then we have fo= und T_i =3D t * 2**i * G =3D lift_x(SHA256(m))=E2=80=8B.




On Thursday, August 13th, 2026 at 2:02 AM, waxwing/ AdamISZ <ekag...@gmail.com> wrote:
This tripwire idea is interesting. Basically "canary in consens= us".

I agree it's valuable. In the scenario of adversari= al actor(s) gaining access to CQRC first, i.e. no whitehats, only blackhats= , obviously nothing to discuss; touching a NUMS ECDL is the last thing they= 'll do. So I'm slightly worried that the general userbase will not notice t= hat point, instead thinking it's a solid defense when it ... depends.
=

In the scenario of at least some whitehats, we get wire= s tripped, or canaries singing. Having it in consensus is nice. The blockch= ain then does its job of being an unambiguous signal and we can have all th= e arguments well ahead of time. [1]

On the other h= and, we traditionally design such systems adversarially, right, so you coul= d argue that an overfocus on this might be suboptimal - it might be better = to do other things.

(Similar comment applies to th= e 'smaller group canary' - definitely nothing wrong with it, but it is not = in itself a defence unless we strongly believe whitehats, and *active* whit= ehats at that, are keeping up). An obvious question to raise: would we cons= ider tripwiring a 192 bit group break of a similar type (NUMS)? I find that= ... plausible?

> The BIP341 NUMS point (which I sugge= st using in this context) is the point whose X coordinate is the SHA256 has= h of the generator point G. This guarantees that the NUMS point cannot pred= ate G (if it did, it would be possible in theory that secp256k1's designers= actually chose G in function of what we call that NUMS point, giving it a = DLP known to them).

w.r.t. 'This guarantees that t= he NUMS point cannot predate G' yes based on SHA2 preimage resistance, but:= isn't the real point that we're relying on SHA-2 not being a naughty funct= ion so that you couldn't find G =3D a * B and SHA2(G) =3D b*B for some base= B in some feasible computation (sans CQRC of course, as was likely back th= en!). I have no idea what precise name you give to that property. OK, this = is a ridiculous thing to discuss, perhaps, given when SHA2 and secp256k1 we= re standardized :) And given the encoding choices for our BIP341 NUMS (iirc= the same as for Elements back in the day? using uncompressed encoding?) we= re able to be counted on the fingers of the hand which the sleeve does not = cover :)

[1] I take Antoine's point that making it= consensus means the miners are involved and there is a non-trivial collusi= on risk if the stakes are high, but I can't see how this scenario is *worse= * than no tripwire?

On Sunday, July 5, 2026 at 4:07:33=E2=80=AFP= M UTC-6 Antoine Riard wrote:
Hi Pieter,

Thanks for the observations.
<= br>When I was saying there is a problem with the game theory,
it's that = strikingly, any activation of the tripwire logic
would rely on a "flag" = transaction being mined in the chain
for the network nodes starting to e= nforce at the block N or
N+1 or whatever the EC disabling threshold.
=
Any "flag" transaction can be itself re-orged out of the chain
to pu= rely disable the effects of the EC disabling threshold,
therefore make i= t null and void as an effect. One might see
it as a competing race betwe= en a group of "sunsetting" users
and a (majority) coalition of miners in= coordination with a
CRQC adversary, where the latter have an interest a= nd the
hashrate capabilities to do a tx-withold [0].

In pure term= s of satoshi fee denominated calculus, empirically
global miners have wo= n an average of $20 B yearly. If we only
consider that P2PK are going to= be frozen by the tripwire effect,
as for most of them it might be assum= ed they will never move to
a safer format, we talk already about 1.7 M o= f coins or as of
today valuation $107 B (the information is on the chain= and can
be verified).

That's $107B can "burn" in revenue or inco= me that a CRQC-enabled
miners coalition to constantly reorg-out the "fla= g" tx out of the
chain. In other terms, something like 5 years of income= , and I
kindly do not count all the loss coins that are likely to amount=
to a far bigger "tripwire" neutralization budget.

In the name of= what a majority of miners will gracefully let on
the table an opportuni= ty of massive income ?

Leveraging Shor the exploitation might be eve= n done anonymously
as the mining process is done. Not even certainty, by= who the
EC-protected coins could be covertly exfiltrated.

That's= the most striking problem when you think about the math
with any "tripw= ire" approach, or even an "hourglass" one relying
on a "flag" transactio= n [1]. I'm ruling out "checkpoints" and
any other trust-the-dev approach= , as that's even worst [2].

As you're introducing post is resounding= , what the miners
are saying now, there are no guarantees on how they wo= uld use
their hashrate down the road, potentially 10 or 20 years from no= w.

Beyond, and to answer back your point, I still think you can
m= anage an escape hatch of the "tripwire" effect, it's all depends
how the= script tripwire logic is implemented, but if you have
two OP_SUCCESS of= different kinds before your EC CHECKSIG, you
can always have a "soft-fo= rk" after the "tripwire" to return
true on the stack, with an EC or has= hlock as a success (I agree
using undefined op_success in a script is no= t safe at all) [3].

Best,
Antoine
OTS hash: 4bc91d8dee1625f6e= 78b27c88bced8e405f25ef6d3d8fd59be8016db5b0fbe66

[0] See naumenkog's = https://www.b= itmex.com/blog/txwithhold-smart-contracts
[1] This is sad, as the "h= ourglass" depending how the parameters are chosen
was a more acceptable = trade-off than pure sunsetting.
[2] Given the amounts at stake to sunset= , as a group of developers you
would just paint yourself a target, there= are more even funds at stake
that Satoshi herself / himself is assumed = to have.
[3] There is no security proof in BIP341 on the unforgeability = of the
NUMS point, if it binds in the ROM or whatever.

Le sam. 4 juil. 2026 =C3=A0 13:47, Sjors Provoost <sj...@sprovoost.nl> a =C3=A9crit = :


On Fri, Jul 3, 2026, at 23:23, Pieter Wuille wrote:

[...]

> * Just publishing the DLP in a transaction (e.g. OP_RETURN with a
> specific marker). This is smaller than a full transaction input +
> signature.
>
> * Similarly, but publishing in the coinbase, and requiring relay using=
> a separate message. Less places a node needs to check, but I'm
> concerned about the difficulty of testing infrastructure that relay of=
> such a message works

[...]

>
> On Saturday, June 27th, 2026 at 12:33 AM, Anthony Towns
> <a...@erisian.com.au>= ; wrote:
>
>> A slight variant of this approach would be to have a 128 byte valu= e "aRsm", such that P =3D N+a*G, N is the BIP-341 NUMS point, and Rs is a B= IP340 signature of m by P. That would allow the victim of post-quantum thef= t via a key-path spend of a BIP341 NUMS IPK to trigger the tripwire, in add= ition to someone who has direct access to a CRQC.
>
> Indeed, I had considered something similar, but see above for why I'm =
> not convinced supporting non-cooperative CRQCs is that useful.
>
> Also, in my view the tripwire isn't really a security feature on itsel= f
> (it's not expected to trigger...), but more something that sets
> expectations around the output type for prospective users.
>
> In that sense, the question is really whether supporting
> non-cooperative CRQCs helps set that expectation more than only
> cooperative ones, which are definitely easier to support.
>
>> I think it could make sense to have the tripwire be included in th= e block via the coinbase witness commitment output, rather than having it b= e locked to a transaction, so you only having to check the coinbase for the= magic rather than every transaction. That would require a separate P2P mes= sage to relay the necessary ECDL-break proof to miners, and would probably = need stratumv2 or a getblocktemplate update in order for the node to be abl= e to tell pools to actually include that info in the coinbase.
>
> I worry this is untestable, really. You'd need things like
> fake-tripwires to be supported through the same message which don't > require an ECDLP break, and still propagate. And then that needs DoS <= br> > protection measures,

I whipped something up last weekend:
https://github.com/Sjors/bitcoin/pull/1= 21

It seems straightforward, but maybe I missed something:
- for test code we use a fake NUMS point, so we can generate "proof" withou= t a quantum computer
- a p2p message floods the proof
- nodes ignore the message if they already have *any* valid proof
- verifying p2p proof candidates might need some rate limiting, but it's as= cheap as verifying a transaction signature
- mining code includes the proof in a coinbase op_return, until the freeze = activates
- with stratum v2 (and ipc mining clients in general this works out of th= e box, a small change is needed for getblocktemplate clients)
- since the proof is not in the header, we can't use the normal bip9 style = header scan to see if the rule activated. Instead the prototype stores it i= n a file along with a merkle inclusion proof, which is read when the node r= estarts.

With this mechanism it doesn't really need to be in the coinbase transactio= n, but that does seem more convenient and miners can censor it anyway.

- Sjors

--
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.
To unsubscribe from this group and all its topics, send an email to bitcoinde= v+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitco= indev/002f2395-7d5d-4cb6-852c-e991aa1f0eb3%40app.fastmail.com.

--
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+..= .@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bit= coindev/f6d78499-d551-45ea-89b1-2b9cbd52f5can%40googlegroups.com.

--
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+u= nsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/fd947d7c-86fd-407c-98a= a-0a63b8be28fan%40googlegroups.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/bitcoindev/irB0rm= 4rUG6GyaLnf1vUsNFW8BBJXAuh8-FIJ_s75xjgFgbOuTdaEGQ30PYzjtawVv5UVIC5xs7Uq_Cm9= BPSyC73A-xGwT5J2oYsKE8QiPE%3D%40proton.me.
-----------------------3f17c28dc3fd80ec3c95e9a5cd959e03-- -----------------------c80a2821565cf2119d292d6615b55da9-- -----------------------fe33818c330c4d07c0a2b1d04a0c0112 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== -----------------------fe33818c330c4d07c0a2b1d04a0c0112-- --------8ba59bb4e9fb112f07aae8e17671626382eb35a33d96f3b29e40519a04c00889 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wrsEARYKAG0FgmqAmSsJEHgpbO2E9rPFRRQAAAAAABwAIHNhbHRAbm90YXRp b25zLm9wZW5wZ3Bqcy5vcmf4rQcOFqduASaMQAvMVwe6H50G/NaqxKRx5wWR RSQlWhYhBEdIka0CMtrLdg13a3gpbO2E9rPFAADkMQEA8o1x+egVHNIVsRP8 Ejt89Gb/F6dMzpEpvKt58FN2AHQA/2hWBDQSXhqfC008bZ3z2yp5mbaMGH2D k+kN5R567dgJ =YxWe -----END PGP SIGNATURE----- --------8ba59bb4e9fb112f07aae8e17671626382eb35a33d96f3b29e40519a04c00889--