From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 26 Jun 2026 11:23:04 -0700 Received: from mail-ot1-f55.google.com ([209.85.210.55]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wdBCh-0006mj-Mo for bitcoindev@gnusha.org; Fri, 26 Jun 2026 11:23:04 -0700 Received: by mail-ot1-f55.google.com with SMTP id 46e09a7af769-7e93b1cc222sf1565517a34.0 for ; Fri, 26 Jun 2026 11:23:03 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1782498177; cv=pass; d=google.com; s=arc-20260327; b=JImDNLvITtW5GB0QncaUb/HHNkHgSr3bGpDJqx5dvOgYWv3DArqHj9tTWu0gpSNIf/ 1pFhXmWxdufurpo8Bn3pJB04i10Wsm4nUmWWXU7I+RfpvIIqnf8Lc/AqtaRnoDYHqWNc 5xVZrZAwRHDyLNJh3qvutDMip+813qxkYezLDP8seCG06+e7YPiu8JsidGeuV9iIcXst EjUHN2k1WOtRDfKUcodVMF7PsimpF5nj4wPS+yTo6t53aAUmyL2JOgID4X46PptBNGcl GexzjP7a+rJSF4YyVlGLI/qNJ9XzpWV9lQc+/EVL6F8iTK9lPc5RvQajuQFSYb+1gYHL kPJQ== 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=exDXC6QOtlocuyOdWkX/MLFF95WdFpb28Mekqv3RGO8=; fh=9C4Vzu7cI+oEKXiv4jsHNjJ1uWAV1aJ8H8WYxOMEsXQ=; b=nsoZIqL2xPx6WWyGDq5b+oVKEowACxb7x33E32w1nGvVcNH3b+NaoxZJIxnE810zWz Az1RZT3EYJFwiZ7mL+PupYtMDYGUnXMimGIDENBuaxdZz64gHiVOXTGSzK7mTUnXxFjI jlNKs0ZOs1lObip6W8ULT1viWPtUnO2VzTRHiCuUHgG6nPe5hg0aYo0W/qZsjpkWaE8A XDzd6mpY7ije45SKpopiJxV+hchbPVBckHIeNuqnO2UagiWxIIkPjJBIQElJWx7r6sHh q43aSqL6Tk45JCWqo4FhFDI5TKS3HL/b6ZQ8nO+9CaUQGRSCW5I0L0D4FpR+ucFuQim1 2yaA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=swb3i7s62zhe5ack5qmebbn7fy.protonmail header.b=VziFNHLc; spf=pass (google.com: domain of conduition@proton.me designates 109.224.244.25 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=1782498177; x=1783102977; 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:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:from:to:cc:subject:date:message-id:reply-to; bh=exDXC6QOtlocuyOdWkX/MLFF95WdFpb28Mekqv3RGO8=; b=SBx4CUd7xlIPiN7JTxDp/Nx8xq91BQZ/7KgrPuFDThN7Yc8peFTLfVJt9zAYO+qswg 9Tcw2FvVdIVngJEQ4xHGaIUKw0cX7+FCBEf+owXNPuw3bHXsCqBQr5mWuqbWmbR6zhLF FUEh7RhybtY24Z0n34jceiEoxtpVnyPx24I+MddIOxVZeYOmv7XPMvLKu7AdtUjl3Nk3 4YUTneucXJ3GT2gm1qNk4bjWj6TpZVri8dcL5ParUKyFqTaBWFLJtulbXXdGAfkZE8Bq BbAlbYk0xTa0uG84G6IhjBGd9v5p4t1hw1sD7bCY141gyGXNX3bW+e+cxfJxoBeUepuY 6xCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782498177; x=1783102977; 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: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; bh=exDXC6QOtlocuyOdWkX/MLFF95WdFpb28Mekqv3RGO8=; b=YvII+vdTX08gkz32bTUc6au/b05Qb/avlkD3iAI19xHUWP+UKLzHpaIpMzByb2Jq6D nHymQXoDs5PjRHU2lXDVQzUO0Q/A70Ay/9y1gp830HsGmssdCgJ2IfZUMsfXIdaTn81T YS/mCNVvZl1FF1/BjsfJTCeoRKAwqtXiA1AX4fsJ3emCroCCXNowBAFaGJYVU+aq9JyU S9B5aQr57UWpU3GJym6BNYIS7mk6Y9qiaHISFZ4GdwbAcnXBI4/qFzvPEzNidb1QuYev PUoTJxR29x9PmEpZ+8sgDQbMtu8j/5r95P/QS8sJF1D9kHB1px/AABCltoQvRaRht7mT QPKw== X-Forwarded-Encrypted: i=2; AFNElJ9SkEas23RDDytLCUV5SshMBkD+Kf/akP437l4fInSLKgYCUPXyvPmeycqUkZbeu1Q4DDdz8kVOWFsE@gnusha.org X-Gm-Message-State: AOJu0YxDCO0YEok+kp0Kcd2YdQmMPz/hV0Rm70fxEtR4UnVgsWXy4MoX zdhfqAdFmxXLYtewij2HLrfFIN8u4KMJp8G0thvjNbshsk8TDqIFHc2L X-Received: by 2002:a05:6820:6ae3:b0:6a1:460a:3bd1 with SMTP id 006d021491bc7-6a1460a404fmr2142507eaf.0.1782498177491; Fri, 26 Jun 2026 11:22:57 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AX0PUUfAWHQO0E8uS7baR4vwTBQdKfBV0XH/xbgOFk6X13EgOg==" Received: by 2002:a05:6871:c7f1:b0:448:3eb1:dba1 with SMTP id 586e51a60fabf-4483eb1de57ls293085fac.1.-pod-prod-08-us; Fri, 26 Jun 2026 11:22:52 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ+QN9q7O9AoAjiwP4p9JjNdbHAUtvMSiSTwQeciQzl5/7mcKr1OkDSqh/xE1x/bJbYx/6LQjGRzBNQM@googlegroups.com X-Received: by 2002:a05:6808:2385:b0:48f:d469:d035 with SMTP id 5614622812f47-4921851a5a2mr6360327b6e.42.1782498172720; Fri, 26 Jun 2026 11:22:52 -0700 (PDT) Received: by 2002:a05:620a:e1b:b0:8f9:4d19:af67 with SMTP id af79cd13be357-92a546a07d0ms85a; Fri, 26 Jun 2026 11:20:38 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ/ye5kF82l2FduXhezlG1220E42mDaMR5ggcfMtPcNoT1tg7YbgC/CQN5LpBlkWKQzqqqXYJAWMsGvy@googlegroups.com X-Received: by 2002:a05:620a:198b:b0:915:9015:3411 with SMTP id af79cd13be357-9293e9cbd50mr1228638985a.58.1782498035983; Fri, 26 Jun 2026 11:20:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1782498035; cv=none; d=google.com; s=arc-20260327; b=mOMjdy4/h7CG0K8NW66gZgHOxSIbgv5I7+TfYdjCoDCmdhE5sgsb4KFiInMtOBP4Y5 Hdj4MaRsltWvDjilzcMyg2IBtNwKbUnsNDaitFBmGqD/faYF+9QcVVCkgxx241agndcQ b4A03KZPhT1yq6WQWLK0t4PjljOWqMVmaGaY5mLANdp5jcj5fyTFL87WZV6XtowsnQ4i FuJgODn+n409TdFV7aPWNCPk/28bOvlo9ZNnkEm7FeswGGVc4uYIFEaxw7IztRQDQQsU uhiYRtikON4V8ywkG93imDrUu4cSvUrRbTnNHzSc+QXZtvKhPHvzzJnp8D3WsG7504lU rDmQ== 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=tqbPPo+e1Pq/OKPydSbGQ2jAFaSEX88r/tzp9fRBsNY=; fh=Sb4KXLEmtAbvbUPnPmX4O3XA75/ua5x9Ywsy8RIWss0=; b=nrKvGkookN9KFU0uyFIqK10jwy9Hnc9IvHubntAqW+aqWJUVawcWhPULVppEyZRnsC tFem7DfZBOcngOSyT9ZBALmNH+Bei+RQUNCs5yl25P5VtJWDQ1zYxiBbWbNPWRRps2mf bBmvYh1WAv4i4IGVLrZSrQclPV+jwljcCju8IJd9ezt8q2IfNqZvjmJisRTnOBGHUlsG YdWqHFD0ObWXl86X2lLHdLtkbiLDXlwsLLkmQKCxI5durGweSeQ5E6zMVATRBpDyNxKx TvdSwT/RkehKvNIuVyFORJ3OzRfGJH9QSQB9kwcSsXqPV2B07QgdhRjXqSUcB1sEj3dO 54mQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=swb3i7s62zhe5ack5qmebbn7fy.protonmail header.b=VziFNHLc; spf=pass (google.com: domain of conduition@proton.me designates 109.224.244.25 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me Received: from mail-24425.protonmail.ch (mail-24425.protonmail.ch. [109.224.244.25]) by gmr-mx.google.com with ESMTPS id af79cd13be357-925fa17e282si46966885a.0.2026.06.26.11.20.35 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 26 Jun 2026 11:20:35 -0700 (PDT) Received-SPF: pass (google.com: domain of conduition@proton.me designates 109.224.244.25 as permitted sender) client-ip=109.224.244.25; Date: Fri, 26 Jun 2026 18:20:26 +0000 To: Pieter Wuille From: "'conduition' via Bitcoin Development Mailing List" Cc: Nagaev Boris , Bitcoin Development Mailing List Subject: Re: [bitcoindev] Giving teeth to expected EC disabling: P2XX(-T)(-ML) Message-ID: In-Reply-To: References: Feedback-ID: 72003692:user:proton X-Pm-Message-ID: bd796c55cd1e696cc39c6ea0cdabdef54aa0db70 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------a6b1809e60e640a4a96616d381fe0bb4d999ad505b08b3d42aa7ae9076a22313"; 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=swb3i7s62zhe5ack5qmebbn7fy.protonmail header.b=VziFNHLc; spf=pass (google.com: domain of conduition@proton.me designates 109.224.244.25 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me X-Original-From: conduition Reply-To: conduition Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: 2.1 (++) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------a6b1809e60e640a4a96616d381fe0bb4d999ad505b08b3d42aa7ae9076a22313 Content-Type: multipart/mixed;boundary=---------------------f01605c73e20f0aba2f1786ae9d32a59 -----------------------f01605c73e20f0aba2f1786ae9d32a59 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Hi Pieter, Thanks for voicing this, I'm generally very supporting of the tripwire idea= . It's an easy win for any PQ output type. I have a few comments on the specifics. > Specifically, as part of the softfork definition, a NUMS point is picked.= Whenever a transaction is mined whose input contains a successful " = OP_CHECKSIG", EC opcodes/paths are disabled within the new output type, as = of the next block. Mining an on-chain spend isn't the only option. The signature by (or discre= te log of) the NUMS point is itself a sufficient and succinct proof that EC= spending ought to be disabled. We don't need a trustless "honeypot"/"rewar= d"/"bounty" for the CRQC, since we're already assuming the CRQC is cooperat= ive. We don't need the "tripwire proof" to be included on-chain except for = posterity (i.e. nodes bootstrapping after Q-day, to know when to enact the = new consensus rules retroactively). All a validator node today needs is to = see the signature/discrete log of the NUMS point, anywhere, at any time, to= know that EC spending ought to be disabled immediately. It could be in an OP_RETURN, it could be a new field in a block, it could b= e a simple P2P message or just seeing a TX containing the tripwire proof ap= pear in the mempool. Maybe requiring the tripwire proof to be mined is simp= le to implement for validators, but relying on that alone runs the risk of = miners censoring or purposefully delaying the inclusion of the tripwire pro= of in a block. So it might be worth the extra complexity engineering of a m= ore highly reactive solution. I'm not sure what the best option here is yet, but I just wanted to point o= ut the tripwire doesn't have to be a UTXO spend, and we should discuss more= options and their trade-offs. > Miner Lockdown (P2XX-ML): allow a hashrate majority/threshold to trigger = the disabling, allowing a faster reaction time to urgent CRQC threats. I'll echo the others' concerns here about early activation, and add that mi= ners may actually be incentivized to trigger this activation early if given= the chance, since doing so will massively pump their fee revenue (though p= erhaps at a cost to the price of Bitcoin itself). This could be more of a c= oncern as the subsidy drops lower and miners with sunk cost seek to recoup = their up-front hardware investment. Generally I think this is a good idea though, and might be worth the risk e= specially because, as you stated, early activation will not confiscate any = meaningful amount of coins. But it should also be possible for nodes to rej= ect a bad-faith early activation. The more important question is, how do you propose to technically achieve t= his? How does "majority hashpower" enact the disabling? My fear is that the= reaction time will actually be very slow, because for us to measure "major= ity hashpower" we typically measure this over an epoch of many blocks. Othe= rwise a random minority miner could luck their way into a few blocks that s= ignal for EC disabling, and so trigger the fork early. The activation window would need to be spread out, and the further it is sp= read out the less time miners have to react, if they even react at all. > I agree with Antoine that it necessarily must disable all usage of EC ins= ide the new output type, so that includes taproot key path spending (if pre= sent), and making any execution of an OP_CHECK* opcode with a non-empty sig= nature for an EC pubkey cause the transaction to be invalid. Anything else = falls short of the goal of making it possible for users to keep sharing pub= lic keys. This should be the case for all disabling, whether through Tripwi= re, Miner Lockdown, or a future softfork. This will confiscate coins held in hybrid scripts and in multisigs whose pa= rties use different sig-schemes, e.g. CHECKSIG CHEC= KSIG. I would suggest to enforce the disabling by running spend validation as nor= mal, but failing at the end if EC-checksig operations have occurred without= any PQ-checksig ops. This also implicitly disables P2TR-style key-spending= and Boris' EC recovery scheme in P2TRH and P2MR, because such spends would= n't involve a PQ signature. > My thinking is that hybrid signature schemes, if desired, should be dealt= with at the opcode level, and not the script level. That is, there would b= e (only) an OP_CHECKHYBRIDECSQISIGN opcode, not an expectation to use both = OP_CHECKSIG and OP_CHECKSQISIGN. > > Practically, my thinking is that due to the low cryptographic assumptions= needed for hash-based schemes, those wouldn't need hybridization with EC (= though the statefulness of some variants is worrying). In the SHRINCS proposal we elect not to introduce a hybrid EC+PQ signature = scheme, for a few reasons: - Complexity & fragility. A hybrid scheme necessitates a brand new Schnorr = signature scheme because combiners like Bird-of-Prey don't use Schnorr as a= black-box. Expands the scope of implementation a lot. - Lack of value. Strong unforgability (one of the main selling points of hy= bridization) is not security-critical because witnesses don't affect TXIDs = anymore. At best a hybrid scheme would provide a minor ~5%-10% improvement = in witness size over a naive scripting approach, and this is still less eff= icient than keeping keys compartmentalized in isolated spending paths. - Redundancy. Deploying SHRINCS as a standalone opcode is already needed fo= r post-Q-day spending, so taking that opcode as a-given, users will already= have access to hybridization techniques by using hybrid scripts. - Security. Standalone SHRINCS uses fewer cryptographic assumptions than BI= P340. Adding Schnorr hybridization thus hedges only against implementation = flaws or state reuse, both of which can be effectively mitigated against. We thus concluded that deploying a hybrid scheme doesn't seem to offer much= unique value, and comes at the expense of great risk and effort in adding = a new checksig algorithm, which very few people will use anyway since they = have much cheaper options (separate leaf scripts). I suspect hybrid script users will exist, but will likely be limited to maj= or custodians, high-security vaults, and other such address-reusers. Dedica= ted hybrid signature algorithms may be desirable in the future with other s= ignature schemes, but I doubt we'll be doing this with SHRINCS anytime soon= . regards, conduition On Friday, June 26th, 2026 at 8:14 AM, Pieter Wuille wrote: > Hi Boris, > > See responses inline below. > > On Friday, June 26th, 2026 at 5:41 AM, Nagaev Boris wrote: > > > For Miner Lockdown, I see a potential false-positive activation. A larg= e > > classical theft may happen, be misinterpreted as a CRQC event, and mine= rs > > may lock the EC path with the best intentions, but it turns out to be a > > false alarm. Shouldn't there be a mechanism for reactivation in this ca= se? > > We have historical examples of bugs causing large-scale or initially > > mysterious thefts: Milk Sad, Android SecureRandom 2013, and the LuBian > > 2020 theft. A similar event in the future could be confused with Q-day, > > and miners could push the button. > > I agree that's a concern, but of course, if this happens, no coins are > lost, just inefficient to access. As Sjors mentions, it's possible for > users to move back to P2TR temporarily, but that of course goes counter t= o > the CRQC-protection goal, and if it happens at scale, chain capacity > problems may cause chaos. > > Adding the ability to revert is a possibility, but I'm not sure it's all > that much better than realizing there is also the possibility of adding a > new P2TRv3 / P2MRv2 / ... that is in a pre-lockdown state? > > > Can you elaborate on the scope of EC disabling, please? Does it disable > > only the main EC path (e.g. key spend in the case of Taproot v2) or all= EC > > involving paths? > > I agree with Antoine that it necessarily must disable all usage of EC > inside the new output type, so that includes taproot key path spending (i= f > present), and making any execution of an OP_CHECK* opcode with a non-empt= y > signature for an EC pubkey cause the transaction to be invalid. Anything > else falls short of the goal of making it possible for users to keep > sharing public keys. This should be the case for all disabling, whether > through Tripwire, Miner Lockdown, or a future softfork. > > > What will happen to scripts using something else in addition to EC? Som= e > > useful constructions may include an EC opcode, e.g. hybrid EC-PQ > > signatures or HTLCs. Maybe it makes sense to disable the main spending = path > > and keep hash-protected supplementary paths available? > > My thinking is that hybrid signature schemes, if desired, should be dealt > with at the opcode level, and not the script level. That is, there would = be > (only) an OP_CHECKHYBRIDECSQISIGN opcode, not an expectation to use both > OP_CHECKSIG and OP_CHECKSQISIGN. My reason for this is that I think the > question of what level of security is appropriate (i.e., whether schemes > should be protected with a layer of EC hybridity) should be a consensus > decision, not an individual one. > > Thinking about it, maybe that means it makes sense to completely separate > PQC scripts and (pure-)EC scripts at the script leaf level, by having > separate script leaf versions for them. That rules out some potentially > useful ways of using conditionals that have PQC and pure-EC branches, but > those do seem pretty error prone (as mixing the two within one execution > trace would be unusable post EC-disabling). > > Practically, my thinking is that due to the low cryptographic assumptions > needed for hash-based schemes, those wouldn't need hybridization with EC > (though the statefulness of some variants is worrying). I don't think > schemes relying on other assumptions feel ready in terms of confidence fo= r > adding to Bitcoin to me, but that can change. > > Cheers, > > -- > Pieter > > -- > 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/A54QKCjvV0Tnk26mHFZrbAKPHdYh6Ol1XWTetB3y1skuSaoLtBZnvNlYD2hSqQtp6oYt85rqv= K4w-JMsDJOm3nPrYgkN94E9jlxxCPZsKZw%3D%40wuille.net. > --=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/= Jj-Ozzq4OMo2XaP_Drftu_n7gmEHWC_Dw2bToW9hI8vId-BN3y4hmQSaHh5JY1xTonTyBWKa17v= zNH4GMYTkM-CiFw5ZNwRFATdc3OE_lLk%3D%40proton.me. -----------------------f01605c73e20f0aba2f1786ae9d32a59 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== -----------------------f01605c73e20f0aba2f1786ae9d32a59-- --------a6b1809e60e640a4a96616d381fe0bb4d999ad505b08b3d42aa7ae9076a22313 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wrsEARYKAG0Fgmo+wtwJEHgpbO2E9rPFRRQAAAAAABwAIHNhbHRAbm90YXRp b25zLm9wZW5wZ3Bqcy5vcmc2/rvbqssy8qZl8fXr7/fVmfizs2Cb4LV/B9O0 vKmg3hYhBEdIka0CMtrLdg13a3gpbO2E9rPFAAB2TQD/bYw7wDgH1/y6a9TU qsXdC9gDq4krVfmMfxm7u/BdvIEBAMQhwT3T7ARAJNzYYchpiSpgGxs4Y8oE xojy5AcsKh4M =17Cu -----END PGP SIGNATURE----- --------a6b1809e60e640a4a96616d381fe0bb4d999ad505b08b3d42aa7ae9076a22313--