From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 15 Aug 2026 08:14:28 -0700 Received: from mail-oo1-f58.google.com ([209.85.161.58]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wvG5a-0006EU-3O for bitcoindev@gnusha.org; Sat, 15 Aug 2026 08:14:28 -0700 Received: by mail-oo1-f58.google.com with SMTP id 006d021491bc7-6aea69817d1sf1866754eaf.2 for ; Sat, 15 Aug 2026 08:14:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1786806860; x=1787411660; 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=p7xpnzCJoMonUKgGRDOah5xN9U+oRiXaj41FNsdKq/Y=; b=djtKQcyV/MnMP59RD83hxVeGXXuugBTvglxwHGEh7y5J6vQJeMaxC4+/nPW61BFlhQ TjMtKXt/FTzF6KWrtMjdFLFU9VB6nSy3zkBgo8fi9RHaTSf8+qIH2jFDaKgx8QBIZmlr CroBjXhIOWwimWzZ08APcNWz2RNRK14LHkHjpCMzaia0JB47MzuSA08fSh1MME0wBaUe DmoYsHOJtWp16pXC5GHbRlOcibttG7v3ItTXheP9XzGpz0PMERdqFUJNoy5hwH25CC7e uuDeYxGP8SN+YgMgNWhV/gX3OjCQ+mbsrbGLe1d4GRmmcPImLo9NUOo/4j77XhKjOktR qiOA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786806860; x=1787411660; 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=p7xpnzCJoMonUKgGRDOah5xN9U+oRiXaj41FNsdKq/Y=; b=E0OVWUMn+LOy5csiEE3gg3QSSSINZJyQt+PlaWyrZ4gpYv/TBha4XwBRk+ID4ZIrKm Obucjp399xl3qJvAlUdqwFdKm6mg2/9Z3JPIjMHrCi59yaQrv3zY4DJ4hTIDCVzb/BBg z84a5OYyhebezMEei7X5nEJ7SiCTAccQcuVpmUiX9C1n6UXQi1mfWrjWDc3qJeqJmDZo OnPmdAOx+kZuyHOoTLPcwNBvDiD+D85snFfroc6yXmvwOIkms4LypjBqGxBu7jtfhcas wtzvl2w3IeXIS2aGAfRYGFAiuZf/QGQO7hIq+wtqlp4hkEowjD+y+lPIQvUpRldLmR/J NKjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786806860; x=1787411660; 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=p7xpnzCJoMonUKgGRDOah5xN9U+oRiXaj41FNsdKq/Y=; b=lFel/rIWRPdXWqyL3ZTLxveOcXtA5QBGBP4acJ33uNS2ABq57zzbsO8u6zypYgyjvw OkkdVzjNutR8UPDtLzoA0gs5CI2o4V6nfUWupwuy1lYB4CTtUyKGbNGP80vp0s+h+0se XuU2e2abUlmgfOLsEuidwnWsxwC49ucecHmeWFPytInGYeGkHX2apd864pgNzvx2GwKh nJ9jHA0jw1jUOq1/Ij9Vm1GGheiduaVpiZ3qxeSripwEKjbpICRCwO+vRueXVajKB8bv a6kghyjcSrH/wVA2wGP8rjK2Skiza9UJFseJNe1g2GsCht1rZobqS8M/ubZiFi27nSBS TOJg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AHgh+RoeOoTezjgfGTLhO5KCNd43Rj734nD6vYjoU7dMgI0AFfvPbCHgMxZ/rO90UR2psUtPHDAgA9J4iEPr@gnusha.org X-Gm-Message-State: AOJu0YwbZJ3vhVRnQ7JfmgubRCeK9Gccifqqt7th/0tsxguaWyMaUEeO 9N9HWqpU8660O+iWHqQrC9zGxJXpXuB9vkI/rsHfMeLOXby+J72UoHLR X-Received: by 2002:a05:6820:709a:20b0:6b0:1ba4:dcc5 with SMTP id 006d021491bc7-6b0d6262bd3mr8934424eaf.20.1786806859759; Sat, 15 Aug 2026 08:14:19 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="Aa7YSPSWedYT14Jd/TXxWDEsFVF+yAySTvt1stsNI77Tg/5hsw==" Received: by 2002:a05:6820:1c86:b0:6b0:b23a:7fb with SMTP id 006d021491bc7-6b0c4e4cb05ls2479941eaf.2.-pod-prod-04-us; Sat, 15 Aug 2026 08:14:13 -0700 (PDT) X-Received: by 2002:a05:6808:bc6:b0:492:5684:7ab3 with SMTP id 5614622812f47-4b241f1bf85mr12442108b6e.21.1786806853668; Sat, 15 Aug 2026 08:14:13 -0700 (PDT) Received: by 2002:a05:690c:c05c:b0:81e:ee9e:9148 with SMTP id 00721157ae682-82325eb7472ms7b3; Sat, 15 Aug 2026 07:49:36 -0700 (PDT) X-Received: by 2002:a05:690c:ec5:b0:814:585f:73c8 with SMTP id 00721157ae682-83708aaec72mr51087487b3.0.1786805372688; Sat, 15 Aug 2026 07:49:32 -0700 (PDT) Date: Sat, 15 Aug 2026 07:49:32 -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_397904_10573795.1786805372341" 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: 3.2 (+++) ------=_Part_397904_10573795.1786805372341 Content-Type: multipart/alternative; boundary="----=_Part_397905_979205915.1786805372341" ------=_Part_397905_979205915.1786805372341 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > 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, possibly= =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 below= =20 192 means classical attack and therefore bad idea. Which is why I said 192= =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 additional= =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 the= =20 whole tripwire idea is likely a *bit* vulnerable to genpop misunderstanding= =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 your= 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 up= =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. Then= =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 who= =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 is= =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 assumed= =20 SHA2 was a proper random oracle then we have with SHA2(enc(G)), something= =20 that's very tightly equivalent to ECDLP, which is what we want. If we want= =20 to pay attention to the fact that SHA2 is an actual hash function and not= =20 an RO, then I think there's some statement like "assuming SHA2 has no=20 structure "matching" secp256k1, then it's tightly equivalent to ECDLP on=20 secp256k1" which is obviously horrendously vague, but would not be very=20 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] 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 grou= p=20 > 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 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. > > 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 o= n=20 > SHA2 preimage resistance, but: isn't the real point that we're relying on= =20 > SHA-2 not being a naughty function so that you couldn't find G =3D a * B = and=20 > SHA2(G) =3D b*B for some base B in some feasible computation (sans CQRC o= f=20 > 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, perhaps= ,=20 > given when SHA2 and secp256k1 were standardized :) And given the encoding= =20 > choices for our BIP341 NUMS (iirc the same as for Elements back in the da= y?=20 > using uncompressed encoding?) were able to be counted on the fingers of t= he=20 > hand which the sleeve does not cover :) > > > Anyone can find G =3D a * B=E2=80=8B. Just generate a key and invert your= secret=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 SHA256= =20 > instead of, say, picking an arbitary point by committee or using digits o= f=20 > pi or some other trickery, is that hash outputs are supposed to be random= =20 > and so SHA256(G)=E2=80=8B is (assumably) a random ECDLP challenge. This m= atches=20 > the classical definition of ECDLP more tightly: Given an arbitrary point = P=E2=80=8B,=20 > find p=E2=80=8B such that P =3D p * G=E2=80=8B. The assumption is that if= an attacker can=20 > factor an honestly-sampled challenge point, they can factor any point.=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 is= =20 > more tightly equivalent to ECDLP, because the point we're trying to facto= r=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 in= =20 > factoring any of them. The attacker can attack all those target points=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 can= =20 > make progress against more than one target concurrently, and breaking any= =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 s= o 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 se= arch 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 a= ttack=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 a= n=20 > easier problem than ST-ECDLP, but harder than MT-ECDLP. Maybe call it *li= mited=20 > multi-target ECDLP (LMT-ECDLP)*? > > > regards, > conduition > > > [1]: First, generate a bunch of target points. Sample scalar t=E2=80=8B a= nd 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 m= essage 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, t= hen 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 nothin= g=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 doe= s=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 strong= ly=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. Thi= s=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 functio= n=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 o= n=20 > SHA2 preimage resistance, but: isn't the real point that we're relying on= =20 > SHA-2 not being a naughty function so that you couldn't find G =3D a * B = and=20 > SHA2(G) =3D b*B for some base B in some feasible computation (sans CQRC o= f=20 > 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, perhaps= ,=20 > given when SHA2 and secp256k1 were standardized :) And given the encoding= =20 > choices for our BIP341 NUMS (iirc the same as for Elements back in the da= y?=20 > using uncompressed encoding?) were able to be counted on the fingers of t= he=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 high= ,=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: 4bc91d8dee1625f6e78b27c88bced8e405f25ef6d3d8fd59be8016db5b0fbe= 66 >> >> [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 usin= g=20 >>> > a separate message. Less places a node needs to check, but I'm=20 >>> > concerned about the difficulty of testing infrastructure that relay o= f=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-quantum= =20 >>> theft via a key-path spend of a BIP341 NUMS IPK to trigger the tripwire= , 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 it= be=20 >>> locked to a transaction, so you only having to check the coinbase for t= he=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 n= ode=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 it'= s=20 >>> 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 i= t=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-e9= 91aa1f0eb3%40app.fastmail.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/f6d78499-d551-45ea-89b1-2b9c= bd52f5can%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/= fd947d7c-86fd-407c-98aa-0a63b8be28fan%40googlegroups.com. ------=_Part_397905_979205915.1786805372341 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable >=C2=A0A 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.=C2=A0192-bit canaries are vulnerable to = classical attack with work approximately 2^96. We should bear in mind the p= ossibility that such a canary could be activated possibly very early, well = before Q-day, possibly even in the absence of any quantum computers.=

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

The idea of 'people will think it a false p= ositive', disagree, I think the whole tripwire idea is likely a *bit* vulne= rable to genpop misunderstanding as I said in my previous post, but this pa= rticular thing I don't see it: a 192 bit being broken is *very* likely to c= ause an appropriate level of panic.

>=C2=A0Anyone can find=C2=A0G =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
<= div style=3D"font-family: Arial, sans-serif;">
> The hard part is then finding some b suc= h that=C2=A0b*G =3D SHA256(G).

You slig= htly missed my point here, I think? The idea is that if you set up two side= s that are both sample-able, you can birthday. 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 ever matches the RHS. This gives yo= u a square root style speedup a la birthday attack. Contrast with if you ju= st fix G, then keep searching for matches: no square root speedup. This is = relevant because the hypothetical evil curve-generator who is trying to poi= son the future H=3DSHA2(G) has an easier time in doing so, than a future ca= nary-solver who obviously cannot try different values of G :)

About your single-t= arget vs multi-target distinction: interesting point is that Shor can targe= t any specific dlog problem, right. So I do think the ST is the correct ver= sion of the problem? But actually I am quite unsure and unclear about those= ST, MT, LMT distinctions you're making; specifically I mean, I am very uns= ure about how they differ in costs.

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

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

=

[1]=C2=A0https://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 obviou= s question to raise: would we consider tripwiring a 192 bit group break of = a similar type (NUMS)? I find that ... plausible?

A 192-bit curve i think should be r= easonable as a canary, but consider this: If someone already has a QC that = breaks 192-bit ECC, how long until they build one which breaks 256-bit ECC?= A day, a week, a year? No way of knowing. If the delay is too long, users = may see the canary as a false-positive, and migrate back to vulnerable addr= esses, and they might even be right.=C2=A0192-bit canaries are vulnerable t= o classical attack with work approximately 2^96. We should bear in mind the= possibility that such a canary could be activated possibly very early, wel= l before Q-day, possibly even in the absence of any quantum computers.

Ideally we wan= t a short gap between "192-bit is broken" and "256-bit is br= oken", but not so short as to make the 192-bit canary effectively fung= ible with a 256-bit canary (because then it's less likely to be activat= ed before theft occurs).

w.= r.t. 'This guarantees that the NUMS point cannot predate G' yes bas= ed on SHA2 preimage resistance, but: isn't the real point that we'r= e relying on SHA-2 not being a naughty function so that you couldn't fi= nd G =3D a * B and SHA2(G) =3D b*B for some base B in some feasible computa= tion (sans CQRC of course, as was likely back then!). I have no idea what p= recise name you give to that property. OK, this is a ridiculous thing to di= scuss, perhaps, given when SHA2 and secp256k1 were standardized :) And give= n the encoding choices for our BIP341 NUMS (iirc the same as for Elements b= ack in the day? using uncompressed encoding?) were able to be counted on th= e fingers of the hand which the sleeve does not cover :)

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

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

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

---------

If we reflect on the requirement that G=E2=80=8B is fixed,= we see SHA256(G)=E2=80=8B is also fixed as a pseudorandom cha= llenge point. The reason for using SHA256 instead of, say, picking an arbit= ary point by committee or using digits of pi or some other trickery, is tha= t 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 honestly-sam= pled challenge point, they can factor any point. SHA256 is just a stand-in = for the "honestly-sampled" part.

However, the fo= llowing two tasks are actually very different:

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

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

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

So I believe it is worth disambiguating canaries between th= e two cases, because they are different security notions. The first (1) I w= ould call=C2=A0single-target ECDLP (ST-ECDLP), and the second (2) I = would call=C2=A0multi-target ECDLP (MT-ECDLP).

<= div>It's pretty clear that MT-ECDLP is easier to break, because attacke= rs can make progress against more than one target concurrently, and breakin= g 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=C2=A0T1 = =3D lift_x(SHA256(m1))=E2=80=8B and T2 =3D lift_x(SHA256(m2))<= /code>=E2=80=8B. Then if I sample a random scalar r=E2=80=8B a= nd 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<= /code>=E2=80=8B, T4=E2=80=8B, ... and so on.

MT-ECDLP also 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 target point T =3D t*G=E2=80=8B, then I can ru= n a brute-force preimage 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 multi-target attack [1].

With S= T-ECDLP, we have only 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 pollard-rho or Shor or other algorithms, but they have on= ly a single target point that they must break to win the game.
The method 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.=C2= =A0

  • ST-ECDLP is less likely= to be triggered early or mistakenly, and is more tightly equivalent to ECD= LP.=C2=A0
  • MT-ECDLP is= more reflective of how real-world attackers behave on Bitcoin (e.g. with t= housands-to-millions of public keys available to attack in parallel, and br= eaking even one is considered unacceptable).
I'm slightly leanings towards a construct= ion like Pieter's, featuring ST-ECDLP, just because I'm not sure wh= at other tricks could be used to potentially trigger MT-ECDLP classically o= r quantumly.

We could also engineer a compro= mise between the two, where we limit the number of targets. For example, de= fine the game like this:

G= iven G=E2=80=8B, find scalar a=E2=80=8B=E2=80=8B = and 32-bit integer=C2=A0i=E2=80=8B=E2=80=8B such that a*= G =3D lift_x(SHA256(G || i))=E2=80=8B=E2=80=8B.
<= div>
Then the adversary can only attack against at mos= t 2^32 unique target points, and those targets are fixed forever, for any a= dversary. 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 bun= ch of target points. Sample scalar=C2=A0t=E2=80=8B and c= ompute 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 addition or multiplication, and still covers the whole cur= ve. Then we run a multi-target SHA256 preimage search over all targets [x(T= 0), x(T1), x(T2), x(T3), ...]=E2=80=8B. If we have n=E2=80=8B targets and c= urve order N=E2=80=8B, then each message hash has an n/N=E2=80= =8B=E2=80=8B chance of success. If we find a valid 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 bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/fd947d7c-86fd-407c-98aa-0a63b8be28fan%40googlegroups.com.
------=_Part_397905_979205915.1786805372341-- ------=_Part_397904_10573795.1786805372341--