From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 13 Apr 2026 18:52:50 -0700 Received: from mail-oa1-f62.google.com ([209.85.160.62]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wCSxN-0002la-BP for bitcoindev@gnusha.org; Mon, 13 Apr 2026 18:52:50 -0700 Received: by mail-oa1-f62.google.com with SMTP id 586e51a60fabf-423133d22a0sf9457345fac.3 for ; Mon, 13 Apr 2026 18:52:49 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1776131559; cv=pass; d=google.com; s=arc-20240605; b=SP3C/fkLjHws37rlXrq8OuTYFFsaEpFqPmdbtv0RdJfQYAdxdOA86lw82G5z9qM/G8 edqozH5LWOzSx/194ABYoBvNPWTwvj5qOZxfoaiWmTEI+JOjIflsWD+pmDSFKjVvdvY9 qrlbuy0mTptp5VYON6eFsaa76tseQy0ku1m6ZsfIrnj+V10LAaY44TwhgattxifUnGwn VAcpmuki82aOSZMCzMFrtFdC1GnC9Kfif54VgWslLldUxEaH5E1qsGcnodpxyt0XU5Ys kuqXN4hO7uj3BlUb9Z/GCoLSp3eB0jzWP7ewgIgvamIZzVvhHxuZVFI12k49ner85YaF wBkw== 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=l/x82N5qOgVvYF+bOumDOFkQwtDRux0FyYaxgF+Fidk=; fh=FNUvQqahwVHpkdvblA8NJhHh+hDzlk8DZRWq8Yzy3gc=; b=UFGzbM/u2I4Mop/Eu8smpaAgHRLVCqmvFpasXDkDOxmw0HKH3aoef5i4HVcugpBVIZ GpmEX3ZMbM0vvH9/wA623ZGUhvDEW9RKP6bczdtSF5d+2mtD4Wwd8Veo4Raqk4PBLVj1 rt6oCfUO9b7Sbdo2yJ6Ni67CsAQyYlARSv2bSDBrD04ID+PLM+7AkHewlhrwnxoALSah zsMzVf5JZUed+6A4cRQz3lNafaLLSFs8BO11towZ5u4hNBejdhD9Wdo2UsE8c/DGH30z 0XWFx1eU7RlieVRLFfSiVlyMTg/TGf5aWp+Wekw12Jj2AUzq1I+vXG3D5Jy4VYDQcC7K /rEQ==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=hi3apaljufa5ndmhidtslg7h7y.protonmail header.b=RlIAxQou; spf=pass (google.com: domain of conduition@proton.me designates 109.224.244.30 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=1776131559; x=1776736359; 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=l/x82N5qOgVvYF+bOumDOFkQwtDRux0FyYaxgF+Fidk=; b=iUAQB5j7LEx7vrYQq0rASJL/wKdmi2e7cU+ORmYF72MYame2s0i0TlvCQvMWflksWb KO1hBzPWMijDi7VKKETIRReMbgQDIQrIxF6WTAFxxvNQacBwxyH8HhloeldQrbS3VO4w yI2QI+AIDHgWMla58iiL/0H7waV915x2x68FL+vp40OB2e1VJyLSvmKXc9TIqXw0DshV /RsjWmfRWovzhCyb1X2TyXyoO5x5X7djMWxvZZtHV1b8PMZJn4I4eKe39AZXhqj9VG9K M0/3VaGS5/nKtpj6bsMPMxOrVHWuPW130SU9jmRKQ/Es5qh5avzPgh4lfobAw9LXmA59 RdHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776131559; x=1776736359; 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=l/x82N5qOgVvYF+bOumDOFkQwtDRux0FyYaxgF+Fidk=; b=G76q532pNDSs2twm6pmqdRlVxzXFBDzZiHL75/XxJGdoo9xviK1zvbIaQe9Xf1hBUX gm+UY9zcEKxZ/6kH91dU9MA99EdK7FqDKDy0tUJtv3cGtIaS1wkX8M5GpIFucj5dmV17 59+6Ux71SbxVxSS1qzVX8iidWEwijgH/caSx9QEv3yHZtnJfIVNMXzONCusicuy6+3+D 9pUwWyuILvx/Succ/I42nGBFfb6g6z+g3jyBwcfx6sQiZmounQP2VJ2VfC8QetgNn+Xg bgmWSzSWSs8QAUBey6K6foPGU5UnqktTTJXwb+vppfd3jTClGPG56YLaQRji10ppd/i0 soRQ== X-Forwarded-Encrypted: i=2; AFNElJ8ltjDS1XHDdMbnecufqjBe5PsQofcx2Z75WKcjJTWm6C2OXj66ubNl1kKZ6H+XSS1HzRzxt8P85Qpt@gnusha.org X-Gm-Message-State: AOJu0YzAo6yczR505WVGTTQNM/OnWSStw7vTFTNTSN0umy2mvFJ9kQbh z7O56ue8eTHNF6kveLXbaLIWoHAhtl059PRabC6c6IIQEYR2cqiB1fC3 X-Received: by 2002:a05:6870:712d:b0:41c:4e6b:3673 with SMTP id 586e51a60fabf-423e0eace94mr8822085fac.10.1776131559254; Mon, 13 Apr 2026 18:52:39 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AYAyTiKCL9pn12Gt1cT7dGpu55r9lFffI/2rmTQYDLw6catA8Q==" Received: by 2002:a05:6870:d409:b0:409:4c04:fab5 with SMTP id 586e51a60fabf-423dd9b0a41ls1918960fac.2.-pod-prod-05-us; Mon, 13 Apr 2026 18:52:34 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ/+Rlvk+5/EsKKtuIVpDeoRnj7Fm8YU4e+7ZouS2dTwoEuvi9Pm6t0p2MgZfdCMnKOTDYxUjVbZif2E@googlegroups.com X-Received: by 2002:a05:6808:c162:b0:467:91:fb26 with SMTP id 5614622812f47-4789f111a6dmr7458316b6e.37.1776131554356; Mon, 13 Apr 2026 18:52:34 -0700 (PDT) Received: by 2002:a05:6808:6691:20b0:467:52e4:df4a with SMTP id 5614622812f47-4775b712654msb6e; Mon, 13 Apr 2026 18:45:54 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ+MGOTEqNq7WQzMlIVIIqhwaWizvVvofBYOT05+8/qGzZvqqb583tFUzLR3jh5v3ykU/92WedsKvM+T@googlegroups.com X-Received: by 2002:a05:6808:7008:b0:459:bcff:a9ff with SMTP id 5614622812f47-4789f00f53bmr8073921b6e.34.1776131153740; Mon, 13 Apr 2026 18:45:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1776131153; cv=none; d=google.com; s=arc-20240605; b=W4Jf/ODoOri1JN2c912ImsBbJ5PeWok6j/z6E0hSu9CDGWdQZ6atF6gQRkjLwRXro9 kJYMl40iTWpFNx9BFdg84PTwhpXGW7QiqRwRdL+VbgICHJXNwAWLGj8j7RpQsPzF2Xfx X6AjO4U0eP7sUjwx/dqif3m4iOLv9DYCDda0QP/sm0OQEVS+JfS3X8Ms0rRMfx8qaETr IAsxQh/ZlJQBmWVvh6w3ErlmqvmpBvUbeToVxt+6he1ZjW01u+n61do/+bSox5Ks8cYU ehdC1qzp2VCAe9nh/MtsT2H+3hHzVOFXt6xXn6wm1790Z61zdaIvDRDuwAzOF4ZVA7/J Wb0g== 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=7EZTr7yjp3269VF9J8Vr4TG83UykussUBxVnIory5fo=; fh=JscRoQWfVjASGdrrQ9flE5fSaik2YIEk9HCJPg7sC0o=; b=M5yMWyQfMgfoKLSIU1ZY/EvUha1t3qHOerhc7r6nBqEyr+x3E0dYFOdOF6I2Gh9sZl Q3vSvotmoxbc2p4qyvHKher0WR4tjXbliBLqFQ5a/tqV+PCRaTpVATkVvwAcKQw0FcOL a7yQ0Egz4u/JLbxJseL91j+WC2cXkQh8FhoVisaKeLOkGUqSrRVnmMa0foTJG8Zf7I+j rhoesPkyRtHONyACjWytRpg2n9BGEFOH7KsypwLm1VqSHJhDejaRE0IYz49cfFHoZZLL 0Qdf6Hzg9+U36LYuNGnYM63WblezjuULmpZ4/CgMLugJ+94BlfTwIg66Oynsm5b4HOUE ZBLA==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=hi3apaljufa5ndmhidtslg7h7y.protonmail header.b=RlIAxQou; spf=pass (google.com: domain of conduition@proton.me designates 109.224.244.30 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me Received: from mail-24430.protonmail.ch (mail-24430.protonmail.ch. [109.224.244.30]) by gmr-mx.google.com with ESMTPS id 5614622812f47-478a060816fsi492549b6e.1.2026.04.13.18.45.53 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 13 Apr 2026 18:45:53 -0700 (PDT) Received-SPF: pass (google.com: domain of conduition@proton.me designates 109.224.244.30 as permitted sender) client-ip=109.224.244.30; Date: Tue, 14 Apr 2026 01:45:45 +0000 To: Matt Corallo From: "'conduition' via Bitcoin Development Mailing List" Cc: Ethan Heilman , Antoine Poinsot , Bitcoin Development Mailing List Subject: Re: [bitcoindev] In defense of a PQ output type Message-ID: In-Reply-To: <6d075872-0db8-4e7b-ac2a-452624c991ad@mattcorallo.com> References: <0vqF88LoOnY4GiUB4vf-MdeZpTAtR70tokS3cLwt2DX0e6_fD1X_wyhPwWEdIdm6R88AULObIU08CWsb5QfeoaM5c4yXPqN5wHyCrqMCtfQ=@protonmail.com> <6wBygQ_pK40ZpU_CMXfzIy-6LkthOmEh-xd2g9bwUl-f8w2K6G4rUWJEssE2zeJgxyipGe2GrFH9y_TUUI48asqfh7dhi9A2rl7NpWyFW1o=@proton.me> <765490aa-5df3-4619-86cc-17570b6d3e99@mattcorallo.com> <6d075872-0db8-4e7b-ac2a-452624c991ad@mattcorallo.com> Feedback-ID: 72003692:user:proton X-Pm-Message-ID: 5b27b882835b5a2a1d90c197599b69184f06b4dc MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------6525775950a5094ddacad7574211cc61071f822a2dc69a0aa00f24ae13f85d72"; 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=hi3apaljufa5ndmhidtslg7h7y.protonmail header.b=RlIAxQou; spf=pass (google.com: domain of conduition@proton.me designates 109.224.244.30 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) --------6525775950a5094ddacad7574211cc61071f822a2dc69a0aa00f24ae13f85d72 Content-Type: multipart/mixed;boundary=---------------------52f8a366324950b472f0e93b41c1f9d3 -----------------------52f8a366324950b472f0e93b41c1f9d3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Hi Matt, > Yes, we have to figure out what kind of output type we want, whether P2MR= (360), P2TRv2 or just P2TR. There are strong arguments for each. But none = of that has any bearing on whether we add hash based signatures to tapscrip= t. We have to add hash based signatures to tapscript first no matter what o= utput type we want! Apologies, there must be some mixup. I think we agree with each other about= this - adding a new PQ opcode to tapscript is always going to be necessary= , and our choice of PQ output type doesn't affect that =F0=9F=91=8D My earlier clarification was that we must go further: We must add a new out= put type in order to disentangle opt-in PQC opcodes from any confiscatory s= oft fork that disables P2TR key-spending. Otherwise, if we only enable the = hash-based opcode and do nothing else, then we must disable key spending la= ter or else the opcode is useless. So the two concepts are not completely independent. Adding hash-based signa= tures to tapscript necessitates a new opt-in output type that we can standa= rdize quantum-resistant wallets under. Similarly, adding a quantum-resistan= t output type doesn't seem very useful without a quantum safe way to author= ize spending. =3D=3D=3D=3D=3D=3D=3D At the risk of this thread further devolving into a debate around P2MR and = P2TRv2... > Our goal is to get as many wallets migrated as possible, which really mea= ns focusing on the wallets that are likely to take the longest to migrate. I can't speak for others, but my goal is to design and deploy a secure and = efficient soft-fork upgrade package so that myself and other bitcoin users = may retain control of our bitcoins in a world where the future security of = the ECDLP is uncertain. Encouraging adoption is a secondary goal which foll= ows immediately if we design the upgrade well. I personally don't see P2TRv2 as a suitable path towards this goal, because= it still depends on ECDLP. At best, P2TRv2 PROMISES to be quantum-secure l= ater, at the chaotic whim of the future Bitcoin community. Personally, I wo= uld rather keep my coins on P2WPKH than on P2TRv2. No: If we are going to h= ave a PQ soft fork, it should be conclusive, self-contained, and require no= follow up. Otherwise, we haven't actually fixed the core uncertainty we ne= ed to address. > That includes both "consumer" wallets which may be infrequently used by p= eople who bought a pile of bitcoin and touch it once every few years as wel= l as those who are quantum-skeptical and will see no reason to upgrade unti= l its urgent. Low-frequency users aren't fee sensitive, almost by definition, so I don't = see them caring much about the minor witness size increase of P2MR compared= to P2TR. As for quantum-skeptical users, I see no reason why they would migrate thei= r coins to ANY quantum-resistant output type, whether P2TRv2 or P2MR. To so= meone who today sees quantum computers as 100% FUD with zero room for doubt= , they will see any PQ output type as a slightly worse version of whatever = they use today. So I don't really understand why it would be so important t= o encourage this class of user to migrate. They won't - not until their wor= ld-view about the quantum threat changes. If and when their attitude does change, then a few vbytes of overhead compa= red to P2TR won't deter them - not with an existential threat motivating th= em to migrate. If fees DO deter them, then they're probably an active high-= frequency user like a miner or exchange, who can keep tabs on the situation= and continue to grind savings out of P2TR until the very last minute [^1]. It is a mistake to compromise on long-term design choices [^2] to please qu= antum-skeptics, because: 1. If the quantum threat is indeed real, then sooner or later, whether by t= heft or migration, this class of bitcoin user will no longer exist. 2. On the other hand, if CRQCs turn out to be not-so-relevant after all, th= en everyone becomes a quantum-skeptic, and we can all return to P2TR while = the new PQ output type slowly fades into obscurity. Note in scenario (2), P2MR actually still has utility: P2MR can be used as = a more-efficient way to construct script-path-only addresses, without the n= eed to commit to a NUMS point. P2TRv2 has no such secondary utility. regards, conduition [^1]: By the way Matt, I think it's a mistake to assume that large corporat= e users are not fee-sensitive. If anything they are more fee-sensitive than= Joe-Average - When you conduct thousands of transactions per day, 10% larg= er witnesses could mean a lot. [^2]: P2TRv2 is a compromise in the long-term compared to P2MR, because aft= er key-spending is disabled, P2TRv2 is strictly worse than P2MR: It would h= ave worse performance and larger witnesses, more cryptographic complexity, = and it commits us to carry legacy ECC as cruft well into the future.=20 On Monday, April 13th, 2026 at 9:23 AM, Matt Corallo wrote: >=20 >=20 > On 4/10/26 8:20 PM, Ethan Heilman wrote: > > > IMO even something like P2MR's additional cost will strongly discour= age adoption. > > > > I don't agree. > > > > Over time as quantum attacks become a bigger and bigger concern for hol= ders, wallets will want to > > show that they can offer security against CRQCs. This is especially tru= e for wallets focused on high > > value Bitcoin outputs. Even if someone thinks there is only a 2% chance= they lose all their Bitcoin > > because of a quantum computer, that 2% chance will keep them up at nigh= t. > > > > P2MR would have 17.25 more vBytes, an 11% overhead. > > > > P2TR 1 input, 2 output - key path spend. 154 vbytes > > P2MR 1 input, 2 output - spending a schnorr sig leaf of a P2MR output w= ith two leafs: 1. PQ sig leaf > > and 2. Schnorr sig leaf. 171.25 vbytes > > > > I'm stacking the deck against P2MR here. Under some circumstances P2MR = has lower fees than P2TR. > > > > It is hard to imagine someone holding significant quantities of Bitcoin= not wanting to pay 50 > > sats to ensure their Bitcoin isn't stolen by a quantum computer. >=20 > Right, but I think we're focusing on two very different groups. The "hold= s significant quantities of > Bitcoin" group I'm much less worried about vs the "holds some quantity of= Bitcoin in an average > consumer Bitcoin wallet". The first group includes institutions, funds, a= nd people relatively "into" > bitcoin - they're paying attention, (hopefully) using decent wallet softw= are, holding funds in cold > storage, and aren't fee-sensitive. But this group is going to have no pro= blem migrating no matter > what the solution is - the institutions and funds camp can migrate in a f= ew days in an urgent > scenario and the long-term holder with a significant portion of their net= -wroth in Bitcoin is also, > likely, paying reasonably close attention to Bitcoin and can react quickl= y. >=20 > Because those groups are quite capable of reacting quickly, I don't reall= y buy that they're the > "target market" for short-term PQC in Bitcoin. Our goal is to get as many= wallets migrated as > possible, which really means focusing on the wallets that are likely to t= ake the longest to migrate. > That includes both "consumer" wallets which may be infrequently used by p= eople who bought a pile of > bitcoin and touch it once every few years as well as those who are quantu= m-skeptical and will see no > reason to upgrade until its urgent. Importantly, the decisions here are m= ade by the developers of > the software, generally not the actual end users holding Bitcoin. >=20 > To put it a different way, the goal of adding PQC to Bitcoin is *not* to = "give people an option to > migrate" but rather to "make use of the PQC scheme the default" across th= e ecosystem. The former may > get the migration process started, yes, but it does not ease the future c= ommunity's difficulties > materially - the slower-to-migrate coins will still be just as stuck as b= efore and just as much > Bitcoin will be available to steal by a theoretical CRQC. Thus, ISTM the = focus *has* to be on > something that has minimal drawbacks - not losing the script policy priva= cy of P2TR, low or no fee > overhead, etc. >=20 > Of course that isn't to say that P2MR might not also make sense in additi= on, but focusing only on > that misunderstands the goal. >=20 > Matt >=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/6d075872-0db8-4e7b-ac2a-452624c991ad%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/= MjCpr-zqQa6GUq9jQH9mWcZ-ClGZ04Q0gCvFRqWt9AOV7fKjSYah5yujwwAFxNkntVooqC_9Pyy= Y9BogZGgt6uQBHO0AGEFGWr_iQnxfbxI%3D%40proton.me. -----------------------52f8a366324950b472f0e93b41c1f9d3 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== -----------------------52f8a366324950b472f0e93b41c1f9d3-- --------6525775950a5094ddacad7574211cc61071f822a2dc69a0aa00f24ae13f85d72 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wrsEARYKAG0FgmndnDsJEHgpbO2E9rPFRRQAAAAAABwAIHNhbHRAbm90YXRp b25zLm9wZW5wZ3Bqcy5vcmcfwsk1uUA8QYLjKzLU1alubAfO/+Q/toYVroew quiJlhYhBEdIka0CMtrLdg13a3gpbO2E9rPFAADsXgD/QCOygHsUxHP7leFR 1jA1dYqGBUYJbUQ5ehKCIbLRY/wBAMQJ7QYzC8gawIgxDYHM7VlpuBmNRPoy NnVEdvIFmPwA =+VXK -----END PGP SIGNATURE----- --------6525775950a5094ddacad7574211cc61071f822a2dc69a0aa00f24ae13f85d72--