From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 15 Aug 2026 11:12:53 -0700 Received: from mail-oa1-f60.google.com ([209.85.160.60]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wvIsE-0000Xc-Na for bitcoindev@gnusha.org; Sat, 15 Aug 2026 11:12:53 -0700 Received: by mail-oa1-f60.google.com with SMTP id 586e51a60fabf-451d80641efsf2085873fac.2 for ; Sat, 15 Aug 2026 11:12:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1786817564; x=1787422364; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :mime-version:subject:references:in-reply-to:message-id:to:from:date :sender:from:to:cc:subject:date:message-id:reply-to:content-type; bh=uRV3xHcgwJuGFo+1sHLH/dOEmeduKXYDA1Y5Z8YblAo=; b=j/jlBafnejXMYP6PQyzP2MeiST4UPo6on6TAscsu74oOGtKXuERRIjNTc4k2J8q0V5 ErBRO/0YlGpnoBSznEm5FL/+6yks+9CZMZCe9gWpwUiTwo2bW4iV36j1npycRova/r1P 1FV/Z0j0AxrFFQO8/17nLpd4Yf6wPfONjr4LY2ODIE6Ec0rl9LDiShrDliRtMMJ8pD61 Kl21yX04f8LSZ/4JnLH4j6l6ICYQ//e0/ihy6vYkCwHTglSNBXAyk/mb5lQ3EyLuAp2w 4MgZdUSf/oSaBZMmVeUKloNSXu+/elqH9l9SvcrOxXyQs+icpbS3JdB6JK9P7m7hcOq/ Ca3A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786817564; x=1787422364; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :mime-version:subject:references:in-reply-to:message-id:to:from:date :from:to:cc:subject:date:message-id:reply-to:content-type; bh=uRV3xHcgwJuGFo+1sHLH/dOEmeduKXYDA1Y5Z8YblAo=; b=O4fPqrkdd/yh7dwKOJ0rwaxrbOuIIZ18dazy/GNe5tyPENKpKRDOVZh19kaqm7Vpai gumv8D5kP/3341kmGy8fAfOfMfNYr6wg4lNayi4EcDov/Mj++K5a19/m6xXQOlQPnk2D 936WKiAp7oSVMJOcb67Sc6VxY5wMItpq8N6iIopr/HG+TAcAsnrjXjhJj3esUFMdlZ9w yPvs8NF6KSIwyaiIpu5ksJmyobarnR2Kyq0SACQrjhPSPGQSkX3g+Oxm+dCBc/ymIhY8 KP5DVsdupmvYQ9hxS/vUMkX5rj+UM7323qX2AabJoPUWsnkAr9rRIqMI9S0UgVlnvRc5 ZTkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786817564; x=1787422364; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :mime-version:subject:references:in-reply-to:message-id:to:from:date :x-beenthere:x-gm-message-state:sender:from:to:cc:subject:date :message-id:reply-to:content-type; bh=uRV3xHcgwJuGFo+1sHLH/dOEmeduKXYDA1Y5Z8YblAo=; b=XhWo5m4mzhJ64FgNt/hyXJcXHMUKdNsqxSb+vseYgozSnKqU9hZpX8pWcRdaabzqm4 VtUKJe4wS7yxNQh8AxiBAQdfhX99XYq8fkKykVb1UldpZAmd15jJWehurf2ECcE1RirB vtJnSIeKlJOZlgMax+UtMeLFJuMEwZnSobesNK6WfZeltiq/VcfVnNZ4dqb5Fy49VQUT mPAgvimH6Vv5gGUvmgymkyIMk6oR3n6omDii7uUEusAkL+ta6p4fhTF6cbRIO2B7yexp 8gRCsiCTb7cpkS56P0ZRaCCEukeixkdA/CMKxphXw7eG3vEnK76ZetORRXUHTefCiOyf Q7mQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AHgh+Rpm8v3Tn+SxBaLcTQQCls/312pj8j4M/jX4EuyOU/2nLtzttpHqgBMGtOUfZUbcRvDz/nOi2dmYdfX4@gnusha.org X-Gm-Message-State: AOJu0YzRin6kMrkPgDhhyjnMEx+RECymkfo7di99rIMUTHYespHHmAih Ro3v3VUYjrMm/vWxPaI8nErlI9TfeqHwhkk1ZD9C1NHFaJ4/C20aQ+8u X-Received: by 2002:a05:6871:14a:b0:451:25f2:da63 with SMTP id 586e51a60fabf-45e91ef3f5bmr12118926fac.6.1786817564265; Sat, 15 Aug 2026 11:12:44 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ATskLdfeajbxmtCVhq07lWzWfvdfj1US5Wvsq8gxLk5enluITg==" Received: by 2002:a05:6870:d206:b0:45e:46c6:be91 with SMTP id 586e51a60fabf-45e5baffc41ls3072615fac.2.-pod-prod-08-us; Sat, 15 Aug 2026 11:12:38 -0700 (PDT) X-Received: by 2002:a05:6808:2e45:b0:4af:57e9:4ec6 with SMTP id 5614622812f47-4b241e0eb49mr12751095b6e.15.1786817558658; Sat, 15 Aug 2026 11:12:38 -0700 (PDT) Received: by 2002:a05:690c:c05c:b0:81e:ee9e:9148 with SMTP id 00721157ae682-82325eb7472ms7b3; Sat, 15 Aug 2026 11:06:23 -0700 (PDT) X-Received: by 2002:a05:690c:e5d1:b0:80e:5236:b944 with SMTP id 00721157ae682-8370d40fbfemr42277527b3.10.1786817182917; Sat, 15 Aug 2026 11:06:22 -0700 (PDT) Date: Sat, 15 Aug 2026 11:06:22 -0700 (PDT) From: waxwing/ AdamISZ To: Bitcoin Development Mailing List Message-Id: In-Reply-To: References: <002f2395-7d5d-4cb6-852c-e991aa1f0eb3@app.fastmail.com> Subject: Re: [bitcoindev] Giving teeth to expected EC disabling: P2XX(-T)(-ML) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_158258_1491725832.1786817182577" X-Original-Sender: ekaggata@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: 2.6 (++) ------=_Part_158258_1491725832.1786817182577 Content-Type: multipart/alternative; boundary="----=_Part_158259_1263434358.1786817182577" ------=_Part_158259_1263434358.1786817182577 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable As if everything wasn't confusing enough, I also made one very notable=20 error: What I was saying here: > This is relevant because the hypothetical evil curve-generator who is=20 trying to poison the future H=3DSHA2(G) has an easier time in doing so, tha= n=20 a future canary-solver who obviously cannot try different values of G :) is, I'm pretty sure, not correct: the canary-solver only needs 2^128 work= =20 anyway (all the normal classical collision finding); it's not like he has= =20 to use pure brute force. > If we have any doubt about that, we could tweak the hash function with=20 some data that is newer than G but still unbiased, e.g. the hash of the=20 genesis block, or the hash of the first block in which the canary goes live= =20 (idea credit: Tadge Dryja=20 ). Seems plausible. I guess two tracks of conversation here; I'm still genuinely curious what= =20 people think about 192 bit and whether we can do it practically, because,= =20 depending on how it plays out, it might buy very useful time. The delving= =20 thread was focused on distributed keygen and ZKP for the canary, but this= =20 is obviously way less trustless than NUMS, so perhaps that's the end of=20 that, or perhaps there's something else clever I'm not aware of. On Saturday, August 15, 2026 at 10:54:11=E2=80=AFAM UTC-6 conduition wrote: > This is relevant because the hypothetical evil curve-generator who is=20 > trying to poison the future H=3DSHA2(G) has an easier time in doing so, t= han=20 > 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= =20 > you were talking about curve designers. Agreed then, but still seems=20 > unlikely that G was chosen this way:=20 > https://bitcoin.stackexchange.com/questions/58784/how-were-the-secp256k1-= base-point-coordinates-decided > > If we have any doubt about that, we could tweak the hash function with=20 > some data that is newer than G but still unbiased, e.g. the hash of the= =20 > genesis block, or the hash of the first block in which the canary goes li= ve=20 > (idea credit: Tadge Dryja=20 > ). > > interesting point is that Shor can target any specific dlog problem,=20 > right. 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= =20 > multi-target attack that is any more efficient than a trivial one-by-one= =20 > attack, so using MT-ECDLP seems like it only serves to makes classical=20 > attacks (or Grover's search) easier. > > regards, > conduition > > On Saturday, August 15th, 2026 at 10:14 AM, waxwing/ AdamISZ < > ekag...@gmail.com> wrote: > > > A 192-bit curve i think should be reasonable as a canary, but consider= =20 > this: If someone already has a QC that breaks 192-bit ECC, how long until= =20 > they build one which breaks 256-bit ECC? A day, a week, a year? No way of= =20 > knowing. If the delay is too long, users may see the canary as a=20 > false-positive, and migrate back to vulnerable addresses, and they might= =20 > even be right. 192-bit canaries are vulnerable to classical attack with= =20 > work approximately 2^96. We should bear in mind the possibility that such= a=20 > canary could be activated possibly very early, well before Q-day, possibl= y=20 > even in the absence of any quantum computers. > > Agreed that is unlikely a big delta, in the nature of these things (QCs),= =20 > between 192 and 256. Including that it's obvious that going very much bel= ow=20 > 192 means classical attack and therefore bad idea. Which is why I said 19= 2=20 > and not sub 160. What's not obvious is that 192 is worse than 256 here. I= t=20 > may only give us a small amount of extra time, but it won't give us=20 > negative extra time. So the tradeoff is, presumably, whether the addition= al=20 > complexity (which is a bit tricky from what I recall [1], but there will= =20 > definitely 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=20 > whole tripwire idea is likely a *bit* vulnerable to genpop misunderstandi= ng=20 > as I said in my previous post, but this particular thing I don't see it: = a=20 > 192 bit being broken is *very* likely to cause an appropriate level of=20 > panic. > > > Anyone can find G =3D a * B=E2=80=8B. Just generate a key and invert yo= ur secret=20 > 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). > > You slightly missed my point here, I think? The idea is that if you set u= p=20 > two sides that are both sample-able, you can birthday. Like, you keep=20 > sampling a on one side and b on the other. Build tables of both sides. Th= en=20 > all you have to do is check whether SHA2 of the LHS ever matches the RHS.= =20 > This gives you a square root style speedup a la birthday attack. Contrast= =20 > with if you just fix G, then keep searching for matches: no square root= =20 > speedup. This is relevant because the hypothetical evil curve-generator w= ho=20 > is trying to poison the future H=3DSHA2(G) has an easier time in doing so= ,=20 > 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=20 > that Shor can target any specific dlog problem, right. So I do think the = ST=20 > is the correct version of the problem? But actually I am quite unsure and= =20 > unclear about those ST, MT, LMT distinctions you're making; specifically = I=20 > mean, I am very unsure about how they differ in costs. > > As for characterizing the problem, I think it's fair to say: if you=20 > assumed SHA2 was a proper random oracle then we have with SHA2(enc(G)),= =20 > something that's very tightly equivalent to ECDLP, which is what we want.= =20 > If we want to pay attention to the fact that SHA2 is an actual hash=20 > function and not an RO, then I think there's some statement like "assumin= g=20 > SHA2 has no structure "matching" secp256k1, then it's tightly equivalent = to=20 > ECDLP on secp256k1" which is obviously horrendously vague, but would not = be=20 > very easy to write down properly. > > Another observation, probably it already exists up-thread: we obviously= =20 > don't want to *literally* use BIP341's H on a 256 bit tripwire, because= =20 > then a Shor-break directly steals a bunch of coins, so what should we use= ?=20 > Maybe SHA2(SHA2(enc(G)) ? > > > [1]=20 > https://delvingbitcoin.org/t/qcap-a-bitcoin-native-quantum-canary-alert/2= 498/9 > On Friday, August 14, 2026 at 12:34:54=E2=80=AFPM UTC-6 conduition wrote: > >> An obvious question to raise: would we consider tripwiring a 192 bit=20 >> group break of a similar type (NUMS)? I find that ... plausible? >> >> >> A 192-bit curve i think should be reasonable as a canary, but consider= =20 >> this: If someone already has a QC that breaks 192-bit ECC, how long unti= l=20 >> they build one which breaks 256-bit ECC? A day, a week, a year? No way o= f=20 >> knowing. If the delay is too long, users may see the canary as a=20 >> false-positive, and migrate back to vulnerable addresses, and they might= =20 >> even be right. 192-bit canaries are vulnerable to classical attack with= =20 >> work approximately 2^96. We should bear in mind the possibility that suc= h a=20 >> canary could be activated possibly very early, well before Q-day, possib= ly=20 >> even in the absence of any quantum computers. >> >> Ideally we want a short gap between "192-bit is broken" and "256-bit is= =20 >> broken", but not so short as to make the 192-bit canary effectively=20 >> fungible with a 256-bit canary (because then it's less likely to be=20 >> activated before theft occurs). >> >> w.r.t. 'This guarantees that the NUMS point cannot predate G' yes based= =20 >> on SHA2 preimage resistance, but: isn't the real point that we're relyin= g=20 >> on SHA-2 not being a naughty function so that you couldn't find G =3D a = * B=20 >> and SHA2(G) =3D b*B for some base B in some feasible computation (sans C= QRC=20 >> of course, as was likely back then!). I have no idea what precise name y= ou=20 >> give to that property. OK, this is a ridiculous thing to discuss, perhap= s,=20 >> given when SHA2 and secp256k1 were standardized :) And given the encodin= g=20 >> choices for our BIP341 NUMS (iirc the same as for Elements back in the d= ay?=20 >> using uncompressed encoding?) were able to be counted on the fingers of = the=20 >> hand which the sleeve does not cover :) >> >> >> Anyone can find G =3D a * B=E2=80=8B. Just generate a key and invert you= r secret=20 >> 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=20 >> also fixed as a pseudorandom challenge point. The reason for using SHA25= 6=20 >> instead of, say, picking an arbitary point by committee or using digits = of=20 >> pi or some other trickery, is that hash outputs are supposed to be rando= m=20 >> and so SHA256(G)=E2=80=8B is (assumably) a random ECDLP challenge. This = matches=20 >> the classical definition of ECDLP more tightly: Given an arbitrary point= =20 >> P=E2=80=8B, find p=E2=80=8B such that P =3D p * G=E2=80=8B. The assumpti= on is that if an attacker=20 >> can factor an honestly-sampled challenge point, they can factor any poin= t.=20 >> 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 a*G =3D lift_x(SHA256(G)= )=E2=80=8B. >> 2. Given G, find scalar a=E2=80=8B and message m=E2=80=8B such that a= *G =3D=20 >> lift_x(SHA256(m))=E2=80=8B. >> >> >> In the case of task 1, if we assume SHA256 output is random, then this i= s=20 >> more tightly equivalent to ECDLP, because the point we're trying to fact= or=20 >> is a fixed target, as is the one sampled honestly by the ECDLP security= =20 >> game. >> >> In the case of task 2, the attacker can sample arbitrary messages to=20 >> create multiple *target points*, and the attacker wins if they succeed= =20 >> in factoring any of them. The attacker can attack all those target point= s=20 >> concurrently if they want, and they get a speedup from doing so. >> >> So I believe it is worth disambiguating canaries between the two cases,= =20 >> because they are different security notions. The first (1) I would call = *single-target=20 >> ECDLP *(ST-ECDLP), and the second (2) I would call *multi-target ECDLP * >> (MT-ECDLP). >> >> It's pretty clear that MT-ECDLP is easier to break, because attackers ca= n=20 >> make progress against more than one target concurrently, and breaking an= y=20 >> one is sufficient to win the security game. >> >> For example, say I sample 2 different messages m1=E2=80=8B and m2=E2=80= =8B, and compute=20 >> ECDLP target points T1 =3D lift_x(SHA256(m1))=E2=80=8B and T2 =3D lift_x= (SHA256(m2))=E2=80=8B.=20 >> Then if I sample a random scalar r=E2=80=8B and compute R =3D r*G=E2=80= =8B, I have two=20 >> potential chances of success: R =3D=3D T1=E2=80=8B OR R =3D=3D T2=E2=80= =8B. I can scale up this=20 >> advantage by generating more targets, T3=E2=80=8B, T4=E2=80=8B, ... and = so on. >> >> MT-ECDLP also admits a more efficient basic unit of computation in brute= =20 >> force attacks (including Grover) by using hashes instead of EC point=20 >> multiplications. If I instead start by picking scalar t=E2=80=8B and fix= the=20 >> target point T =3D t*G=E2=80=8B, then I can run a brute-force preimage s= earch on=20 >> SHA256 until I find m=E2=80=8B such that SHA256(m) =3D=3D x(T)=E2=80=8B.= This can also be=20 >> scaled up using a multi-target attack [1]. >> >> With ST-ECDLP, we have only a single fixed message m =3D G=E2=80=8B, and= so the=20 >> attacker can't use those multi-target cheat codes. They can parallelize,= =20 >> use pollard-rho or Shor or other algorithms, but they have only a single= =20 >> target point that they must break to win the game. >> >> The method Pieter suggested using for the canary construction is=20 >> equivalent to *single-target* ECDLP. >> >> I've heard others (e.g. Tadge in this thread=20 >> )= =20 >> previously suggest using a script like OP_SHA256 OP_CHECKSIG=E2=80=8B as= a=20 >> canary, where any spend of such a script would trigger the canary. This= =20 >> would be *multi-target* ECDLP. >> >> I'm not sure which is better.=20 >> >> >> - ST-ECDLP is less likely to be triggered early or mistakenly, and is= =20 >> more tightly equivalent to ECDLP.=20 >> =20 >> >> - MT-ECDLP is more reflective of how real-world attackers behave on= =20 >> Bitcoin (e.g. with thousands-to-millions of public keys available to = attack=20 >> in parallel, and breaking even one is considered unacceptable). >> >> >> I'm slightly leanings towards a construction like Pieter's, featuring=20 >> ST-ECDLP, just because I'm not sure what other tricks could be used to= =20 >> potentially trigger MT-ECDLP classically or quantumly. >> >> We could also engineer a compromise between the two, where we limit the= =20 >> number of targets. For example, define the game like this: >> >> 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=20 >> lift_x(SHA256(G || i))=E2=80=8B=E2=80=8B. >> >> Then the adversary can only attack against at most 2^32 unique target=20 >> points, and those targets are fixed forever, for any adversary. This is = an=20 >> easier problem than ST-ECDLP, but harder than MT-ECDLP. Maybe call it *l= imited=20 >> multi-target ECDLP (LMT-ECDLP)*? >> >> >> regards, >> conduition >> >> >> [1]: First, generate a bunch of target points. Sample scalar t=E2=80=8B = and compute=20 >> 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=20 >> double each point? point doubling is cheaper than addition or=20 >> multiplication, and still covers the whole curve. Then we run a=20 >> multi-target SHA256 preimage search over all targets [x(T0), x(T1), x(T2= ),=20 >> x(T3), ...]=E2=80=8B. If we have n=E2=80=8B targets and curve order N=E2= =80=8B, then each message=20 >> hash has an n/N=E2=80=8B=E2=80=8B chance of success. If we find a valid = message m=E2=80=8B, such=20 >> that SHA256(m) =3D=3D x(R_i)=E2=80=8B for some target index i=E2=80=8B, = then we have found T_i=20 >> =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 consensus". >> >> I agree it's valuable. In the scenario of adversarial actor(s) gaining= =20 >> access to CQRC first, i.e. no whitehats, only blackhats, obviously nothi= ng=20 >> to discuss; touching a NUMS ECDL is the last thing they'll do. So I'm=20 >> slightly worried that the general userbase will not notice that point,= =20 >> instead thinking it's a solid defense when it ... depends. >> >> In the scenario of at least some whitehats, we get wires tripped, or=20 >> canaries singing. Having it in consensus is nice. The blockchain then do= es=20 >> its job of being an unambiguous signal and we can have all the arguments= =20 >> well ahead of time. [1] >> >> On the other hand, we traditionally design such systems adversarially,= =20 >> right, so you could argue that an overfocus on this might be suboptimal = -=20 >> it might be better to do other things. >> >> (Similar comment applies to the 'smaller group canary' - definitely=20 >> nothing wrong with it, but it is not in itself a defence unless we stron= gly=20 >> believe whitehats, and *active* whitehats at that, are keeping up). An= =20 >> obvious question to raise: would we consider tripwiring a 192 bit group= =20 >> break of a similar type (NUMS)? I find that ... plausible? >> >> > The BIP341 NUMS point (which I suggest using in this context) is the= =20 >> point whose X coordinate is the SHA256 hash of the generator point G. Th= is=20 >> guarantees that the NUMS point cannot predate G (if it did, it would be= =20 >> possible in theory that secp256k1's designers actually chose G in functi= on=20 >> of what we call that NUMS point, giving it a DLP known to them). >> >> w.r.t. 'This guarantees that the NUMS point cannot predate G' yes based= =20 >> on SHA2 preimage resistance, but: isn't the real point that we're relyin= g=20 >> on SHA-2 not being a naughty function so that you couldn't find G =3D a = * B=20 >> and SHA2(G) =3D b*B for some base B in some feasible computation (sans C= QRC=20 >> of course, as was likely back then!). I have no idea what precise name y= ou=20 >> give to that property. OK, this is a ridiculous thing to discuss, perhap= s,=20 >> given when SHA2 and secp256k1 were standardized :) And given the encodin= g=20 >> choices for our BIP341 NUMS (iirc the same as for Elements back in the d= ay?=20 >> using uncompressed encoding?) were able to be counted on the fingers of = the=20 >> hand which the sleeve does not cover :) >> >> [1] I take Antoine's point that making it consensus means the miners are= =20 >> involved and there is a non-trivial collusion risk if the stakes are hig= h,=20 >> but I can't see how this scenario is *worse* than no tripwire? >> >> On Sunday, July 5, 2026 at 4:07:33=E2=80=AFPM UTC-6 Antoine Riard wrote: >> >>> Hi Pieter, >>> >>> Thanks for the observations. >>> >>> 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. >>> >>> 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]. >>> >>> 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). >>> >>> 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. >>> >>> In the name of what a majority of miners will gracefully let on >>> the table an opportunity of massive income ? >>> >>> 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. >>> >>> 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]. >>> >>> 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. >>> >>> 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=20 >>> 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]. >>> >>> Best, >>> Antoine >>> OTS hash:=20 >>> 4bc91d8dee1625f6e78b27c88bced8e405f25ef6d3d8fd59be8016db5b0fbe66 >>> >>> [0] See naumenkog's=20 >>> https://www.bitmex.com/blog/txwithhold-smart-contracts >>> [1] This is sad, as the "hourglass" depending how the parameters are=20 >>> 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 = a=20 >>> =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=20 >>>> > specific marker). This is smaller than a full transaction input +=20 >>>> > signature. >>>> > >>>> > * Similarly, but publishing in the coinbase, and requiring relay=20 >>>> using=20 >>>> > a separate message. Less places a node needs to check, but I'm=20 >>>> > concerned about the difficulty of testing infrastructure that relay= =20 >>>> of=20 >>>> > such a message works >>>> >>>> [...] >>>> >>>> > >>>> > On Saturday, June 27th, 2026 at 12:33 AM, Anthony Towns=20 >>>> > wrote: >>>> > >>>> >> A slight variant of this approach would be to have a 128 byte value= =20 >>>> "aRsm", such that P =3D N+a*G, N is the BIP-341 NUMS point, and Rs is = a=20 >>>> BIP340 signature of m by P. That would allow the victim of post-quantu= m=20 >>>> theft via a key-path spend of a BIP341 NUMS IPK to trigger the tripwir= e, in=20 >>>> addition to someone who has direct access to a CRQC. >>>> > >>>> > Indeed, I had considered something similar, but see above for why I'= m=20 >>>> > not convinced supporting non-cooperative CRQCs is that useful. >>>> > >>>> > Also, in my view the tripwire isn't really a security feature on=20 >>>> itself=20 >>>> > (it's not expected to trigger...), but more something that sets=20 >>>> > expectations around the output type for prospective users. >>>> > >>>> > In that sense, the question is really whether supporting=20 >>>> > non-cooperative CRQCs helps set that expectation more than only=20 >>>> > cooperative ones, which are definitely easier to support. >>>> > >>>> >> I think it could make sense to have the tripwire be included in the= =20 >>>> block via the coinbase witness commitment output, rather than having i= t be=20 >>>> locked to a transaction, so you only having to check the coinbase for = the=20 >>>> magic rather than every transaction. That would require a separate P2P= =20 >>>> message to relay the necessary ECDL-break proof to miners, and would= =20 >>>> probably need stratumv2 or a getblocktemplate update in order for the = node=20 >>>> 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=20 >>>> > fake-tripwires to be supported through the same message which don't= =20 >>>> > require an ECDLP break, and still propagate. And then that needs DoS= =20 >>>> > protection measures,=20 >>>> >>>> I whipped something up last weekend: >>>> https://github.com/Sjors/bitcoin/pull/121 >>>> >>>> It seems straightforward, but maybe I missed something: >>>> - for test code we use a fake NUMS point, so we can generate "proof"= =20 >>>> 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, but=20 >>>> it's as cheap as verifying a transaction signature >>>> - mining code includes the proof in a coinbase op_return, until the=20 >>>> freeze activates >>>> - with stratum v2 (and ipc mining clients in general this works out of= =20 >>>> the box, a small change is needed for getblocktemplate clients) >>>> - since the proof is not in the header, we can't use the normal bip9= =20 >>>> style header scan to see if the rule activated. Instead the prototype= =20 >>>> stores it in a file along with a merkle inclusion proof, which is read= when=20 >>>> the node restarts. >>>> >>>> With this mechanism it doesn't really need to be in the coinbase=20 >>>> transaction, but that does seem more convenient and miners can censor = it=20 >>>> anyway. >>>> >>>> - Sjors >>>> >>>> --=20 >>>> You received this message because you are subscribed to a topic in the= =20 >>>> Google Groups "Bitcoin Development Mailing List" group. >>>> To unsubscribe from this topic, visit=20 >>>> https://groups.google.com/d/topic/bitcoindev/aWYtPLVPZ3U/unsubscribe. >>>> To unsubscribe from this group and all its topics, send an email to=20 >>>> bitcoindev+...@googlegroups.com. >>>> To view this discussion visit=20 >>>> https://groups.google.com/d/msgid/bitcoindev/002f2395-7d5d-4cb6-852c-e= 991aa1f0eb3%40app.fastmail.com >>>> . >>>> >>> --=20 >> >> You received this message because you are subscribed to the Google Group= s=20 >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n=20 >> email to bitcoindev+...@googlegroups.com. >> To view this discussion visit=20 >> https://groups.google.com/d/msgid/bitcoindev/f6d78499-d551-45ea-89b1-2b9= cbd52f5can%40googlegroups.com >> . >> >> >> --=20 > You received this message because you are subscribed to the Google Groups= =20 > "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an= =20 > email to bitcoindev+...@googlegroups.com. > > To view this discussion visit=20 > https://groups.google.com/d/msgid/bitcoindev/fd947d7c-86fd-407c-98aa-0a63= b8be28fan%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/= d84e4a53-f3b1-4cd1-9a86-9591ec8c7211n%40googlegroups.com. ------=_Part_158259_1263434358.1786817182577 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable As if everything wasn't confusing enough, I also made one very notable erro= r: What I was saying here:

>=C2=A0This is relevant = because the hypothetical evil curve-generator who is trying to poison the f= uture H=3DSHA2(G) has an easier time in doing so, than a future canary-solv= er who obviously cannot try different values of G :)

is, I'm pretty sure, not correct: the canary-solver only needs 2^128 work = anyway (all the normal classical collision finding); it's not like he has t= o use pure brute force.

>=C2=A0I= f 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: T= adge Dryja
Seems plausible.=

I guess two tracks of conversation here; I'm still= genuinely curious what people think about 192 bit and whether we can do it= practically, because, depending on how it plays out, it might buy very use= ful time. The delving thread was focused on distributed keygen and ZKP for = the canary, but this is obviously way less trustless than NUMS, so perhaps = that's the end of that, or perhaps there's something else clever I'm not aw= are of.

<= /span>
On Saturday, August 15, 2026 at 10:54:11=E2=80=AFAM UTC-6 conduition wro= te:
This is relevant because the hypothetical e= vil curve-generator who is trying to poison the future H=3DSHA2(G) has an e= asier time in doing so, than a future canary-solver who obviously cannot tr= y different values of G :)

Ah sorry, I thought = you were talking about canary solvers, didn't realize you were talking = about curve designers. Agreed then, but still seems unlikely that G was cho= sen this way:=C2=A0https://bitcoin.stackexchange.com/questions/58784/how= -were-the-secp256k1-base-point-coordinates-decided=

=
If we have any doubt about that, we could tweak the hash function with s= ome data that is newer than G but still unbiased, e.g. the hash of the gene= sis block, or the hash of the first block in which the canary goes live (idea credit: Tadge Dryja).

inte= resting point is that Shor can target any specific dlog problem, right. So = I do think the ST is the correct version of the problem?
<= /span>

Yes, I believe so. I don't know of any way t= o batch Shor's algorithm in a multi-target attack that is any more effi= cient than a trivial one-by-one attack, so using MT-ECDLP seems like it onl= y serves to makes classical attacks (or Grover's search) easier.=

<= div>regards,
<= span style=3D"font-size:10.5pt;line-height:normal;font-family:Arial,sans-se= rif">conduition

On Saturday, August 15th, 2026 at 10:14 AM, waxwing/ AdamISZ <ekag...@gmail.com> wrote:
> A 192-bit cur= ve 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 they build one whi= ch breaks 256-bit ECC? A day, a week, a year? No way of knowing. If the del= ay is too long, users may see the canary as a false-positive, and migrate b= ack to vulnerable addresses, and they might even be right. 192-bit canaries are vulnerable to clas= sical attack with work approximately 2^96. We should bear in mind the possi= bility that such a canary could be activated possibly very early, well befo= re Q-day, possibly even in the absence of any quantum computers.
Agreed that is unlikely a big delta, in the nature of these t= hings (QCs), between 192 and 256. Including that it's obvious that goin= g very much below 192 means classical attack and therefore bad idea. Which = is why I said 192 and not sub 160. What's not obvious is that 192 is wo= rse than 256 here. It may only give us a small amount of extra time, but it= won't give us negative extra time. So the tradeoff is, presumably, whe= ther the 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 w= orth it.

The idea of 'people will think it a f= alse positive', disagree, I think the whole tripwire idea is likely a *= bit* vulnerable to genpop misunderstanding as I said in my previous post, b= ut this particular thing I don't see it: a 192 bit being broken is *ver= y* 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 SHA256(G).

You slightly missed my point here, I think? The id= ea is that if you set up two sides that are both sample-able, you can birth= day. Like, you keep sampling a on one side and b on the other. Build tables= of both sides. Then all you have to do is check whether SHA2 of the LHS ev= er matches the RHS. This gives you a square root style speedup a la birthda= y attack. Contrast with if you just fix G, then keep searching for matches:= no square root speedup. This is relevant because the hypothetical evil cur= ve-generator who is trying to poison the future H=3DSHA2(G) has an easier t= ime in doing so, than a future canary-solver who obviously cannot try diffe= rent values of G :)

About your single-target vs multi-target distinction: interesting = point is that Shor can target any specific dlog problem, right. So I do thi= nk the ST is the correct version of the problem? But actually I am quite un= sure and unclear about those ST, MT, LMT distinctions you're making; sp= ecifically I mean, I am very unsure about how they differ in costs.

As for characterizing the problem, I think it's fair = to say: if you assumed SHA2 was a proper random oracle then we have with SH= A2(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 actu= al hash function and not an RO, then I think there's some statement lik= e "assuming SHA2 has no structure "matching" secp256k1, then= it's tightly 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-th= read: we obviously don't want to *literally* use BIP341's H on a 25= 6 bit tripwire, because then a Shor-break directly steals a bunch of coins,= so what should we use? Maybe SHA2(SHA2(enc(G)) ?

=
On Friday, August= 14, 2026 at 12:34:54=E2=80=AFPM UTC-6 conduition wrote:
An obvious question to raise: would we consider tripwiring a 192 b= it group break of a similar type (NUMS)? I find that ... plausible?

<= div style=3D"font-family:Arial,sans-serif;font-size:14px">A 192-bit curve i= think should be reasonable as a canary, but consider this: If someone alre= ady has a QC that breaks 192-bit ECC, how long until they build one which b= reaks 256-bit ECC? A day, a week, a year? No way of knowing. If the delay i= s too long, users may see the canary as a false-positive, and migrate back = to vulnerable addresses, and they might even be right. 192-bit canaries are= vulnerable to classical attack with work approximately 2^96. We should bea= r in mind the possibility that such a canary could be activated possibly ve= ry early, well before Q-day, possibly even in the absence of any quantum co= mputers.

I= deally 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 eff= ectively fungible with a 256-bit canary (because then it's less likely = to be activated before theft occurs).

w.r.t. 'This guarantees that the 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 function so that you co= uldn't find G =3D a * B and SHA2(G) =3D b*B for some base B in some fea= sible computation (sans CQRC of course, as was likely back then!). I have n= o idea what precise name you give to that property. OK, this is a ridiculou= s thing to discuss, perhaps, given when SHA2 and secp256k1 were standardize= d :) And given the encoding choices for our BIP341 NUMS (iirc the same as f= or Elements back in the day? using uncompressed encoding?) were able 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 an= d 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 th= at 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 pse= udorandom challenge point. The reason for using SHA256 instead of, say, pic= king an arbitary point by committee or using digits of pi or some other tri= ckery, is that hash outputs are supposed to be random and so SHA256(G= )=E2=80=8B is (assumably) a random ECDLP challenge. This matches the= classical definition of ECDLP more tightly: Given an arbitrary point 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 factor an hone= stly-sampled challenge point, they can factor any point. SHA256 is just a s= tand-in for the "honestly-sampled" part.
<= br>
However= , the following two tasks are actually very different:

  1. Given G, find scalar a=E2=80=8B such that = a*G =3D lift_x(SHA256(G))=E2=80=8B.
  2. Given G, find scalar a=E2=80=8B and me= ssage m=E2=80=8B such that a*G =3D lift_x(SHA256(m))=E2=80=8B.

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 factor is a fixed target, as i= s the one sampled honestly by the ECDLP security game.

=
In the case of task 2, the attacker can sample arbitrary messages to c= reate multiple target points, and the attacker wins if they succeed = in factoring any of them. The attacker can attack all those target points c= oncurrently if they want, and they get a speedup from doing so.
<= br>
So I believe it is worth disambiguating canaries between the = two cases, because they are different security notions. The first (1) I wou= ld call single-target ECDLP (ST-ECDLP), and the second (2) I would c= all multi-target ECDLP (MT-ECDLP).

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

For example,= say I sample 2 different messages m1=E2=80=8B and m2=E2=80=8B, and compute ECDLP target points T1 =3D lift_x(SHA256(m= 1))=E2=80=8B and T2 =3D lift_x(SHA256(m2))=E2=80=8B. Th= en 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 T1=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 al= so admits a more efficient basic unit of computation in brute force attacks= (including Grover) by using hashes instead of EC point multiplications. If= I instead start by picking scalar t=E2=80=8B and fix the targ= et point T =3D t*G=E2=80=8B, then I can run a brute-force prei= mage search 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 m= ulti-target attack [1].

With ST-ECDLP, we have onl= y a single fixed message m =3D G=E2=80=8B, and so the attacker= can't use those multi-target cheat codes. They can parallelize, use po= llard-rho or Shor or other algorithms, but they have only a single target p= oint that they must break to win the game.

The met= hod Pieter suggested using for the canary construction is equivalent to = single-target 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 spe= nd of such a script would trigger the canary. This would be multi-target= ECDLP.

I'm not sure which is better.

  • ST-ECDLP is less likely to be = triggered early or mistakenly, and is more tightly equivalent to ECDLP.
  • MT-ECDLP is more reflec= tive of how real-world 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 Pie= ter's, featuring ST-ECDLP, just because I'm not sure what other tri= cks could be used to potentially trigger MT-ECDLP classically or quantumly.=

We could also engineer a compromise between= the two, where we limit the number of targets. For example, define the gam= e like this:

Given G= =E2=80=8B, find scalar a=E2=80=8B=E2=80=8B and 32-bit i= nteger i=E2=80=8B=E2=80=8B such that a*G =3D lift_x(SHA2= 56(G || i))=E2=80=8B=E2=80=8B.

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

=

regards,
conduition


[1]: First, generate a bunch of target po= ints. 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 each point? point doubling is cheaper than add= ition or multiplication, and still covers the whole curve. Then we run a mu= lti-target SHA256 preimage search 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 chanc= e of success. If we find a valid message 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 found 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 co= nsensus".

I agree it's valuable. In the scenari= o of adversarial actor(s) gaining access to CQRC first, i.e. no whitehats, = only blackhats, obviously nothing to discuss; touching a NUMS ECDL is the l= ast thing they'll do. So I'm slightly worried that the general user= base will not notice that point, instead thinking it's a solid defense = when it ... depends.

In the scenario of at least s= ome whitehats, we get wires tripped, or canaries singing. Having it in cons= ensus is nice. The blockchain then does its job of being an unambiguous sig= nal and we can have all the arguments well ahead of time. [1]
On the other hand, we traditionally design such systems adversa= rially, right, so you could argue that an overfocus on this might be subopt= imal - it might be better to do other things.

(Sim= ilar comment applies to the 'smaller group canary' - definitely not= hing wrong with it, but it is not in itself a defence unless we strongly be= lieve whitehats, and *active* whitehats at that, are keeping up). An obviou= s question to raise: would we consider tripwiring a 192 bit group break of = a similar type (NUMS)? I find that ... plausible?

> Th= e BIP341 NUMS point (which I suggest using in this context) is the point wh= ose X coordinate is the SHA256 hash of the generator point G. This guarante= es that the NUMS point cannot predate 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 the NUMS point cannot predate G= 9; yes based on SHA2 preimage resistance, but: isn't the real point tha= t we're relying on SHA-2 not being a naughty function so that you could= n't find G =3D a * B and SHA2(G) =3D b*B for some base B in some feasib= le computation (sans CQRC of course, as was likely back then!). I have no i= dea what precise name you give to that property. OK, this is a ridiculous t= hing to discuss, perhaps, given when SHA2 and secp256k1 were standardized := ) And given the encoding choices for our BIP341 NUMS (iirc the same as for = Elements back in the day? using uncompressed encoding?) were able to be cou= nted on the fingers of the hand which the sleeve does not cover :)

[1] I take Antoine's point that making it consensus me= ans the miners are involved and there is a non-trivial collusion risk if th= e 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=AFPM UTC-6 A= ntoine Riard wrote:
Hi Pieter,

Thanks for the observations.

When I= was saying there is a problem with the game theory,
it's that strik= ingly, any activation of the tripwire logic
would rely on a "flag&q= uot; 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= .

Any "flag" transaction can be itself re-orged out of the= chain
to purely disable the effects of the EC disabling threshold,
t= herefore make it null and void as an effect. One might see
it as a compe= ting race between a group of "sunsetting" users
and a (majorit= y) 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].

In pure terms of satoshi fee denominated calculus, empirically=
global miners have won an average of $20 B yearly. If we only
consid= er 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 t= alk already about 1.7 M of coins or as of
today valuation $107 B (the in= formation is on the chain and can
be verified).

That's $107B = can "burn" in revenue or income that a CRQC-enabled
miners coa= lition 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 c= ount 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 opportunity of massive in= come ?

Leveraging Shor the exploitation might be even done anonymous= ly
as the mining process is done. Not even certainty, by who the
EC-p= rotected coins could be covertly exfiltrated.

That's the most st= riking problem when you think about the math
with any "tripwire&quo= t; approach, or even an "hourglass" one relying
on a "fla= g" transaction [1]. I'm ruling out "checkpoints" and
= any other trust-the-dev approach, as that's even worst [2].

As y= ou'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.

Beyond, and to answer bac= k your point, I still think you can
manage an escape hatch of the "= tripwire" effect, it's all depends
how the script tripwire logi= c is implemented, but if you have
two OP_SUCCESS of different kinds befo= re your EC CHECKSIG, you
can always have a "soft-fork" after t= he "tripwire" to return
true on the stack, with an EC or hash= lock as a success (I agree
using undefined op_success in a script is not= safe at all) [3].

Best,
Antoine
OTS hash: 4bc91d8dee1625f6e7= 8b27c88bced8e405f25ef6d3d8fd59be8016db5b0fbe66

[0] See naumenkog'= ;s https:= //www.bitmex.com/blog/txwithhold-smart-contracts
[1] This is sad, as= the "hourglass" depending how the parameters are chosen
was a= more acceptable trade-off than pure sunsetting.
[2] Given the amounts a= t stake to sunset, as a group of developers you
would just paint yoursel= f a target, there are more even funds at stake
that Satoshi herself / hi= mself is assumed to have.
[3] There is no security proof in BIP341 on th= e unforgeability of the
NUMS point, if it binds in the ROM or whatever.<= /div>
Le sam. 4 juil. 2026 =C3=A0 13:47, Sjors Pr= ovoost <sj...@sprovoost.nl&g= t; 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 BIP340 signature of m by P. That would allow the victim of post-qu= antum theft via a key-path spend of a BIP341 NUMS IPK to trigger the tripwi= re, in addition to someone who has direct access to a CRQC.
>
> Indeed, I had considered something similar, but see above for why I= 9;m
> not convinced supporting non-cooperative CRQCs is that useful.
>
> Also, in my view the tripwire isn't really a security feature on i= tself
> (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&qu= ot; 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, 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 st= yle header scan to see if the rule activated. Instead the prototype stores = it in a file along with a merkle inclusion proof, which is read when the no= de restarts.

With this mechanism it doesn't really need to be in the coinbase transa= ction, but that does seem more convenient and miners can censor it anyway.<= br>
- 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 &= quot;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 &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/d84e4a53-f3b1-4cd1-9a86-9591ec8c7211n%40googlegroups.com.
------=_Part_158259_1263434358.1786817182577-- ------=_Part_158258_1491725832.1786817182577--