From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 18 Aug 2026 02:17:42 -0700 Received: from mail-oa1-f62.google.com ([209.85.160.62]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wwFwx-0001CV-3a for bitcoindev@gnusha.org; Tue, 18 Aug 2026 02:17:42 -0700 Received: by mail-oa1-f62.google.com with SMTP id 586e51a60fabf-448bb8bd2efsf7018471fac.0 for ; Tue, 18 Aug 2026 02:17:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1787044652; x=1787649452; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to: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=l82iuOmcA3q5OIRyOSYf38M/06841zOVYcdj5Jj/th4=; b=bnfjW0IW9crWrHnAUZI39jGU2Y1XSceQzzJuep40PE0tVYBVvRfZUfe24w4m60iflP FUq4MZTETqKAyciGFG+CELx9GKX7iNwECHiRmuBNXOmrWzzEJyepV20aknOW18XeHbaN V6wXBL08cscvKgbycMeR/3GR5VgObLMJQ4J4Fv2xBfRTnfFzH1my1QjQeiouUPrU9uB3 O65bUXDrC0Muc6VHGviFuVVASvQ93t7m9/uLyUNO90MBSFCeDBCzEqv+MDJOEDDRK9ky O5KKf27U1ndX4FZp990+UfI0Duj80s04vNbVTUu+lrx5ysvSEk4nudMCm2t9SzkZ23Mq ZZow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787044652; x=1787649452; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:x-original-sender :content-type:mime-version:subject:references:in-reply-to:message-id :to:from:date:x-beenthere:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=l82iuOmcA3q5OIRyOSYf38M/06841zOVYcdj5Jj/th4=; b=CNJcjpklBzwulCvPfJ3X/BD3sgxkL/jDvO4rW0SMD+sx+CR+FluvJ7eAZiGS2nvJEd I/C8w6/FjTlLUcao+biwO0N+1uU01T2FnLp5PyKYBty5lLin3e9pXuwDowVA+0nNbHA/ I/iIwIrz+FNDWFwV9Sov2BClv0WTM7Mu8K4Uq+Gd8jnuBJET74lgduSDyKP6sgvkbnSi L7bBHBiT23Zs8PNcrvT6JgpZn+oEvU3Y9U/5RX5Xt4Ouhj/UCWfapGy+YzJl/r76lZIy 4bcfbu43yq28+oHOMH6wZ8ezD/XXEakbMebcCMnkuJjuP/3iNJmsV7a0b6erZJf+zvEh rCHg== X-Forwarded-Encrypted: i=1; AHgh+Rr4O4Wr1vwOwAnfX92C4I74DX9ezFdvQqz7o+d2B4en3gUmdGSK0P5ghrH7ztmDrMfJJtl4y0D8vH1J@gnusha.org X-Gm-Message-State: AOJu0YzDnCbVydcv6eeTVoVy8g2YpC5CZHIQOhNBgEKy9L/AJhjNBnuf df/aHJTuOWPNsbxPOqUG6ffDsYDCUr1ehxArPqFkBw78D02RfayYrbig X-Received: by 2002:a05:6870:e9aa:b0:448:9a86:aff9 with SMTP id 586e51a60fabf-45e92045b85mr26205609fac.15.1787044652532; Tue, 18 Aug 2026 02:17:32 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ATskLdfbmPzrrDYBed8iDDll/G0Gtnxo+RQroHZHCHXBDUEjSQ==" Received: by 2002:a05:6871:7403:b0:45e:435c:5ea with SMTP id 586e51a60fabf-45e5c043ed0ls3375145fac.1.-pod-prod-06-us; Tue, 18 Aug 2026 02:17:25 -0700 (PDT) X-Received: by 2002:a05:6808:3305:b0:4a4:25b4:a0be with SMTP id 5614622812f47-4b240f9b072mr29802881b6e.2.1787044645836; Tue, 18 Aug 2026 02:17:25 -0700 (PDT) Received: by 2002:a05:690c:a642:b0:80b:2194:fea2 with SMTP id 00721157ae682-82320fd1896ms7b3; Sun, 16 Aug 2026 12:30:04 -0700 (PDT) X-Received: by 2002:a05:690c:e68f:20b0:815:bc6a:2e48 with SMTP id 00721157ae682-8370ea71c6bmr56014697b3.14.1786908603007; Sun, 16 Aug 2026 12:30:03 -0700 (PDT) Date: Sun, 16 Aug 2026 12:30:02 -0700 (PDT) From: "'conduition' via Bitcoin Development Mailing List" To: Bitcoin Development Mailing List Message-Id: <22f8b95d-403c-4a3e-ad64-221faf2ea851n@googlegroups.com> 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_358928_1967542620.1786908602620" X-Original-Sender: conduition@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 (++) ------=_Part_358928_1967542620.1786908602620 Content-Type: multipart/alternative; boundary="----=_Part_358929_81099652.1786908602620" ------=_Part_358929_81099652.1786908602620 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm hesitant to say I support a 192-bit canary outright, but I like the=20 idea and I think more research is needed to confirm whether it would work,= =20 or if such a system would be over- or under-sensitive (i.e. triggered too= =20 late by the first powerful quantum computer, or triggered exceptionally=20 early by a classical attack). I'm especially interested in any attempts to= =20 estimate a rough time delta between the "secp192r is broken" and "secp256k1= =20 is broken" events. I suppose that's more a question for the QC experts (not= =20 me). I'll have a go anyway. Based on logical qubit count estimates in the google paper=20 (see=20 page 7), a QC needs at least 4.5 * n qubits to crack a curve of n bits=20 (with a practical Toffoli gate count). So secp192r1 might be broken by more= =20 than 192 * 4.5 =3D 900 logical qubits. Breaking secp256k1 requires at least= =20 1200. So how difficult would it be for a QC to scale from 900 to 1200 qubits? If= =20 we assume QC scaling will follow moore's law (if it ever scales at all),=20 then that's worrisome: less than half a doubling of margin. The first QC=20 that breaks secp192r1 might very well also be able to break secp256k1. Also: I read the QCAP thread=20 ,=20 and my initial impression is that using DLEQAG proofs to share the secret= =20 among a trusted group is overkill: If breaking a 192-bit curve such as=20 secp192r1 suffices to prove "QCs are coming" and so activate a soft fork,= =20 then why go through the effort to map that statement to secp256k1? We can= =20 just use a secp192r1 canary proof on its own as a self-contained=20 cryptographic statement published on-chain. Then the proof can use a NUMS= =20 point generated in some honest fashion, same as for secp256k1. Nodes could= =20 activate the canary as soon as they see the canary proof published anywhere= =20 on-chain (e.g. OP_RETURN). As discussed before in this thread, there's no= =20 need to tie the canary specifically to a Bitcoin UTXO being spent. regards, conduition On Saturday, August 15, 2026 at 1:12:44=E2=80=AFPM UTC-5 waxwing/ AdamISZ w= rote: > 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, t= han=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 li= ve=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 wrot= e: > >> 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, = than=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 realiz= e=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 l= ive=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 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. >> >> 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 be= low=20 >> 192 means classical attack and therefore bad idea. Which is why I said 1= 92=20 >> and not sub 160. What's not obvious is that 192 is worse than 256 here. = It=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 additio= nal=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= =20 >> the whole tripwire idea is likely a *bit* vulnerable to genpop=20 >> misunderstanding as I said in my previous post, but this particular thin= g I=20 >> don't see it: a 192 bit being broken is *very* likely to cause an=20 >> appropriate level of panic. >> >> > Anyone can find G =3D a * B=E2=80=8B. Just generate a key and invert y= our 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= =20 >> up 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. T= hen=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. Contras= t=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 = who=20 >> is trying to poison the future H=3DSHA2(G) has an easier time in doing s= o,=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= =20 >> is that Shor can target any specific dlog problem, right. So I do think = the=20 >> ST is the correct version of the problem? But actually I am quite unsure= =20 >> and unclear about those ST, MT, LMT distinctions you're making;=20 >> specifically 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=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 "assumi= ng=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 us= e?=20 >> Maybe SHA2(SHA2(enc(G)) ? >> >> >> [1]=20 >> https://delvingbitcoin.org/t/qcap-a-bitcoin-native-quantum-canary-alert/= 2498/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 unt= il=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 migh= t=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 su= ch a=20 >>> canary could be activated possibly very early, well before Q-day, possi= bly=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 relyi= ng=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 = CQRC=20 >>> of course, as was likely back then!). I have no idea what precise name = you=20 >>> give to that property. OK, this is a ridiculous thing to discuss, perha= ps,=20 >>> given when SHA2 and secp256k1 were standardized :) And given the encodi= ng=20 >>> choices for our BIP341 NUMS (iirc the same as for Elements back in the = day?=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 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). >>> >>> --------- >>> >>> If we reflect on the requirement that G=E2=80=8B is fixed, we see SHA25= 6(G)=E2=80=8B is=20 >>> also fixed as a pseudorandom challenge point. The reason for using SHA2= 56=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 rand= om=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 poin= t=20 >>> P=E2=80=8B, find p=E2=80=8B such that P =3D p * G=E2=80=8B. The assumpt= ion is that if an attacker=20 >>> can factor an honestly-sampled challenge point, they can factor any poi= nt.=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= =20 >>> is more tightly equivalent to ECDLP, because the point we're trying to= =20 >>> factor is a fixed target, as is the one sampled honestly by the ECDLP= =20 >>> security 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 poin= ts=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= =20 >>> can make progress against more than one target concurrently, and breaki= ng=20 >>> 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=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 brut= e=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 fi= x the=20 >>> target point T =3D t*G=E2=80=8B, then I can run a brute-force preimage = search 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, an= d 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 singl= e=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 a= s 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= =20 >>> is 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 *= limited=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 T= 2 + T2=E2=80=8B, etc.=20 >>> Why 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(T= 2),=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,=20 >>> such that SHA256(m) =3D=3D x(R_i)=E2=80=8B for some target index i=E2= =80=8B, then we have=20 >>> 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 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 noth= ing=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 d= oes=20 >>> its job of being an unambiguous signal and we can have all the argument= s=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 stro= ngly=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. T= his=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 funct= ion=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 relyi= ng=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 = CQRC=20 >>> of course, as was likely back then!). I have no idea what precise name = you=20 >>> give to that property. OK, this is a ridiculous thing to discuss, perha= ps,=20 >>> given when SHA2 and secp256k1 were standardized :) And given the encodi= ng=20 >>> choices for our BIP341 NUMS (iirc the same as for Elements back in the = day?=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 ar= e=20 >>> involved and there is a non-trivial collusion risk if the stakes are hi= gh,=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 valu= e=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-quant= um=20 >>>>> theft via a key-path spend of a BIP341 NUMS IPK to trigger the tripwi= re, in=20 >>>>> addition to someone who has direct access to a CRQC. >>>>> > >>>>> > Indeed, I had considered something similar, but see above for why= =20 >>>>> 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 th= e=20 >>>>> block via the coinbase witness commitment output, rather than having = it 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 P2= P=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 coinbas= e. >>>>> > >>>>> > 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 Do= S=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 o= f=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 rea= d 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 th= e=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-= e991aa1f0eb3%40app.fastmail.com >>>>> . >>>>> >>>> --=20 >>> >>> You received this message because you are subscribed to the Google=20 >>> Groups "Bitcoin Development Mailing List" group. >>> To unsubscribe from this group and stop receiving emails from it, send= =20 >>> an email to bitcoindev+...@googlegroups.com. >>> To view this discussion visit=20 >>> https://groups.google.com/d/msgid/bitcoindev/f6d78499-d551-45ea-89b1-2b= 9cbd52f5can%40googlegroups.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/fd947d7c-86fd-407c-98aa-0a6= 3b8be28fan%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/= 22f8b95d-403c-4a3e-ad64-221faf2ea851n%40googlegroups.com. ------=_Part_358929_81099652.1786908602620 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm hesitant to say I support a 192-bit canary outright, but I like the ide= a and I think more research is needed to confirm whether it would work, or = if such a system would be over- or under-sensitive (i.e. triggered too late= by the first powerful quantum computer, or triggered exceptionally early b= y a classical attack). I'm especially interested in any attempts to estimat= e a rough time delta between the "secp192r is broken" and "secp256k1 is bro= ken" events. I suppose that's more a question for the QC experts (not me). = I'll have a go anyway.

Based on logical qubit count es= timates in the google paper=C2=A0(see page 7), a Q= C needs at least 4.5 * n qubits to crack a curve of n bits (with a practica= l Toffoli gate count). So secp192r1 might be broken by more than 192 * 4.5 = =3D 900 logical qubits. Breaking secp256k1 requires at least 1200.

So how difficult would it be for a QC to scale from 900 = to 1200 qubits? If we assume QC scaling will follow moore's law (if it ever= scales at all), then that's worrisome: less than half a doubling of margin= . The first QC that breaks secp192r1 might very well also be able to break = secp256k1.

Also: I read the QCAP t= hread, and my initial impression is that=C2=A0using DLEQAG proofs to sh= are the secret among a trusted group is overkill: If breaking a 192-bit cur= ve such as secp192r1 suffices to prove "QCs are coming" and so activate a s= oft fork, then why go through the effort to map that statement to secp256k1= ? We can just use a secp192r1 canary proof on its own as a self-contained c= ryptographic statement published on-chain. Then the proof can use a NUMS po= int generated in some honest fashion, same as for secp256k1. Nodes could ac= tivate the canary as soon as they see the canary proof published anywhere o= n-chain (e.g. OP_RETURN). As discussed before in this thread, there's no ne= ed to tie the canary specifically to a Bitcoin UTXO being spent.
=
regards,
conduition

On Saturday, A= ugust 15, 2026 at 1:12:44=E2=80=AFPM UTC-5 waxwing/ AdamISZ wrote:
As if everything wasn= 't confusing enough, I also made one very notable error: What I was say= ing here:

>=C2=A0This 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 :)

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

>=C2=A0If we have any doubt about tha= t, 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 fir= st block in which the canary goes live (idea credit: Tadge Dryja).
Seems plausible.

I guess two tracks of conversation here; I'm still genuinel= y curious what people think about 192 bit and whether we can do it practica= lly, because, depending on how it plays out, it might buy very useful time.= The delving thread was focused on distributed keygen and ZKP for the canar= y, 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= 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-generat= or who is trying to poison the future H=3DSHA2(G) has an easier time in doi= ng so, than a future canary-solver who obviously cannot try different value= s of G :)

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

If we have any d= oubt about that, we could tweak the hash function with some data that is ne= wer than G but still unbiased, e.g. the hash of the genesis block, or the h= ash of the first block in which the canary goes live (idea credit: Ta= dge Dryja).

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?

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

<= span style=3D"font-size:10.5pt;line-height:normal;font-family:Arial,sans-se= rif">regards,
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/22f8b95d-403c-4a3e-ad64-221faf2ea851n%40googlegroups.com.
------=_Part_358929_81099652.1786908602620-- ------=_Part_358928_1967542620.1786908602620--