From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 16 Jul 2025 09:48:38 -0700 Received: from mail-yw1-f183.google.com ([209.85.128.183]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1uc5J7-0001fP-9l for bitcoindev@gnusha.org; Wed, 16 Jul 2025 09:48:38 -0700 Received: by mail-yw1-f183.google.com with SMTP id 00721157ae682-710e75f9229sf101217677b3.2 for ; Wed, 16 Jul 2025 09:48:37 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1752684507; cv=pass; d=google.com; s=arc-20240605; b=FaLOiomjLQPdj/BvU2RaL/0jC7KZhsRVf11DMnI4X/AczF0ImY9yZzQUbi0Be4nIeX k+8vqmiHnMz7JUgogeaJ1r2As4ml/Z5duLqQZhX4ruEdgI/ooO6k+FNX6Nkh7uzEQI1d jZLV0wrdYh79oEPrWf2Ch7LuhZRlqpIYHc72i4IAj6iVDMyLl13nzV2hT9zVFfy+RnEC 7YikFkazJHXuhlVU/hxm8LeN/J0QrnHUl0OGgKEwTkT1WaOdI8wxQAJFMUg4aEZuTJxF gO49bOwuvL/FqaaCbyFCuLwxPxAIUjaGj15KyueN2hn2++NWaWl+XvTXNSjK04gTZ9L/ WbQg== 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=J25mA9Y6PTPgCSwEVmVqbFkfHWPZOmMJ+slOhqEvsPQ=; fh=CUs0flmAMn1r1aGQJVhl+zsZ0j8G9VyLIfDaCANLOaU=; b=iWBDyWHcGgNhKBB+BoXpeOVL7xYzBfI/OZhf5E29VpZMX6D8C6lUx5HXigQ5oUFrMF oX0r2bMh2voaG79cu4RGUV7kvo3DB73qa6i19xqAz6ImXd4awX5G7aZjgQD5aRku9s1t clpzqIOpy+x67r6OOCxS+WZBEFWy22qgKTQuWZfEWDXDP/EomRKqjT4aPZYtN8SUwICx VlV9IjmFtaCu3wUWfkuRng0JvccbXtCyp7TobNO6g6KrNZ3+LYVSvPFwryRRjqdrTjfs kpXy75LXY3botv//PaMPsTpMkcCQWYEdm5Uw3PS7D8rOO75HV9KDfQjme2JBYZbRgGxF vlSQ==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b="kf/13yTh"; spf=pass (google.com: domain of conduition@proton.me designates 109.224.244.18 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=20230601; t=1752684507; x=1753289307; 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=J25mA9Y6PTPgCSwEVmVqbFkfHWPZOmMJ+slOhqEvsPQ=; b=b2E48587X4ibEOtmEminpRDi1HiqTAv4HM3QDZgB27q7pL/LYApcg8qYBN9jC9Vm+G oDk7lWnOqjZCOdSQB/a5FN3CVOezmQaHn7AWU7nGQ+DskLTw9pSkIrWyRzDX9Kv752RS qm7wQCCzahtNmav+d+gQ/n5Y0oKBMQDYp9+LFBZ810TBZnWWeFGb3FAZPEUUwNyOkBdm FE5hDo/Wm73aIRQNUG7iA3dpwzwtvFNFOzEXsZkkfiupIQL7uvWesq/glC5UMkjdjmkV v2ERsPaD65J6lc5a1uPOHlQlwHqNlo3s/YETbvV76VFbT5v1jMttlTSZNDyYuheOii1d +NCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752684507; x=1753289307; 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=J25mA9Y6PTPgCSwEVmVqbFkfHWPZOmMJ+slOhqEvsPQ=; b=tyCVEpfX1XytvnNd1d/OW6XrKI3zH9nWLNbug9m+Gk6DD8SS1HY1XdClvNvZpzVX8Y 7a6mKQ9sfehjidbsNn7YtONf802dgq51ZNNGLIhfjASeIK4pKyZwMX7OqErS7n0xENDv OLk5CH7xRWP89+st3PmY3c86phFagl+JeoY/mpzd/jBRIbnqBtzMgk8vJe7YQfyKHG7G kP3Y26I9dstMLVAq4G5sGRQ14DGuTkrHKvR2Zv5qcWg7NKgYrj4tjQYVPoW0WqqGU4SM rGnIf4ZRkohc+IK7y6wHkEfLAbNj+rtnhbb1hFfozIPGKd6jPizS+C7T0TPdJFTdc9Gk sGsQ== X-Forwarded-Encrypted: i=2; AJvYcCXPVMusoSynHoouI4VcUpCET3tKe8ukdpC1WmUbCcgoY1VdZmrWshSFk/kkTzDLUdA1XwCJLopQX543@gnusha.org X-Gm-Message-State: AOJu0YyyqEq+W2oc+1eJ6i79YxjSMdh+R2WnmLGILA4H8uU+NFwkasqS quw60McHBHy7GDo73XaifSeg4oAzwjcYQuiXQfJuar4ISQtz4ggrloc7 X-Google-Smtp-Source: AGHT+IEfPYslqddEyCQ44x5EhZ5g9N8b3xwAksHFAgpT1kBoFL32gxtcZxTjX0YNp6z4R8G1dR2sZw== X-Received: by 2002:a05:6902:258a:b0:e8b:d2d0:8b12 with SMTP id 3f1490d57ef6-e8bd2d091admr1696495276.17.1752684506993; Wed, 16 Jul 2025 09:48:26 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZcTdVwbrAY8dRgDA225LugiWS6Lnrw4br7CRYgMeAfepQ== Received: by 2002:a25:4cc2:0:b0:e87:adad:c527 with SMTP id 3f1490d57ef6-e8bd4608490ls145269276.1.-pod-prod-04-us; Wed, 16 Jul 2025 09:48:22 -0700 (PDT) X-Received: by 2002:a05:690c:7006:b0:70e:82d6:9af2 with SMTP id 00721157ae682-7183519693bmr54582107b3.34.1752684502613; Wed, 16 Jul 2025 09:48:22 -0700 (PDT) Received: by 2002:a05:6808:2186:b0:40d:498:c1f6 with SMTP id 5614622812f47-41cd998409bmsb6e; Wed, 16 Jul 2025 09:43:30 -0700 (PDT) X-Received: by 2002:a05:6808:11cb:b0:409:f8e:72a7 with SMTP id 5614622812f47-41cefffbdf5mr2385419b6e.33.1752684209448; Wed, 16 Jul 2025 09:43:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1752684209; cv=none; d=google.com; s=arc-20240605; b=e3u/eIxjhHc6gvhe5sa41dq7lKEOUgP0EJqEXCKJO82LmPuy12WETyLmcN1yNt3egn sIXTedo2qnQbQ601q5eMY2gL23XT05Qm7rQXHsUaOENY6Yam8pzPdJyWqtjTpojQAMQo Y68M+hjgCIuTgU/f4bTWsRCZtVhSIIwwDTRct2uzOnwjpL3Pv2jO3phrb+hEQ1aiPvnd QQ3zkYjYdIPyAN23wLa0kze3a6jEPkAgBEv5BhFss5wkcOgiOKJDJSe3nTZttjbQxKca lHjixU5uFJZPp149aX2Bk7TUtlJrq6QVfhlYBSHqU1qpDw/tn/7V6EBVJhPq/bP1aIx9 7Jaw== 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=sTpaqEy06+xJrN4LCDPf+qkTqBOJqiihkxMrASKd7D8=; fh=6b1pLcW6tcZ6I7AhOCDpUTdU/HBZRb+DjIxd1ga4+Sc=; b=ghWJtM8QKCrpQimWVkVFNfQOGMSz1k64/pSfk6Ld4wZQVzxemFjmVFT4i0w13K/QgR oC1zuf4z8ry5wVKidqaKR1i9iJYB9/GojFu2HriajkXONbW0pqRPVa+CD3ffonh0ugdD 10+N1rf4mhhrSbOySQD5FmaB/RnLr8dO6RN2Bkbz/g2TN/2m0es/Aiig0pin0l/H41w2 HrG+QZkidyuExyFFbyS82ibVQjkmLH3k5HHSbHzkkm+lpr8/3QnvVp6qROr2qLoCyeDu 8Q20mIKDWCWIVY7qukyXMDjgl5OQiILHCwBZmmN/katCKoUQ7sS1NsuXP6eXEE5aN7JH iCbw==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b="kf/13yTh"; spf=pass (google.com: domain of conduition@proton.me designates 109.224.244.18 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me Received: from mail-24418.protonmail.ch (mail-24418.protonmail.ch. [109.224.244.18]) by gmr-mx.google.com with ESMTPS id 006d021491bc7-6159092ea4asi279672eaf.2.2025.07.16.09.43.29 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Jul 2025 09:43:29 -0700 (PDT) Received-SPF: pass (google.com: domain of conduition@proton.me designates 109.224.244.18 as permitted sender) client-ip=109.224.244.18; Date: Wed, 16 Jul 2025 16:43:23 +0000 To: Boris Nagaev From: "'conduition' via Bitcoin Development Mailing List" Cc: Bitcoin Development Mailing List Subject: Re: [bitcoindev] A Post Quantum Migration Proposal Message-ID: In-Reply-To: <88a7b020-e84f-4052-9716-fb40b23f07ddn@googlegroups.com> References: <88a7b020-e84f-4052-9716-fb40b23f07ddn@googlegroups.com> Feedback-ID: 72003692:user:proton X-Pm-Message-ID: 9b7047850c1dff8579057cdb7f87032998e2d624 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------442003c1b53fea4273b5e8261d1b5e1fed421d5b9f717560147700cce0069004"; 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="kf/13yTh"; spf=pass (google.com: domain of conduition@proton.me designates 109.224.244.18 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: -0.4 (/) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------442003c1b53fea4273b5e8261d1b5e1fed421d5b9f717560147700cce0069004 Content-Type: multipart/mixed;boundary=---------------------62bf685ff5328b00dc0f0d1bae6f9d3f -----------------------62bf685ff5328b00dc0f0d1bae6f9d3f Content-Type: multipart/alternative;boundary=---------------------53a85936325f78fd11dddc5852d49201 -----------------------53a85936325f78fd11dddc5852d49201 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Hey Boris and list, > What if all vulnerable coins are temporarily locked during phase B, with = a clearly defined future block height X (e.g., in 5-10 years) at which poin= t these coins become EC-spendable again? Great idea. It gives us more time to get the zk-STARK proof system for phas= e C tightened up, but we still have the option of deploying phase B indepen= dently to protect procrastinators against a fast-arriving quantum adversary= , even if the STARK system isn't ready yet. If quantum progress is slower (= or phase C development is faster) than anticipated, we also have the option= to merge the phases B and C together into a single deployment. If we do that, should we apply the same logic to phase A though, and eventu= ally permit sending to pre-quantum addresses at height X? Because as descri= bed, once phase A is locked in, we can never again permit sending to pre-qu= antum addresses (without a hard fork). Maybe we should also talk about BIP360 P2QRH addresses and how they'd be tr= eated by these phases. As Ethan pointed out, P2QRH addresses can contain EC= signature spending conditions (OP_CHECKSIG). Would phase B's stricter rule= s also block EC spends from P2QRH UTXOs? If yes, and phase B restricts EC spending from P2QRH, users may accidentall= y send money to P2QRH addresses whose leafs all require at least one EC sig= nature opcode. This locks the money up until phase C, even though the purpo= se of phase A was to avoid exactly this from happening. Restricting P2QRH E= C spending also makes hybrid spending conditions, which require both EC sig= natures and=C2=A0PQ signatures for extra safety, harder to implement explic= itly in P2QRH script - We'd need dedicated EC/PQ hybrid checksig opcodes (w= hich is an option if we want it). If no, and phase B doesn't=C2=A0restrict EC spending from P2QRH, then P2QRH= UTXOs with exposed EC spending leafs will be even more vulnerable to a qua= ntum attacker than those who have exposed pubkeys in pre-quantum UTXOs: Pre= -quantum UTXOs would have better protection, since they are temporarily loc= ked by phase B but P2QRH UTXOs aren't. Personally i think phase B should restrict ALL EC spending across all scrip= t types, because at least then users can eventually reclaim their BTC when = phase C rolls out. We can ameliorate the situation by properly standardizin= g P2QRH address derivation, providing libraries to generate addresses with = ML-DSA and SLH-DSA leafs. We should recommend strongly against=C2=A0creatin= g P2QRH addresses without at least one post-quantum spending path. To better support hybrid spending conditions in P2QRH, we should modify pha= se B as follows: Fail any EC checksig opcode unless at least one PQ checksi= g opcode was executed earlier in the script. This implicitly blocks spendin= g of pre-quantum UTXOs (until the predefined height X as Boris suggested). = P2QRH addresses can explicitly define flexible hybrid signature schemes in = the P2QRH tree using a two-leaf construction: one leaf with just=C2=A0`OP_C= HECKSIG`, and one leaf with both=C2=A0`OP_CHECKSIG` and a PQ checksig opcod= e (such as `OP_MLDSACHECKSIG`). To nodes who have upgraded to phase A (or earlier), funds sent to this addr= ess could be unlocked with the `OP_CHECKSIG` branch using a relatively smal= l witness stack. On the other hand, nodes upgraded to phase B would reject = the `OP_CHECKSIG`-only branch, because there is no PQ-checksig opcode in th= e same script. Phase B nodes require the=C2=A0`OP_MLDSACHECKSIG + OP_CHECKS= IG`=C2=A0branch to validate the spend. This branch needs a much larger witn= ess stack, but would still permit a hybrid spend, covered by the combined s= ecurity of Schnorr + Dilithium. regards, conduition --=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/= gSvbx255CIbMSivfsn-1cGECh7UpJufvfVP4lwnp5r7gIamZo9t5LdBZBEYyiw4Eb9zNSvLXoi2= SW8Sq3i7shSwBkWwxLRjoPkncexfCPRM%3D%40proton.me. -----------------------53a85936325f78fd11dddc5852d49201 Content-Type: multipart/related;boundary=---------------------23e536eee94a34b1ab8b657456532477 -----------------------23e536eee94a34b1ab8b657456532477 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Boris a= nd list,

What if all vulnerable coins are temporarily locked during ph= ase B, with a clearly defined future block height X (e.g., in 5-10 years) a= t which point these coins become EC-spendable again?

Great idea. It gives us more time to get the zk-STARK proof system = for phase C tightened up, but we still have the option of deploying phase B= independently to protect procrastinators against a fast-arriving quantum a= dversary, even if the STARK system isn't ready yet. If quantum progress is = slower (or phase C development is faster) than anticipated, we also have th= e option to merge the phases B and C together into a single deployment.

If we do t= hat, should we apply the same logic to phase A though, and eventually permi= t sending to pre-quantum addresses at height X? Because as described, once = phase A is locked in, we can never again permit sending to pre-quantum addr= esses (without a hard fork).

Maybe we should also talk about BIP360 P2QRH addresse= s and how they'd be treated by these phases. As Ethan pointed out, P2QRH ad= dresses can contain EC signature spending conditions (OP_CHECKSIG). Woul= d phase B's stricter rules also block EC spends from P2QRH UTXOs?
=

<= div style=3D"font-family: Arial, sans-serif; font-size: 14px;">If yes, and = phase B restricts EC spending from P2QRH, users may accidentally send money= to P2QRH addresses whose leafs all require at least one EC signature opcod= e. This locks the money up until phase C, even though the purpose of phase = A was to avoid exactly this from happening. Restricting P2QRH EC spending a= lso makes hybrid spending conditions, which require both EC signatures a= nd PQ signatures for extra safety, harder to implement explicitly = in P2QRH script - We'd need dedicated EC/PQ hybrid checksig opcodes (which = is an option if we want it).

If no, and phase B doesn't restrict EC sp= ending from P2QRH, then P2QRH UTXOs with exposed EC spending leafs will be = even more vulnerable to a quantum attacker than those who have exposed pubk= eys in pre-quantum UTXOs: Pre-quantum UTXOs would have better protection, s= ince they are temporarily locked by phase B but P2QRH UTXOs aren't.

Personally i t= hink phase B should restrict ALL EC spending across all script types, beca= use at least then users can eventually reclaim their BTC when phase C rolls= out. We can ameliorate the situation by properly standardizing P2QRH addre= ss derivation, providing libraries to generate addresses with ML-DSA and SL= H-DSA leafs. We should recommend strongly against creating P2QR= H addresses without at least one post-quantum spending path.

To be= tter support hybrid spending conditions in P2QRH, we should modify phase B = as follows: Fail any EC checksig opcode unless at least one PQ checksig opc= ode was executed earlier in the script. This implicitly blocks spending of = pre-quantum UTXOs (until the predefined height X as Boris suggested). P2QRH= addresses can explicitly define flexible hybrid signature schemes in the P= 2QRH tree using a two-leaf construction: one leaf with just OP_CHECKSIG=E2=80=8B, and one leaf with both OP_CHECKSIG=E2=80=8B and <= /i>a PQ checksig opcode (such as OP_MLDSACHECKSIG=E2=80=8B).

To nodes who have upgraded to phase = A (or earlier), funds sent to this address could be unlocked with the OP_CHECKSIG=E2=80=8B branch using a relatively small witness stack.= On the other hand, nodes upgraded to phase B would reject the OP_CHE= CKSIG=E2=80=8B-only branch, because there is no PQ-checksig opcode i= n the same script. Phase B nodes require the OP_MLDSACHECKSIG + = OP_CHECKSIG=E2=80=8B branch to validate the spend. This branch = needs a much larger witness stack, but would still permit a hybrid spend, c= overed by the combined security of Schnorr + Dilithium.


regards,
conduition

--
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/gSvbx2= 55CIbMSivfsn-1cGECh7UpJufvfVP4lwnp5r7gIamZo9t5LdBZBEYyiw4Eb9zNSvLXoi2SW8Sq3= i7shSwBkWwxLRjoPkncexfCPRM%3D%40proton.me.
-----------------------23e536eee94a34b1ab8b657456532477-- -----------------------53a85936325f78fd11dddc5852d49201-- -----------------------62bf685ff5328b00dc0f0d1bae6f9d3f 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== -----------------------62bf685ff5328b00dc0f0d1bae6f9d3f-- --------442003c1b53fea4273b5e8261d1b5e1fed421d5b9f717560147700cce0069004 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wrsEARYKAG0Fgmh31psJkHgpbO2E9rPFRRQAAAAAABwAIHNhbHRAbm90YXRp b25zLm9wZW5wZ3Bqcy5vcmctw708EFxBLldnUatDgrcJfYmwNLE1/0MQsEE9 c8pIdRYhBEdIka0CMtrLdg13a3gpbO2E9rPFAAAwRQD+P5dYguAthYzDPC2W bHKWIQBGnO5XHpGcvIK1iMq/RCAA/Rt0xN4anIqGo4wyzIjBb3zw1+zAN5vK Uph0EQOybwsG =zzDi -----END PGP SIGNATURE----- --------442003c1b53fea4273b5e8261d1b5e1fed421d5b9f717560147700cce0069004--