From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 14 Aug 2026 11:35:03 -0700 Received: from mail-ot1-f61.google.com ([209.85.210.61]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wuwk9-0001tQ-1F for bitcoindev@gnusha.org; Fri, 14 Aug 2026 11:35:03 -0700 Received: by mail-ot1-f61.google.com with SMTP id 46e09a7af769-7f39e32ca40sf257150a34.3 for ; Fri, 14 Aug 2026 11:35:00 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1786732494; cv=pass; d=google.com; s=arc-20260327; b=Ur+zDPoMW64Oe3jNm1k5joYlkFM3TF6dQBJZgyGDbUQwIkcPL9Xj5NoI3V/JRqKPL9 iTjrD1FRkr0mfT280245IplzHw0I6L85xJF3J3ULIXAIC6u1oDUgNR8jxo2n1wqPQ+lt hB3mP2dkx1c22ZMOHWlS8Xd+7jBrVGWl14jKVkNXQOYCqidXw+joCAbhxTkmRKco6nQA dv39t8rah1cK+ckKAczdo0Lc3Qdws50jTylD5n25UbXxt8aKuUSOqGiwxP6Khs+lrKBM kE6CguygeVfBEd1ecoqP/iuVY87ql4tgzDrk68uSfrkcuAhNamoU23mm/f7p7R3Gel5u I1TA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:mime-version:feedback-id :references:in-reply-to:message-id:subject:cc:from:to:date :dkim-signature; bh=GJ5ztqn2GrZX3G5rpHYzipl3zUgjFI6GHftzxD8O5lA=; fh=l9DMILDfl6vnNNa2kosUB2pYgyzQAQPgNntyPxo8hYI=; b=dhWiCQEqGVrcgMAkNkOLE5IKLWTKf+gXEFlbpn8m/dQzT7nKkHc9pmelsR8WT0OBYq s/ZMYYN54T97aXym8ypUrS0EM+aawERWeDIgFPUrMwvWtEUb8ySCFHBxBMGkjJHBiB0V JWOJXkhKS0bRlUpbkmh3aVP35C0wppzeDRRazouqobjbPmowEwa/RZariq8fMlDchoM4 +MZyoSTjvWVQROVMG4gZEtPgiaHdFEr647qpD97wjaCPrwJmzIP69Kr1ReG5758htGkX SlkPvCurFbVAQy9sO8/jc1AeYLovfCe4XtO7g7FCYT5UaY0mGzU+zEc/UC+narNYmzSz 1ukw==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=ljanrzwdhfaadkx2uuuu5j53uu.protonmail header.b=FnmGprMH; spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.103 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1786732494; x=1787337294; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:content-type :mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:from:to:cc:subject:date:message-id:reply-to :content-type; bh=GJ5ztqn2GrZX3G5rpHYzipl3zUgjFI6GHftzxD8O5lA=; b=k+q+lndCn31GRuSp865LIfvpP+O0YT3k4klQD0cPLclXTurpwa+mP9CTbwxUy7mo7L mRoLe29TtCBZgZJEX4foqV+Zep/hlZlZwjNoTIDMUcph2wzzqlfNnDnj347U1cZsTVT8 uV1EPGHTHwFCluhkBuou169oPMKgZsPeJCdMUqw1DeMjfD1xZ98wIgSRk8+gkzxp4JaN qzwo1JXfHBAnru0RSBjJM6lRsoFgmg+6MjgEkSZ+MZx/q/0Qr9BItaS3Y8Pu0NLZcTJE 8whaeRpWKd/ei/+LghhZKUwk+BVHOxD+N3omLHGXSQewpoFovhor1ScpbDx+4bJzpDBB /MEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786732494; x=1787337294; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:content-type :mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:x-beenthere:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to:content-type; bh=GJ5ztqn2GrZX3G5rpHYzipl3zUgjFI6GHftzxD8O5lA=; b=QPNLNg3Xv0wC621Gp0/uEsPh6IEnqN8EPr8infOT+mhIdPwFxo/H//DNiKH9X478pI KFryTaefGCuyEn3WPP2XTjG+xnY6FZfv+74Qh3oAHfts5Z5XrWUwwqNl5bskgUj33nX6 /W5+SORIpFEFTwWYCZlA37/cSeh2mbK9lcamuY1rX4RW7oMoE8jt+iSmGGCNxjcM8bHF EMaMrdfWhCEaX4hAtRAaMDMN6dD+W06fT5qv6/GXu1Oa9TCSEEdJ70eM5/u221CA63h8 FFvUIK1yj1OWLX2gbnG8RD+5DD9QRayPbViN8ZzFmJDEccjancRHxw8Ppckjh7CJweAn 4UQA== X-Forwarded-Encrypted: i=2; AHgh+RpPgU3ZqJc+R3ap8zFCj9v8dvToGh0KSLq/n9DSy3BKsaGCjArSVF/FAs/DmTULc04sD103qjMiwlIb@gnusha.org X-Gm-Message-State: AOJu0YyTLUN5d1KQmwAHNqHkX74tyus+AXDNvbPusULOMkwReP+2nxDa oKx9/zO4h9GX5w9gRIGCM34KVHrl1Kqie03LCwagaatFO8o70g3ofI+A X-Received: by 2002:a05:6830:909:b0:7e6:6f9f:7445 with SMTP id 46e09a7af769-7f3de5fd940mr4107038a34.3.1786732494100; Fri, 14 Aug 2026 11:34:54 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ATskLdfnQaI+KFCcmtVwvngZ+E3PBZxTrTfTuyYCpxb3zkNyUw==" Received: by 2002:a05:6870:c28b:b0:456:dd1a:b93d with SMTP id 586e51a60fabf-45e358bc1b6ls1969173fac.1.-pod-prod-00-us-canary; Fri, 14 Aug 2026 11:34:46 -0700 (PDT) X-Received: by 2002:a05:6808:1449:b0:4a0:9eab:4d0 with SMTP id 5614622812f47-4b2403b214bmr4261019b6e.11.1786732486699; Fri, 14 Aug 2026 11:34:46 -0700 (PDT) Received: by 2002:a05:6402:3608:b0:670:416a:5ab4 with SMTP id 4fb4d7f45d1cf-6a1cfd0f1cbmsa12; Fri, 14 Aug 2026 11:33:21 -0700 (PDT) X-Received: by 2002:a05:6402:52c6:b0:698:c13e:179a with SMTP id 4fb4d7f45d1cf-6a38a948d10mr3313661a12.10.1786732399659; Fri, 14 Aug 2026 11:33:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1786732399; cv=none; d=google.com; s=arc-20260327; b=Zv+z3SaVZHPJx0YlE72iAy208rMd/eCEg5JKKGnDjVptKpdKvi8flO1jJo4kesvozY x3hvkMKk43auTmP5Cal7I3JxQTGQJiJCiToy7kC+1scc/ZoLXbti92dBx4gDQv4c1YSe NVsKWlCi3oWtDfYuGHxbFwiDHjnA8xrQwgvsgursSxqvno3Z3jjIReN1jHSrrqLTd3BS LZDo2NB4TdvAru7WZlVTUdjIXstKlFTdx6l64fTOT95XksAuKL13IOAMM9CW/4qyM5TR Y3DC5ZdvC79v08FfA+ZhHLfu/ciRFBvy9UereLqMVZUC4aIY+3UeN2rjLe2blkbMmTW7 I0NA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:dkim-signature; bh=/cG2mOjo9xbqVAzumWgK9qkICt8q/dpGo7TyhFJ5euE=; fh=zwD6MnSx31+wTUYXvjlRY9wKEAVfUFCZok1hjFoWcUg=; b=IgS8SsAqAs3ETAkIfDZ7DMLKqY8JtNDRf9aHMTuokgtFfL5DU6y6wNz2FoV/I751wD 5O84ZNGTU642k+IC27ZXUYdO/acBwT3W6QeMuyo/X/QQlHYKfSRJ9MdwHoASLn0roZRj ILhb+X1EJInt32pnki923VsQGvitfD7PMbsd8BJecjBmCE70OLf2bpKdO+VQGYLY6iI8 aKZu6vsUyzCF833w+oWq2EXOVOvT4Br8bHwXf+Vwv1zXr0oO3cPgqt9Q36byKg4eFdXj 1fgwvRpPZ1fmWrR+jOXHOpMmFcH0257KC7+E1m3TiAYsvmPZHJWT3tANoipSOlAwrS4F WCGw==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=ljanrzwdhfaadkx2uuuu5j53uu.protonmail header.b=FnmGprMH; spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.103 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me Received: from mail-106103.protonmail.ch (mail-106103.protonmail.ch. [79.135.106.103]) by gmr-mx.google.com with ESMTPS id 4fb4d7f45d1cf-6a38d783b1dsi51849a12.8.2026.08.14.11.33.19 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 14 Aug 2026 11:33:19 -0700 (PDT) Received-SPF: pass (google.com: domain of conduition@proton.me designates 79.135.106.103 as permitted sender) client-ip=79.135.106.103; Date: Fri, 14 Aug 2026 18:33:14 +0000 To: waxwing/ AdamISZ From: "'conduition' via Bitcoin Development Mailing List" Cc: Bitcoin Development Mailing List Subject: Re: [bitcoindev] Giving teeth to expected EC disabling: P2XX(-T)(-ML) Message-ID: In-Reply-To: References: <002f2395-7d5d-4cb6-852c-e991aa1f0eb3@app.fastmail.com> Feedback-ID: 72003692:user:proton X-Pm-Message-ID: 9969d4250bad13d16393a1f79bd81d2f981142ee MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------02c36632dd4a6c75637f2e0340d62ee892cc28c6d4fdffad1e0961d9291fb793"; charset=utf-8 X-Original-Sender: conduition@proton.me X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=ljanrzwdhfaadkx2uuuu5j53uu.protonmail header.b=FnmGprMH; spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.103 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me X-Original-From: conduition Reply-To: conduition Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: 2.7 (++) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------02c36632dd4a6c75637f2e0340d62ee892cc28c6d4fdffad1e0961d9291fb793 Content-Type: multipart/mixed;boundary=---------------------ae6ef00487c0477d15f5c07e472339a0 -----------------------ae6ef00487c0477d15f5c07e472339a0 Content-Type: multipart/alternative;boundary=---------------------2a5b20a8ed0e32c8770c65ee26ad8653 -----------------------2a5b20a8ed0e32c8770c65ee26ad8653 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" > An obvious question to raise: would we consider tripwiring a 192 bit grou= p break of a similar type (NUMS)? I find that ... plausible? A 192-bit curve i think should be reasonable as a canary, but consider this= : If someone already has a QC that breaks 192-bit ECC, how long until they = build one which breaks 256-bit ECC? A day, a week, a year? No way of knowin= g. If the delay is 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 approximat= ely 2^96. We should bear in mind the possibility that such a canary could b= e activated possibly very early, well before Q-day, possibly even in the ab= sence of any quantum computers. Ideally we want a short gap between "192-bit is broken" and "256-bit is bro= ken", but not so short as to make the 192-bit canary effectively fungible w= ith 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 o= n SHA2 preimage resistance, but: isn't the real point that we're relying on= SHA-2 not being a naughty function so that you couldn't find G =3D a * B a= nd SHA2(G) =3D b*B for some base B in some feasible computation (sans CQRC = of course, as was likely back then!). I have no idea what precise name you = give to that property. OK, this is a ridiculous thing to discuss, perhaps, = given when SHA2 and secp256k1 were standardized :) And given the encoding c= hoices for our BIP341 NUMS (iirc the same as for 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`. Just generate a key and invert your secret k= ey. `P =3D a * G` 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` is fixed, we see `SHA256(G)` is a= lso fixed as a pseudorandom challenge point. The reason for using SHA256 in= stead of, say, picking an arbitary point by committee or using digits of pi= or some other trickery, is that hash outputs are supposed to be random and= so `SHA256(G)` is (assumably) a random ECDLP challenge. This matches the c= lassical definition of ECDLP more tightly: Given an arbitrary point `P`, fi= nd `p` such that `P =3D p * G`. The assumption is that if an attacker can f= actor an honestly-sampled challenge point, they can factor any point. SHA25= 6 is just a stand-in for the "honestly-sampled" part. However, the following two tasks are actually very different: 1. Given G, find scalar=C2=A0`a` such that `a*G =3D lift_x(SHA256(G))`. 2. Given G, find scalar=C2=A0`a` and message `m` such that `a*G =3D lift_x= (SHA256(m))`. In the case of task 1, if we assume SHA256 output is random, then this is m= ore tightly equivalent to ECDLP, because the point we're trying to factor i= s a fixed target, as is the one sampled honestly by the ECDLP security game= . In the case of task 2, the attacker can sample arbitrary messages to create= multiple target points, and the attacker wins if they succeed in 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 the two cases, bec= ause they are different security notions. The first (1) I would call=C2=A0s= ingle-target ECDLP (ST-ECDLP), and the second (2) I would call=C2=A0multi-t= arget ECDLP (MT-ECDLP). It's pretty clear that MT-ECDLP is easier to break, because attackers can m= ake progress against more than one target concurrently, and breaking any on= e is sufficient to win the security game. For example, say I sample 2 different messages `m1` and `m2`, and compute E= CDLP target points=C2=A0`T1 =3D lift_x(SHA256(m1))` and `T2 =3D lift_x(SHA2= 56(m2))`. Then if I sample a random scalar `r` and compute `R =3D r*G`, I h= ave two potential chances of success: `R =3D=3D T1` OR `R =3D=3D T2`. I can= scale up this advantage by generating more targets, `T3`, `T4`, ... and so= on. MT-ECDLP also admits a more efficient basic unit of computation in brute fo= rce attacks (including Grover) by using hashes instead of EC point multipli= cations. If I instead start by picking scalar `t` and fix the target point = `T =3D t*G`, then I can run a brute-force preimage search on SHA256 until I= find `m` such that `SHA256(m) =3D=3D x(T)`. This can also be scaled up usi= ng a multi-target attack [1]. With ST-ECDLP, we have only a single fixed message `m =3D G`, and so the at= tacker can't use those multi-target cheat codes. They can parallelize, use = pollard-rho or Shor or other algorithms, but they have only a single 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 sc= ript like `OP_SHA256 OP_CHECKSIG` as a canary, where any spend of such a sc= ript 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 mor= e tightly equivalent to ECDLP.=C2=A0 - MT-ECDLP is more reflective of how real-world attackers behave on Bitco= in (e.g. with thousands-to-millions of public keys available to attack in p= arallel, and breaking even one is considered unacceptable). I'm slightly leanings towards a construction like Pieter's, featuring ST-EC= DLP, just because I'm not sure what other tricks could be used to potential= ly trigger MT-ECDLP classically or quantumly. We could also engineer a compromise between the two, where we limit the num= ber of targets. For example, define the game like this: Given `G`, find scalar `a` and 32-bit integer=C2=A0`i` such that `a*G =3D l= ift_x(SHA256(G || i))`. Then the adversary can only attack against at most 2^32 unique target point= s, and those targets are fixed forever, for any adversary. This is an easie= r problem than ST-ECDLP, but harder than MT-ECDLP. Maybe call it limited mu= lti-target ECDLP (LMT-ECDLP)? regards, conduition [1]: First, generate a bunch of target points. Sample scalar=C2=A0`t` and c= ompute `T0 =3D t * G`, T1 =3D T0 + T0, and T2 =3D T1 + T1, and T3 =3D T2 + = T2, etc. Why double each point? point doubling is cheaper than addition or = multiplication, and still covers the whole curve. Then we run a multi-targe= t SHA256 preimage search over all targets [x(T0), x(T1), x(T2), x(T3), ...]= . If we have n targets and curve order N, then each message hash has an `n/= N` chance of success. If we find a valid message `m`, such that `SHA256(m) = =3D=3D x(R_i)` for some target index `i`, then we have found `T_i =3D t * 2= **i * G =3D lift_x(SHA256(m))`. On Thursday, August 13th, 2026 at 2:02 AM, waxwing/ AdamISZ wrote: > This tripwire idea is interesting. Basically "canary in consensus". > I agree it's valuable. In the scenario of adversarial actor(s) gaining ac= cess to CQRC first, i.e. no whitehats, only blackhats, obviously nothing to= discuss; touching a NUMS ECDL is the last thing they'll do. So I'm slightl= y worried that the general userbase will not notice that point, instead thi= nking it's a solid defense when it ... depends. >=20 > In the scenario of at least some whitehats, we get wires tripped, or cana= ries singing. Having it in consensus is nice. The blockchain then does its = job of being an unambiguous signal and we can have all the arguments well a= head of time. [1] >=20 > On the other hand, we traditionally design such systems adversarially, ri= ght, so you could argue that an overfocus on this might be suboptimal - it = might be better to do other things. >=20 > (Similar comment applies to the 'smaller group canary' - definitely nothi= ng wrong with it, but it is not in itself a defence unless we strongly beli= eve whitehats, and *active* whitehats at that, are keeping up). An obvious = question to raise: would we consider tripwiring a 192 bit group break of a = similar type (NUMS)? I find that ... plausible? > > The BIP341 NUMS point (which I suggest using in this context) is the po= int whose X coordinate is the SHA256 hash of the generator point G. This gu= arantees that the NUMS point cannot predate G (if it did, it would be possi= ble in theory that secp256k1's designers actually chose G in function of wh= at we call that NUMS point, giving it a DLP known to them). >=20 > w.r.t. 'This guarantees that the NUMS point cannot predate G' yes based o= n SHA2 preimage resistance, but: isn't the real point that we're relying on= SHA-2 not being a naughty function so that you couldn't find G =3D a * B a= nd SHA2(G) =3D b*B for some base B in some feasible computation (sans CQRC = of course, as was likely back then!). I have no idea what precise name you = give to that property. OK, this is a ridiculous thing to discuss, perhaps, = given when SHA2 and secp256k1 were standardized :) And given the encoding c= hoices for our BIP341 NUMS (iirc the same as for 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 :) >=20 > [1] I take Antoine's point that making it consensus means the miners are = involved and there is a non-trivial collusion risk if the stakes are high, = but I can't see how this scenario is *worse* than no tripwire? >=20 > On Sunday, July 5, 2026 at 4:07:33=E2=80=AFPM UTC-6 Antoine Riard wrote: >=20 > > Hi Pieter, > >=20 > > Thanks for the observations. > >=20 > > When I was saying there is a problem with the game theory, > > it's that strikingly, any activation of the tripwire logic > > would rely on a "flag" transaction being mined in the chain > > for the network nodes starting to enforce at the block N or > > N+1 or whatever the EC disabling threshold. > >=20 > > Any "flag" transaction can be itself re-orged out of the chain > > to purely disable the effects of the EC disabling threshold, > > therefore make it null and void as an effect. One might see > > it as a competing race between a group of "sunsetting" users > > and a (majority) coalition of miners in coordination with a > > CRQC adversary, where the latter have an interest and the > > hashrate capabilities to do a tx-withold [0]. > >=20 > > In pure terms of satoshi fee denominated calculus, empirically > > global miners have won an average of $20 B yearly. If we only > > consider that P2PK are going to be frozen by the tripwire effect, > > as for most of them it might be assumed they will never move to > > a safer format, we talk already about 1.7 M of coins or as of > > today valuation $107 B (the information is on the chain and can > > be verified). > >=20 > > That's $107B can "burn" in revenue or income that a CRQC-enabled > > miners coalition to constantly reorg-out the "flag" tx out of the > > chain. In other terms, something like 5 years of income, and I > > kindly do not count all the loss coins that are likely to amount > > to a far bigger "tripwire" neutralization budget. > >=20 > > In the name of what a majority of miners will gracefully let on > > the table an opportunity of massive income ? > >=20 > > Leveraging Shor the exploitation might be even done anonymously > > as the mining process is done. Not even certainty, by who the > > EC-protected coins could be covertly exfiltrated. > >=20 > > That's the most striking problem when you think about the math > > with any "tripwire" approach, or even an "hourglass" one relying > > on a "flag" transaction [1]. I'm ruling out "checkpoints" and > > any other trust-the-dev approach, as that's even worst [2]. > >=20 > > As you're introducing post is resounding, what the miners > > are saying now, there are no guarantees on how they would use > > their hashrate down the road, potentially 10 or 20 years from now. > >=20 > > Beyond, and to answer back your point, I still think you can > > manage an escape hatch of the "tripwire" effect, it's all depends > > how the script tripwire logic is implemented, but if you have > > two OP_SUCCESS of different kinds before your EC CHECKSIG, you > > can always have a "soft-fork" after the "tripwire" to return > > true on the stack, with an EC or hashlock as a success (I agree > > using undefined op_success in a script is not safe at all) [3]. > >=20 > > Best, > > Antoine > > OTS hash: 4bc91d8dee1625f6e78b27c88bced8e405f25ef6d3d8fd59be8016db5b0fb= e66 > >=20 > > [0] See naumenkog's https://www.bitmex.com/blog/txwithhold-smart-contra= cts > > [1] This is sad, as the "hourglass" depending how the parameters are ch= osen > > 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. > >=20 > >=20 > > Le sam. 4 juil. 2026 =C3=A0 13:47, Sjors Provoost = a =C3=A9crit : > >=20 > > >=20 > > >=20 > > > On Fri, Jul 3, 2026, at 23:23, Pieter Wuille wrote: > > >=20 > > > [...] > > >=20 > > > > * Just publishing the DLP in a transaction (e.g. OP_RETURN with a > > > > specific marker). This is smaller than a full transaction input + > > > > signature. > > > > > > > > * Similarly, but publishing in the coinbase, and requiring relay us= ing > > > > 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 > > >=20 > > > [...] > > >=20 > > > > > > > > On Saturday, June 27th, 2026 at 12:33 AM, Anthony Towns > > > > wrote: > > > > > > > >> A slight variant of this approach would be to have a 128 byte valu= e "aRsm", such that P =3D N+a*G, N is the BIP-341 NUMS point, and Rs is a B= IP340 signature of m by P. That would allow the victim of post-quantum thef= t via a key-path spend of a BIP341 NUMS IPK to trigger the tripwire, in add= ition to someone who has direct access to a CRQC. > > > > > > > > Indeed, I had considered something similar, but see above for why I= 'm > > > > not convinced supporting non-cooperative CRQCs is that useful. > > > > > > > > Also, in my view the tripwire isn't really a security feature on it= self > > > > (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 Do= S > > > > protection measures, > > >=20 > > > I whipped something up last weekend: > > > https://github.com/Sjors/bitcoin/pull/121 > > >=20 > > > It seems straightforward, but maybe I missed something: > > > - for test code we use a fake NUMS point, so we can generate "proof" = 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 i= t's as cheap as verifying a transaction signature > > > - mining code includes the proof in a coinbase op_return, until the f= reeze activates > > > - with stratum v2 (and ipc mining clients in general this works out o= f 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 = style header scan to see if the rule activated. Instead the prototype store= s it in a file along with a merkle inclusion proof, which is read when the = node restarts. > > >=20 > > > With this mechanism it doesn't really need to be in the coinbase tran= saction, but that does seem more convenient and miners can censor it anyway= . > > >=20 > > > - Sjors > >=20 > > > -- > > > You received this message because you are subscribed to a topic in th= e Google Groups "Bitcoin Development Mailing List" group. > > > To unsubscribe from this topic, visit https://groups.google.com/d/top= ic/bitcoindev/aWYtPLVPZ3U/unsubscribe. > > > To unsubscribe from this group and all its topics, send an email to b= itcoindev+...@googlegroups.com. > > > To view this discussion visit https://groups.google.com/d/msgid/bitco= indev/002f2395-7d5d-4cb6-852c-e991aa1f0eb3%40app.fastmail.com. >=20 > -- > You received this message because you are subscribed to the Google Groups= "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an= email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit https://groups.google.com/d/msgid/bitcoinde= v/f6d78499-d551-45ea-89b1-2b9cbd52f5can%40googlegroups.com. --=20 You received this message because you are subscribed to the Google Groups "= Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= wftCzgJs2k7H-4R22EOqdOhhXYdFPFhSZhsYHvlzejpJ5emoze0ACgL3rrYiTP-X5QQMpThdRW1= cO7mr9IQvs2C4MHxSD2eu_gPFGv-yZs8%3D%40proton.me. -----------------------2a5b20a8ed0e32c8770c65ee26ad8653 Content-Type: multipart/related;boundary=---------------------5a560aed76b9697937496205678d2a73 -----------------------5a560aed76b9697937496205678d2a73 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
An obvious 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 reasonable as a canary, but consider this: If someone al= ready 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 bac= k to vulnerable addresses, and they might even be right. 192-= bit canaries are vulnerable to classical attack with work approximately 2^9= 6. We should bear in mind the possibility that such a canary could be activ= ated possibly very early, well before Q-day, possibly even in the absence o= f any quantum computers.

Ideally we want a short gap between "192-bit is br= oken" and "256-bit is broken", but not so short as to make the 192-bit cana= ry effectively fungible with a 256-bit canary (because then it's less likel= y to be activated before theft occurs).

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

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

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

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

---------

If we reflect on the requirement that G= =E2=80=8B is fixed, we see SHA256(G)=E2=80=8B is also fixed as= a pseudorandom challenge point. The reason for using SHA256 instead of, sa= y, picking an arbitary point by committee or using digits of pi or some oth= er trickery, is that hash outputs are supposed to be random and so SH= A256(G)=E2=80=8B is (assumably) a random ECDLP challenge. This match= es 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-sampled challenge point, they can factor any point. SHA256 is = just a stand-in for the "honestly-sampled" part.
<= /span>
However, the following two tasks are actually very different:
  1. Given G, find scalar a=E2=80=8B such th= at 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 lift_x(SHA2= 56(m))=E2=80=8B.

In the case of t= ask 1, if we assume SHA256 output is random, then this is more tightly equi= valent to 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 message= s to create multiple target points, and the attacker wins if they su= cceed in factoring any of them. The attacker can attack all those target po= ints concurrently if they want, and they get a speedup from doing so.
=

So I believe it is worth disambiguating canaries betwee= n the two cases, because they are different security notions. The first (1)= I would call single-target 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 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 T1 = =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 par= allelize, use pollard-rho or Shor or other algorithms, but they have only a= single target point that they must break to win the game.

The method Pieter suggested using for the canary construction is e= quivalent to single-target ECDLP.

I've hear= d others (e.g. Tadge in this thread= ) previously suggest using a script like OP_SHA256 OP_CHECKSIG= =E2=80=8B as a canary, where any spend of such a script would trigger the c= anary. 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. 
    • <= /ul>
  • MT-ECDLP is more r= eflective of how real-world attackers behave on Bitcoin (e.g. with thousand= s-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 Pi= eter's, featuring ST-ECDLP, just because I'm not sure what other tricks cou= ld be used to potentially trigger MT-ECDLP classically or quantumly.
<= /div>

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 integer i=E2=80=8B=E2=80=8B such that a*G =3D lift_x(SHA256(G || i))=E2=80=8B=E2=80=8B.

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


regards,
conduition


[1]: Fir= st, generate a bunch of target points. Sample scalar t=E2= =80=8B and compute T0 =3D t * G=E2=80=8B, T1 =3D T0 + T0= , and T2 =3D T1 + T1, and T3 =3D T2 + T2=E2=80=8B, etc. Why double each poi= nt? point doubling is cheaper than addition or multiplication, and still co= vers the whole curve. Then we run a multi-target SHA256 preimage search ove= r all targets [x(T0), x(T1), x(T2), x(T3), ...]=E2=80=8B. If we have n=E2= =80=8B targets and curve order N=E2=80=8B, then each message hash has an n/N=E2=80=8B=E2=80=8B chance of success. If we find a valid mess= age 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.
<= br>

=

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

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

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

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

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

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

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

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

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

Thanks for the observatio= ns.

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 start= ing to enforce at the block N or
N+1 or whatever the EC disabling thresh= old.

Any "flag" transaction can be itself re-orged out of the chain<= br>to purely disable the effects of the EC disabling threshold,
therefor= e make it null and void as an effect. One might see
it as a competing ra= ce between a group of "sunsetting" users
and a (majority) coalition of m= iners in coordination with a
CRQC adversary, where the latter have an in= terest and the
hashrate capabilities to do a tx-withold [0].

In p= ure 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 t= he 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 o= f income, and I
kindly do not count all the loss coins that are likely t= o amount
to a far bigger "tripwire" neutralization budget.

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

Leveraging Shor the exploitation migh= t be even done anonymously
as the mining process is done. Not even certa= inty, by who the
EC-protected coins could be covertly exfiltrated.
That's the most striking problem when you think about the math
with an= y "tripwire" approach, or even an "hourglass" one relying
on a "flag" tr= ansaction [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 re= sounding, 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 dependshow the script tripwire logic is implemented, but if you have
two OP_SU= CCESS of different kinds before your EC CHECKSIG, you
can always have a = "soft-fork" after the "tripwire" to return
true on the stack, with an E= C or hashlock as a success (I agree
using undefined op_success in a scri= pt is not safe at all) [3].

Best,
Antoine
OTS hash: 4bc91d8de= e1625f6e78b27c88bced8e405f25ef6d3d8fd59be8016db5b0fbe66

[0] See naum= enkog's htt= ps://www.bitmex.com/blog/txwithhold-smart-contracts
[1] This is sad,= as the "hourglass" depending how the parameters are chosen
was a more a= cceptable trade-off than pure sunsetting.
[2] Given the amounts at stake= to sunset, as a group of developers you
would just paint yourself a tar= get, there are more even funds at stake
that Satoshi herself / himself i= s assumed to have.
[3] There is no security proof in BIP341 on the unfor= geability of the
NUMS point, if it binds in the ROM or whatever.
Le sam. 4 juil. 2026 =C3=A0 13:47, Sjors Provoost = <sj...@sprovoost.nl> a =C3=A9crit :=


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

[...]

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

[...]

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

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

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

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

- Sjors

--
You received this message because you are subscribed to a topic in the Goog= le Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this topic, visit https://groups.googl= e.com/d/topic/bitcoindev/aWYtPLVPZ3U/unsubscribe.
To unsubscribe from this group and all its topics, send an email to bitcoindev+...@googlegroups.= com.
To view this discussion visit https://groups.google.com/d/msgid/bit= coindev/002f2395-7d5d-4cb6-852c-e991aa1f0eb3%40app.fastmail.com.

--
You received this message because you are subscribed to the Google Groups "= Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+u= nsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/f6d78499-d551-45ea-89b= 1-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/bitcoindev/wftCzg= Js2k7H-4R22EOqdOhhXYdFPFhSZhsYHvlzejpJ5emoze0ACgL3rrYiTP-X5QQMpThdRW1cO7mr9= IQvs2C4MHxSD2eu_gPFGv-yZs8%3D%40proton.me.
-----------------------5a560aed76b9697937496205678d2a73-- -----------------------2a5b20a8ed0e32c8770c65ee26ad8653-- -----------------------ae6ef00487c0477d15f5c07e472339a0 Content-Type: application/pgp-keys; filename="publickey - conduition@proton.me - 0x474891AD.asc"; name="publickey - conduition@proton.me - 0x474891AD.asc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="publickey - conduition@proton.me - 0x474891AD.asc"; name="publickey - conduition@proton.me - 0x474891AD.asc" LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgp4ak1FWkRub0tSWUpLd1lCQkFI YVJ3OEJBUWRBcnBZYWFjZDgwcXdocmNaQW9VbW9NSHNWS21iZWlPZUEKcFhXbk1ybFdPZkxOSzJO dmJtUjFhWFJwYjI1QWNISnZkRzl1TG0xbElEeGpiMjVrZFdsMGFXOXVRSEJ5CmIzUnZiaTV0WlQ3 Q2pBUVFGZ29BUGdXQ1pEbm9LUVFMQ1FjSUNaQjRLV3p0aFBhenhRTVZDQW9FRmdBQwpBUUlaQVFL YkF3SWVBUlloQkVkSWthMENNdHJMZGcxM2EzZ3BiTzJFOXJQRkFBQTZhQUVBM1RmNHdqSVoKYnox K0diS0h4K09WQytNUXlVdi84RStoWUpjTE5QZnA0NEFBLzNiak5OTXN4WHdJTGZEM0xManNVVWFo CitBV2JyblVjVUFqQ2R1d3hUT01LempnRVpEbm9LUklLS3dZQkJBR1hWUUVGQVFFSFFDSXYxZW5J MU5MbAo3Zm55RzlVWk1wQ3ZsdG5vc0JrTmhQUVZxT3BXL3RKSkF3RUlCOEo0QkJnV0NBQXFCWUpr T2VncENaQjQKS1d6dGhQYXp4UUtiREJZaEJFZElrYTBDTXRyTGRnMTNhM2dwYk8yRTlyUEZBQUFR TFFEL2NCR2kwUDdwCkZTTkl2N1B6OVpkeUNVQjhzTy90dWZkV3NjQkNZK2ZMYTV3QkFNK0hTL3Jp S014RGt0TkhLakRGc2EvUgpEVDFxUGNBYXZCaXc2dDZ4Ti9jRgo9Y3d5eAotLS0tLUVORCBQR1Ag UFVCTElDIEtFWSBCTE9DSy0tLS0tCg== -----------------------ae6ef00487c0477d15f5c07e472339a0-- --------02c36632dd4a6c75637f2e0340d62ee892cc28c6d4fdffad1e0961d9291fb793 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wrsEARYKAG0Fgmp/X1gJEHgpbO2E9rPFRRQAAAAAABwAIHNhbHRAbm90YXRp b25zLm9wZW5wZ3Bqcy5vcmfSdP53fem/8aEkRJNaYnczo51BXHWF1Nssymbx e/P5ghYhBEdIka0CMtrLdg13a3gpbO2E9rPFAADL/wD+Pn5bb4NJeo4ePJI6 jW9EGt6N6KNas3INQccWGtkPDwIA/3NbqF1rsAWJlD9v9IuC3qDLgVVGyR9H Ucl/es4tix4C =MGH0 -----END PGP SIGNATURE----- --------02c36632dd4a6c75637f2e0340d62ee892cc28c6d4fdffad1e0961d9291fb793--