From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 10 Apr 2026 10:47:18 -0700 Received: from mail-oa1-f60.google.com ([209.85.160.60]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wBFws-00005E-4k for bitcoindev@gnusha.org; Fri, 10 Apr 2026 10:47:18 -0700 Received: by mail-oa1-f60.google.com with SMTP id 586e51a60fabf-415583a6862sf3338184fac.1 for ; Fri, 10 Apr 2026 10:47:17 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1775843232; cv=pass; d=google.com; s=arc-20240605; b=hy6Y5qyn6bJimDzHd9mxPMrimmRDOPl2xI2PdqUy3MU9MaOK1/4Tgt6YubWnCclFrt EgDaI9HVxMFLgQ7zkA6VJkC1vJ82V/12HfknVLN7fEFTo2vdvl0AHicY++va31bMUJnO tkHPE6l+f3Fidyr4Qf2Mdb6w+rkgFBSMN3uc+ZIIiYRZ73Dmlef6Vx8W4P9QV4BO6Fgi SU8W1X1rrIacVyquvHiXVlVPgO7j2ui2OY/e7t4fmLLWuNGLnAO8r+vvd0ZijpPjoaSO cSi4us0qYoQAL3mkkJI71Jt4h7aKYaTVtZJSB4Pzz7oNJsEUArCaqdEQrAGv7OBENStR s/TQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; 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=Z0NPEw4L5e44VI0obz/TMYSoD09jfmYFeOtnE8lX32c=; fh=d5pAi4Jt2aE0rjvWPgR+ZcV3rO2aMNDOvQCtkomrg3M=; b=bVbw3z3Mo4xZpnowKrxnHGa/9g4y+CKpzGwyFRoGqTEhEEykWeYo618eD4AJCIhOSr 7QJbMZnxwCjERGijmIjG3s7NvstOWDFLKOWxbuOTG4TcCaraEJEVl5yX846kWxzRUTTx 8yhm5HdCDOVJjvsvGopYu84hDEJqKvP0DlFtcXDTWyGb9L9xmpLNorMap7nbctnNkrfv iSEzn8+27YpeGcwsvaZVIUmfpx8PCo4kYmIQUH5pKBvacnxEGEKWNc7z3L0HI90wf/Pb bbSa4Gdym++fUB66Y8HI9px/hHi8wfq988Yy18ZM6b2Xkd0sk43bAx7TZwx2wkap2Oht tXQw==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=btPwn+VC; spf=pass (google.com: domain of conduition@proton.me designates 185.70.43.167 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=1775843232; x=1776448032; 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=Z0NPEw4L5e44VI0obz/TMYSoD09jfmYFeOtnE8lX32c=; b=tbcia/H3MI/X4aSmuCa6dShYmNBLh5nbDaernRoWTnflXv7pVOQMV/+Ypv+FLWPpi5 iIgQG7KLsdCuCYCi2NVb9NDZiWB2pRl1qxe5o6rhCjFRfdKlQgoC1fw/+8TAty9ntizA eZMTxGTvLzUSD/tiInwsX4YaNztr1d9mergceu+P1hyruUUaXT4Y4VP4lNmu9iTHNJgw VII+QRBtMTdCYzFvXEyosSOk0QUqDAnsCFu4bN2cHI3T7dIlqQS9+iRdyHvdaSx7HGOT Y3mZNR51IJOFEqmSlGE7PiyUUn/9y1vSAfO7D8PfIwrvWWVrYFmetKOjPXpt+6cymjEZ iSbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775843232; x=1776448032; 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=Z0NPEw4L5e44VI0obz/TMYSoD09jfmYFeOtnE8lX32c=; b=FWSfV2Ay3BvVmjCEP5Q7FNKKXHxYA/YLrSztrZuEnVp9KX6nGpOZGxfsXR4KlO2Lky Xtgu4ERAPGmZa0ydyjVi+EOF4B4Jmrqrvc1rHGhRDYqQEVKSCrteaSP8VFG+wqUImMq+ HkgEtPFPaXQjtJflzdjJtHUDhGFoj0N0X08BDVfK+Y6zjP3QDJNo0UGS3CXrxKaPEDUp Q6o4TJbQtt96k8n15k2h12uqvkcyA2td6/1lyo+AfZBZo3wiLGV0NffwrvyQ0lhAOnxR FRWQVHvKG8EEMaGIAjoZm3nTQhJzFo/2wkB6uegI/5n11oTqw22cre5DaFDhkikxE7kH nxcQ== X-Forwarded-Encrypted: i=2; AJvYcCUKHdubYj8HbxkzmY7xHK94Ja8LGl/PuUiIozq36PVef9LrMv14H8s96I828ybTMrNR5lwvn26ZUUvn@gnusha.org X-Gm-Message-State: AOJu0Yz6+1AQDV70ERq53b+bp5TzqJLbIuprMCYeh0lTYJOjMWJjWNWd IAuOpqiGY1NmjPwPjkEEdX6nsoD22H8j9Gxh7b8/px4cfEm/Cd/GT+UR X-Received: by 2002:a05:6870:b9b:b0:417:3161:bfcc with SMTP id 586e51a60fabf-423e1b7766emr2071966fac.5.1775843231907; Fri, 10 Apr 2026 10:47:11 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AYAyTiIeWZ7isPsKxwE7glxIKyzyDIW4lclMcNxr7DuG38T4Rw==" Received: by 2002:a05:6870:830a:b0:423:73f9:2b3 with SMTP id 586e51a60fabf-4239ec1fbe4ls1176235fac.1.-pod-prod-00-us-canary; Fri, 10 Apr 2026 10:47:07 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCX9nxYHxIbYfgZg7Vc1idWLiI/IjnKFlGCRcuvsWtOpGvkFN26xDK0lsOhkml1BA9gHQZXQ3mgEdRDY@googlegroups.com X-Received: by 2002:a05:6808:3a13:b0:467:697:7bbf with SMTP id 5614622812f47-478b37b79d3mr1787565b6e.0.1775843227366; Fri, 10 Apr 2026 10:47:07 -0700 (PDT) Received: by 2002:a05:600c:529b:b0:488:965a:b7a8 with SMTP id 5b1f17b1804b1-488cf323ff6ms5e9; Fri, 10 Apr 2026 10:03:32 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCXhWlM7J9Nl96ywTl7cvgsHq+WNYTXfO37JqsijbQ5ZSX7JdCxgnu71Jc42HcDBXarvDvHjr2IsCZEQ@googlegroups.com X-Received: by 2002:a05:600c:c088:b0:488:a98b:b891 with SMTP id 5b1f17b1804b1-488d67bf75amr38396545e9.3.1775840610879; Fri, 10 Apr 2026 10:03:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1775840610; cv=none; d=google.com; s=arc-20240605; b=DbuccBKxav0gGpFs5VW2npvnagNaflf3uTTLgd1yHcqtsVOFZ4McM+WayE09ABFMHI onbQe5/CrrghBv4RHQ1JQTUL/r+Y2xq7P5qQlsPfjbTZPtOfsSNBcJ/84joYh7LEhFCU leh2/RXoBolrwq0N7/be+/z44RnAD8s1h9gBjGOiTythGgv84CoR8+I8MelNHZD65eW4 i8HY3V9SEBOGDi+8bKeLHxF2umA3rzCfj3vgTk0s2Ktvwe2MqOd5gfeyyZem14Uz7yT+ SuHyRA/fiS9Iye0YNX/O/2EWWcTE/mYxLND7KkZra1Y9TsZFqyPvoeHvHXmAjzgz5hSk jtqg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:dkim-signature; bh=ggUjOi4cuR2M3LCu2KyBKbgOBgOzLqGAJTMgRWVe6Rc=; fh=utekUrWgarsMKG1Ve1Ub6jerzb4Ft12nIPb5EnRSce8=; b=iLhUb5hPPQ/VZhmrEmwtoNSXbWRWbueSSM19JkU2dVH9RCAe43s7E/KcXzdK0QSyod KbyUCwUdLFw0xzGcpjY743JzGr2JJBjDpFibzgwxH3DQ79jsmpdOWNEA32kDZa5q20df 31sxI+e0hq/wmGsg7y7A/adRwd6T46ypk111j0bBAD7LrjcdBO+wuPWjxeDhQqy4Mt/3 B12mKvY0DHWFSx0/FRf6V/LyzsiO985gEr5g3552xOKkaKBE/T5jxen9fOPhPCporkRI 6HMMjYq1Zaxt+HbfmSMXchMoUUnVVq/kLI4U9/sptAtVIAEv0tFyYeikCaD5/4N1vycn x8Nw==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=btPwn+VC; spf=pass (google.com: domain of conduition@proton.me designates 185.70.43.167 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me Received: from mail-43167.protonmail.ch (mail-43167.protonmail.ch. [185.70.43.167]) by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-488d534adb0si659425e9.2.2026.04.10.10.03.30 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Apr 2026 10:03:30 -0700 (PDT) Received-SPF: pass (google.com: domain of conduition@proton.me designates 185.70.43.167 as permitted sender) client-ip=185.70.43.167; Date: Fri, 10 Apr 2026 17:03:21 +0000 To: Matt Corallo From: "'conduition' via Bitcoin Development Mailing List" Cc: Antoine Poinsot , Bitcoin Development Mailing List Subject: Re: [bitcoindev] In defense of a PQ output type Message-ID: <6wBygQ_pK40ZpU_CMXfzIy-6LkthOmEh-xd2g9bwUl-f8w2K6G4rUWJEssE2zeJgxyipGe2GrFH9y_TUUI48asqfh7dhi9A2rl7NpWyFW1o=@proton.me> In-Reply-To: References: <0vqF88LoOnY4GiUB4vf-MdeZpTAtR70tokS3cLwt2DX0e6_fD1X_wyhPwWEdIdm6R88AULObIU08CWsb5QfeoaM5c4yXPqN5wHyCrqMCtfQ=@protonmail.com> Feedback-ID: 72003692:user:proton X-Pm-Message-ID: b5a431176cc087697b5a8894e9477ed9a1538322 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------e1586010e6388055d88ff39a5c4fd825e2d3380f412fcf0eff4c5516ff6039e5"; 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=protonmail header.b=btPwn+VC; spf=pass (google.com: domain of conduition@proton.me designates 185.70.43.167 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: -1.0 (-) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------e1586010e6388055d88ff39a5c4fd825e2d3380f412fcf0eff4c5516ff6039e5 Content-Type: multipart/mixed;boundary=---------------------bb65179755df3dd1259f67dbaaf79832 -----------------------bb65179755df3dd1259f67dbaaf79832 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Hi List, I second Antoine's position. We can have two distinct fields of R&D proceed= ing concurrently: 1. Proactive: BIP360/P2MR; PQ signature opcodes; QSB & other scripting tric= ks 2. Retroactive: Freezing; Hourglass; Rescue protocols like BIP32 STARKs and= commit/reveal The two should be independent, because (1) need not affect inactive holders= and legacy coins at all, whereas (2) necessarily does. In my humble opinion, the proactive field (1) is the much more pressing iss= ue. The sooner we settle on at least one address format and wallet structur= e for long-term hodling, the sooner PQ-vulnerable UTXOs can start migrating= , and the fewer will be stolen or need rescue protocols later. Though planning ahead for (2) is also important long-term. Laolu's recent d= evelopment work building and benchmarking concrete BIP32 STARK proofs [1] i= s a great example. Through this, or a commit/reveal equivalent, maybe combi= ned with an ownership proof used for non-BIP32 hashed addresses, I for one = am confident we can catch a majority of exposed bitcoin in a safety net. > But as mentioned above I do not see why any addition of hash based signat= ures to tapscript should require any kind of community consensus on future = disablement of insecure spend paths I think Antoine's point here is that if we introduce a PQC opcode to tapscr= ipt but choose NOT to deploy P2MR, and then encourage people to use that op= code in P2TR script leaves, then we are locking ourselves into the assumpti= on that the community will later disable P2TR key-path spending - otherwise= those addresses will be compromised by a CRQC and the PQC leaf script is u= seless. > Adding a PQ output type which no one will use (eg one where use of the ha= sh-based signature is mandatory, which drives fees up hugely and has all th= e drawbacks you mention) is not a risk mitigation strategy - it does not ma= terially allow for any migration and doesn't accomplish much of anything. B= ut as mentioned above I do not see why any addition of hash based signature= s to tapscript I don't think anyone is suggesting deployment of an output type with mandat= ory hash-based signatures. That would be borderline unusable for anyone but= large companies and wealthy elites. Every decent proposal I've seen has suggested using PQC in tandem with ECC = across multiple tapscript leaves, whether in some bastardized variant of P2= TR, or in BIP360's P2MR.=20 My favorite idea is using hash-based sigs as a fallback escape hatch, becau= se as a highly conservative field of cryptography, hash-based keys can be a= fallback not just for ECC but for any future FancySig PQC algorithm we ado= pt in the future: lattice, isogeny, multivariate, whatevs. I posted an idea= recently [2] for how to construct drop-in BIP32 replacement algorithms und= er this exact context. regards, conduition [1]: https://groups.google.com/g/bitcoindev/c/Q06piCEJhkI [2]: https://groups.google.com/g/bitcoindev/c/5tLKm8RsrZ0 On Thursday, April 9th, 2026 at 8:34 PM, Matt Corallo wrote: >=20 >=20 > On 4/9/26 2:58 PM, 'Antoine Poinsot' via Bitcoin Development Mailing List= wrote: > > Many of us appear to be in favour of introducing post-quantum signature= s to > > Bitcoin via a new Tapscript operation, conditioning the CRQC resistance= on a > > future invalidation of Taproot key spends.I would like to offer an argu= ment in > > favour of introducing such post-quantum signatures as a new output type= instead, > > that does not depend on invalidating a spending path on existing output= s. > > > > First of all, it's important to clarify what we are trying to achieve. = We need > > to accept that, by virtue of being faced with an uncertain existential = threat to > > the network, there are scenarios, however unlikely, in which the networ= k does > > not survive. Not all plausible futures are worth optimizing for. For in= stance, > > one in which PoW ends up broken only a few years after EC crypto, or on= e where > > the entire Bitcoin userbase *must* migrate within a handful of years. > > > > I think there are two futures worth optimizing for primarily: > > - a CRQC never materializes and users can continue benefiting from the > > properties of a Bitcoin network relying on classical cryptographic > > assumptions; > > - a CRQC materializes on a long enough timeframe that PQ signature sche= mes that > > maintain today's properties can be designed, vetted and adopted, and= the vast > > majority of the userbase migrated. > > > > And because hope is not a strategy, it's important to also have a "brea= k glass" > > emergency plan in case a CRQC emerges on a shorter (yet still reasonabl= e) > > timeframe. I think the current proposals for hash-based PQ schemes fit = this > > category. If they became the only safe option available, it would certa= inly make > > Bitcoin a lot less attractive. But having them around is good risk miti= gation > > *regardless* of whether a CRQC emerges. > > > > It's often argued that a freeze will be necessary anyways, therefore we= might as > > well disable the Taproot keyspend path simultaneously and simply introd= uce the > > PQ scheme today in Tapscript. I personally reject the premise, but more > > importantly i think we should separate the concerns of 1) making a PQ s= cheme > > available and 2) freezing vulnerable coins. Yet introducing a PQ scheme= inside > > vulnerable Taproot outputs locks us onto the path of eventually freezin= g > > vulnerable coins, as it will inevitably turn users of the PQ scheme int= o > > supporters of a freeze. >=20 > You've missed the much-more-important thing that cannot be extricated fro= m disabling insecure spend > paths - the ability to recover from a seedphrase. In any world where a CR= QC exists, whether it is > next year or a century from now, there will be a million or two bitcoin i= n lost-key-wallets and a > nontrivial amount in wallets people haven't touched in ten years but stil= l have keys for. Given a > goal of any migration strategy should be to enable the absolute maximum n= umber of coins to be > retained by their owners (I think this is basically the *only* goal?), en= abling seedphrase proof > recovery is pretty critical. Sadly the only way that can be done is throu= gh disabling insecure spend > proofs. >=20 > But you've also confused unrelated concerns here - whether a hash-based s= ignature is added as a > tapscript opcode or not is not strictly tied to whether a new output type= is created. If BIP 360 is > the way bitcoin goes, it *still* needs a new hash-based opcode in tapscri= pt. Maybe more > interestingly, a new taproot "version" could be added which has identical= semantics to today's > taproot but signals through an alternative version number (or maybe there= 's a cleverer way to encode > a bit somewhere that we should prefer) that a PQC pubkey exist in a tapro= ot leaf somewhere so the > insecure spend path should be disabled. >=20 > > This approach would tie the availability of a PQ scheme to reaching con= sensus on > > a future freeze. Frankly, i do not believe the latter is achievable, le= t alone > > at this stage with so little evidence that a CRQC will materialize anyt= ime soon. > > By contrast, there is a much stronger case for introducing a PQ scheme = in the > > near term purely as a risk mitigation measure. Coupling the two decisi= ons would > > necessarily delay the deployment of a PQ scheme, unnecessarily exacerba= ting > > risks whether or not CRQCs become a reality. >=20 > Adding a PQ output type which no one will use (eg one where use of the ha= sh-based signature is > mandatory, which drives fees up hugely and has all the drawbacks you ment= ion) is not a risk > mitigation strategy - it does not materially allow for any migration and = doesn't accomplish much of > anything. But as mentioned above I do not see why any addition of hash ba= sed signatures to tapscript > should require any kind of community consensus on future disablement of i= nsecure spend paths - not > only is it a likely prerequisite for an alternative output type, but its = also (obviously?) not > possible to have any kind of "consensus" on what the future bitcoin commu= nity will do. Thus it would > be rather impossible to do *anything* if that were a requirement. >=20 > > Another drawback of the PQ output type approach is that it would make t= hose > > outputs distinguishable from Taproot ones, which is suboptimal in the e= vent that > > a CRQC never materializes. But i would argue that even in this case, th= e cost is > > minimal. The users most likely to adopt PQ outputs today (those securin= g large > > amounts of BTC with a small set of keys) already have vastly different = usage > > patterns from Taproot users: they often reuse addresses and use legacy = output > > types (and show little interest in upgrading). > > > > Best, > > Antoine Poinsot > > >=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/cba894e1-f830-4ad5-9498-09f04faaadf7%40mattcorallo.com. >=20 --=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/= 6wBygQ_pK40ZpU_CMXfzIy-6LkthOmEh-xd2g9bwUl-f8w2K6G4rUWJEssE2zeJgxyipGe2GrFH= 9y_TUUI48asqfh7dhi9A2rl7NpWyFW1o%3D%40proton.me. -----------------------bb65179755df3dd1259f67dbaaf79832 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== -----------------------bb65179755df3dd1259f67dbaaf79832-- --------e1586010e6388055d88ff39a5c4fd825e2d3380f412fcf0eff4c5516ff6039e5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wrsEARYKAG0FgmnZLUcJEHgpbO2E9rPFRRQAAAAAABwAIHNhbHRAbm90YXRp b25zLm9wZW5wZ3Bqcy5vcmfgXGJFpVfFDip12YjcdauudBylH3NdskRq8+bC yY/hhhYhBEdIka0CMtrLdg13a3gpbO2E9rPFAABFSwD/aLQBi/Vg0G0OQ2QE CiLdwCDy/oduE5bAUmTBgqJfzsABAKi0bCefH/2IZJqVx/6gOLGP8hdBN+WQ cCWfejBsDw4C =vmkL -----END PGP SIGNATURE----- --------e1586010e6388055d88ff39a5c4fd825e2d3380f412fcf0eff4c5516ff6039e5--