From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 18 Jan 2026 15:33:52 -0800 Received: from mail-ot1-f62.google.com ([209.85.210.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 1vhcHH-0007vS-L8 for bitcoindev@gnusha.org; Sun, 18 Jan 2026 15:33:52 -0800 Received: by mail-ot1-f62.google.com with SMTP id 46e09a7af769-7c6cb7bf71bsf5969634a34.0 for ; Sun, 18 Jan 2026 15:33:51 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1768779225; cv=pass; d=google.com; s=arc-20240605; b=Jc0fSvnH0eUwwnTtN6LnjQKis/fEdVN2KbYWH5BhygfV2i3plhd37xywmIUuUBtKlI ajBLdhbiMTxB10WvaptpfUVW4KngQsRyM0MPpqjcshfH+nWK3yZOmGUxzTE51M9fhf/k fj86qgBGH8RZ9vfbN0GDclqj45m7sz8x3ihFKhc9zYjVpSH8Hx04uFMv6MRGZQT4wY4K AOMHIbhh1imizxhd6RK8gYBQ210EaHH12WaCVzJRl7RTvBA5EkP8XV/+buYMTXT+Mcbi hhOWJf8pncV8gKkJBjg40ZDamI//x2/lbVFXUgZzi0/iMhdBabyT/A1acaENcjmMzLLC VCaQ== 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=FV3p3bzO9UW8+YYkqMMOrvjVYB+NwoUyR/vhMdnN5+o=; fh=NpATmscFDdR/wyCriCCQWIYNHTzpwaCV8mF2C/OBK3k=; b=OKDcV2WhsLz6CD/Ahrt1CXodAXQSkKA0nDhSwX1ppr04sBvI8pd1KfcQ8ZlRv/cPhC mKqcRAUd5o9eiychnd5CqtPCSUwn6nWaOF3r2/OEq/4SZPTD7qJGCEUgsdRxLpe7I6Sh Rx8kaKtADdP5kbfuyd5klcKNnVkLgn6O+DMZwS7wGzdZIkMnOexPd31WC19M9+8oU0kX aWb4ju0OVyw6quZOw6S7exfl5n8wwLA7QyeqTJWIyz/hRtcdlLdT8aTOgydBh047jyEN t9fszM2q8XhS/zW2wBg49B8NuH6gL2ftD6HkK9Ck7Fd8KX0o11kefNJe4j5aDuk0VU8S bKDw==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=Pjt4lSyk; spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.102 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=1768779225; x=1769384025; 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=FV3p3bzO9UW8+YYkqMMOrvjVYB+NwoUyR/vhMdnN5+o=; b=oCHqfVludIzuh8XiSx4zznxELU5v5ARdcpT2DKy5Na5SpYhDE1rz7zUAWHrRc+8tsI 18CHo9xZoQbJV0KAksWDIto8ypdjohM9SYsaHQaDW+OJ8jly2KOlKTGGqrL7LFgoG0Ke 8HBKIjfW0Oq94XXyJGr6Ypic48MNERusPWmGreQFgQ++XJuuRJ8MmttvDVlSxryPLGDA XtYjeBF9LbqtoDkuqMqBl2aX4k1z6P9Rqc2HaZ0YlwIGSTwkhHtCVoDZs4zjzaPJ9wK3 XNLC2PNdxeVBZBXYkvnpPjeIuOE8IHaQqpgEq/FY5FpXRXdZIUfwoRHPuSiuq+IwfKTb a3UQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768779225; x=1769384025; 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=FV3p3bzO9UW8+YYkqMMOrvjVYB+NwoUyR/vhMdnN5+o=; b=Mn07i3D9KAOoBHRZ+r/FpT5spms81v6HIpiCumXasUH80GOoI4IXLojivDBXlykkNc EEBHBV31J9t4gIgMcr8JDBRv+9O+c7swsJFbZEd4ulEt0gHG+gs+GQccBcwvQDz8OD5w MKNUbHzoOWIlfUehNjMySCidhBNerYoYPy51rupG9JBtKO1sC6PqfRKdRrdIM26ykj3I VbRTdHltX+t2VFDaFOovYDWHj80eAnJ778obfRQVDuvGGkUIeIw1BqMFqxh56XUNeQxR Fm9NfUy5cult+KA0pZytMXDh75L7SUCYkti3RMBZEaWgL5gZiT6mGhdt4TLmPD/nokCT IpTw== X-Forwarded-Encrypted: i=2; AJvYcCXJ7w4sHgMr1JT5xK8jFraNo4p1BTcDINcclQvpaDEV9sTrw4Eyb9eYdHNnYsY1CJSaPuPIAJLbzUyA@gnusha.org X-Gm-Message-State: AOJu0Yy7C23LdWm7e4VJhic5MHVAUYlxZeyJtGV++zD4ylTuTMHlSmO+ iVyVvbDZADubZxR/o8gyYpIizVhnIbt9nNBQNnGAMZoPjVN+mu2SSN39 X-Received: by 2002:a05:6820:2225:b0:65d:6ed:e065 with SMTP id 006d021491bc7-661189ad24fmr4152016eaf.58.1768779224676; Sun, 18 Jan 2026 15:33:44 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+H4Dz8k7e8nsAuZ74W0dZb/O/Z+hwb/pUsAxxXpovM9CA==" Received: by 2002:a05:6870:11c4:b0:315:8af6:e4ed with SMTP id 586e51a60fabf-40428a06104ls2052315fac.2.-pod-prod-05-us; Sun, 18 Jan 2026 15:33:39 -0800 (PST) X-Received: by 2002:a05:6808:80a7:b0:450:ca65:ef60 with SMTP id 5614622812f47-45c9d86e9a1mr3730709b6e.39.1768779219756; Sun, 18 Jan 2026 15:33:39 -0800 (PST) Received: by 2002:a05:600c:5893:b0:477:99f7:45de with SMTP id 5b1f17b1804b1-4801fe64772ms5e9; Sun, 18 Jan 2026 15:11:24 -0800 (PST) X-Received: by 2002:a05:6000:2289:b0:430:fd69:9926 with SMTP id ffacd0b85a97d-4356999bb7emr11949921f8f.28.1768777881872; Sun, 18 Jan 2026 15:11:21 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1768777881; cv=none; d=google.com; s=arc-20240605; b=iF3RTpCQRMeZxcHQAwsuhalQxpVmNKwTpw0WeJtUlPtB/xAE5peSoKf8zaAksGX+d9 om/beB4FhVhhV8gfAGSP5d+0tEaHOQ/KqSfIqLfDpIJhl9Bo8flXaMcgVpBX/KKwJOAh FwkayGBVU1RuWJlaGlJ5hMqAOvgwr8wnonoe3rKDu8Wt/bzrD99S1z4AsumYgPkxqey6 bpF44ZEiR+JEJ0UCYYFpXKncr5j1kODXHlFC6JhhPUVMTe+c5maipPK3FDyVh4Tg+FMl 5igUZ8u3037Wz44P+dx3INNIipHLN9bC3YbQpcHrVufDuyiwHQyo9saIeVtl0GXpQIxT eMkg== 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=NNPhNl9XAoGmorfSV41MqRGOmF2hzB63Mf44y7tU84c=; fh=t0xe4s6OwK/nag7dWixgc9y26E3m78ldPpNpzh4RGuU=; b=CMJjruFjzDOPI97OKYkhws0FdWg4kNjMi73zM0xverlZQPJ8+aMPyzN730lETQMLCU /6CQDz1FNl9abwCQQkEgK/9Q8iKsNtfar6wj+ABuNnjjXsys/0IUogP1x7mZXbwkXTgd mrls9flu4b4BzW1Nk03mV8/iO0X0p7UScPgRXQeWH1wN9SsjPzPA3XZf3SQCqN/8veMh /w3IRzMC4gX5QrlLwRh/zSXUGd1ZFdYNb+HcmbaW9xqHV3iB6vRr8pewzK6maH6RLE2Y zuf6m7R+zM4w0MPKtRtVzANLQcZOLceeaDbpQ52DGkvn+OotczfkMYwjqmhoEEsGlQaU Blpg==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=Pjt4lSyk; spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.102 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me Received: from mail-106102.protonmail.ch (mail-106102.protonmail.ch. [79.135.106.102]) by gmr-mx.google.com with ESMTPS id ffacd0b85a97d-435699263d6si149164f8f.4.2026.01.18.15.11.21 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 18 Jan 2026 15:11:21 -0800 (PST) Received-SPF: pass (google.com: domain of conduition@proton.me designates 79.135.106.102 as permitted sender) client-ip=79.135.106.102; Date: Sun, 18 Jan 2026 23:11:18 +0000 To: Erik Aronesty From: "'conduition' via Bitcoin Development Mailing List" Cc: Bitcoin Development Mailing List Subject: Re: [bitcoindev] Re: Perhaps the simplest possible quantum-security upgrade Message-ID: <6AzufPg5x941QjBsaCZIFaboRU_x1KVcs2Xn7gzmHVvZ7mlja6ldAs_-9skg521Nq6kAKjpvBQ6v4yD-bp599Z7qQYOYeT6XhywxtFuRBFY=@proton.me> In-Reply-To: References: Feedback-ID: 72003692:user:proton X-Pm-Message-ID: f59dfabe6edfb573b50d6c8215b44b79907c750c MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------a1d25a7757c019896c79bfe6a479c239b3852ad4b0445fe28ebe5acb09cd3c3f"; 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=Pjt4lSyk; spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.102 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) --------a1d25a7757c019896c79bfe6a479c239b3852ad4b0445fe28ebe5acb09cd3c3f Content-Type: multipart/mixed;boundary=---------------------f121fcb26e7c59db9e041657097bc81a -----------------------f121fcb26e7c59db9e041657097bc81a Content-Type: multipart/alternative;boundary=---------------------516c6bf5f6d53e947ddc855f50df57c0 -----------------------516c6bf5f6d53e947ddc855f50df57c0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Hey Erik, thanks for writing on this subject. While I don't think your solu= tion will work, commit/reveal protocols like this are a great backup plan i= n case we can't make the larger sizes of real post-quantum signing schemes = work at scale.=C2=A0 The main issue I see with your protocol as described is that unlike other c= ommit/reveal protocols, the "anchor tx" as you call it doesn't commit to th= e reveal TX at all. Once the reveal TX appears in the mempool, a quantum ad= versary could just copy the secret, invert the public key, and attempt to R= BF the reveal TX. Forgive me if the answer lies somewhere in your code, I don't fully underst= and what it's supposed to be doing. regards, conduition On Thursday, December 18th, 2025 at 8:49 PM, Erik Aronesty w= rote: > I wrote the python code for this. It was a little trickier to get it righ= t: >=20 > https://gist.github.com/earonesty/ea086aa995be1a860af093f93bd45bf2 >=20 > Spender publishes an ephemeral anchor tx committing to a future secret wi= thout revealing the secret in one block. >=20 > Spender publishes the revealed secret and spend in a future block. >=20 > New opcode needs to verify that the anchor tx was published at least N bl= ocks prior to the spend block. >=20 > This creates the necessary information asymmetry without being a true sig= nature, relying on asymmetry-over-time to protect against quantum threats. >=20 > On Wed, Dec 17, 2025 at 12:57=E2=80=AFPM Erik Aronesty wro= te: >=20 > > Was thinking about this and I realized that a quantum-resistance scheme= doesn't technically need a new "signature" - because those constraints (ge= nerality) are far harder than needed for Bitcoin's "proof of utxo ownership= ". > >=20 > > Instead of new signatures, I propose a chain-native authorization primi= tive whose security is bounded by the same economic assumptions as transact= ion finality itself. The objective is a quantum migration path that can be = deployed immediately, does not require large witnesses, remains cheap to va= lidate, and does not rely on assumptions stronger than those already requir= ed to trust confirmed spends. > >=20 > > The construction relies on a minimal new introspection primitive rather= than a wholesale redesign of Script. A single opcode exposes a chain-deriv= ed challenge tied to the spent output, defined as the block hash at a selec= table offset from the block in which the UTXO was created. The offset is fi= xed by the locking script and can be chosen to reflect the value at risk. L= arger offsets correspond to deeper confirmation depth and higher economic r= esistance to manipulation (an enforced confirmation wait). Existing timeloc= k opcodes already enforce the required delay; the only missing element is a= ccess to this chain-defined value. > >=20 > > This is commit=E2=80=93challenge=E2=80=93response (=CE=A3-protocol=E2= =80=93derived) authentication, but the challenge is provided by the future = chain. This is a well known scheme. > >=20 > > Authorization is conjunctive, not alternative. A valid spend must satis= fy both a traditional signature check and a delayed, chain-conditioned hash= -based proof. The traditional signature preserves today=E2=80=99s security = assumptions and compatibility, while the chain-conditioned proof adds a qua= ntum-resistant requirement that cannot be bypassed by a quantum adversary. = Either condition alone is insufficient. This ensures the scheme is strictly= at least as secure as current authorization and strictly stronger against = quantum-capable attackers. > >=20 > > The delayed component commits to randomness in advance and later reveal= s it combined with a hash of the chain-provided challenge. Verification con= sists only of checking the timelock, evaluating a hash operation, and verif= ying the traditional signature. There is no large witness, no algebraic str= ucture, and no expensive validation path. Failure requires the ability to b= ias or reorganize the chain across the selected confirmation window, which = is the same failure mode already implicit in transaction finality. > >=20 > > This design enables quantum migration without changing address formats,= inflating transaction sizes, or introducing fragile cryptographic assumpti= ons. It aligns authorization with the economic security model the system al= ready relies on and provides an enforceable, compact, and conservative quan= tum-resistance mechanism that can be adopted incrementally. > >=20 > > If anyone is interested in a BIP or further development of this securit= y construct, please let me know. > >=20 > > - Erik >=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/CAJowKgKcRN6QOKFdvMDdrZVcFGu%2BhrrCMiB%2BB9HVdM2RXphQAQ%40mail.gmail.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/= 6AzufPg5x941QjBsaCZIFaboRU_x1KVcs2Xn7gzmHVvZ7mlja6ldAs_-9skg521Nq6kAKjpvBQ6= v4yD-bp599Z7qQYOYeT6XhywxtFuRBFY%3D%40proton.me. -----------------------516c6bf5f6d53e947ddc855f50df57c0 Content-Type: multipart/related;boundary=---------------------1cba381e5730ef659c0ffae8fcc75dcf -----------------------1cba381e5730ef659c0ffae8fcc75dcf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Erik, t= hanks for writing on this subject. While I don't think your solution will w= ork, commit/reveal protocols like this are a great backup plan in case we c= an't make the larger sizes of real post-quantum signing schemes work at sca= le. 

The main issue I see with your protocol as described is that unlike othe= r commit/reveal protocols, the "anchor tx" as you call it doesn't commit to= the reveal TX at all. Once the reveal TX appears in the mempool, a quantum= adversary could just copy the secret, invert the public key, and attempt t= o RBF the reveal TX.

Forgive me if the answer lies somewhere in your code, I don't= fully understand what it's supposed to be doing.

regards,
conduition
=20
=20
=20

<= div class=3D"protonmail_quote"> On Thursday, December 18th, 2025 at 8:49 PM, Erik Aronesty <erik= @q32.com> wrote:
I wrote the python code for this. It was a li= ttle trickier to get it right:

https://gist.github.com/earonesty/ea086aa995be1a860af= 093f93bd45bf2

Spender publishes an ephemeral anchor tx committin= g to a future secret without revealing the secret in one block.

Spen= der publishes the revealed secret and spend in a future block.

New o= pcode needs to verify that the anchor tx was published at least N blocks pr= ior to the spend block.

This creates the necessary information asymm= etry without being a true signature, relying on asymmetry-over-time to prot= ect against quantum threats.


On Wed, D= ec 17, 2025 at 12:57=E2=80=AFPM Erik Aronesty <erik@q32.com> wrote:
=
Was thinking about this and I realized that a quantum-resistance scheme do= esn't technically need a new "signature" - because those constraints (gener= ality) are far harder than needed for Bitcoin's "proof of utxo ownership".<= /p>

Instead of new signatures, I propose a chain-native authorization pri= mitive whose security is bounded by the same economic assumptions as transa= ction finality itself. The objective is a quantum migration path that can b= e deployed immediately, does not require large witnesses, remains cheap to = validate, and does not rely on assumptions stronger than those already requ= ired to trust confirmed spends.

The construction relies on a minimal new introspection primitive rather = than a wholesale redesign of Script. A single opcode exposes a chain-derive= d challenge tied to the spent output, defined as the block hash at a select= able offset from the block in which the UTXO was created. The offset is fix= ed by the locking script and can be chosen to reflect the value at risk. La= rger offsets correspond to deeper confirmation depth and higher economic re= sistance to manipulation (an enforced confirmation wait). Existing timelock= opcodes already enforce the required delay; the only missing element is ac= cess to this chain-defined value.

This is commit=E2=80=93cha= llenge=E2=80=93response (=CE=A3-protocol=E2=80=93derived) authentication, but the challenge is provided by the future chain. This is= a well known scheme.

Authorization is conjunctive, not alternative= . A valid spend must satisfy both a traditional signature check and a delay= ed, chain-conditioned hash-based proof. The traditional signature preserves= today=E2=80=99s security assumptions and compatibility, while the chain-co= nditioned proof adds a quantum-resistant requirement that cannot be bypasse= d by a quantum adversary. Either condition alone is insufficient. This ensu= res the scheme is strictly at least as secure as current authorization and = strictly stronger against quantum-capable attackers.

The delayed comp= onent commits to randomness in advance and later reveals it combined with a= hash of the chain-provided challenge. Verification consists only of checki= ng the timelock, evaluating a hash operation, and verifying the traditional= signature. There is no large witness, no algebraic structure, and no expen= sive validation path. Failure requires the ability to bias or reorganize th= e chain across the selected confirmation window, which is the same failu= re mode already implicit in transaction finality.

This design enables quantum migration without changing address forma= ts, inflating transaction sizes, or introducing fragile cryptographic assum= ptions. It aligns authorization with the economic security model the system= already relies on and provides an enforceable, compact, and conservative q= uantum-resistance mechanism that can be adopted incrementally.

If an= yone is interested in a BIP or further development of this security constru= ct, please let me know.

- Erik

--
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://gr= oups.google.com/d/msgid/bitcoindev/CAJowKgKcRN6QOKFdvMDdrZVcFGu%2BhrrCMiB%2= BB9HVdM2RXphQAQ%40mail.gmail.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/6AzufP= g5x941QjBsaCZIFaboRU_x1KVcs2Xn7gzmHVvZ7mlja6ldAs_-9skg521Nq6kAKjpvBQ6v4yD-b= p599Z7qQYOYeT6XhywxtFuRBFY%3D%40proton.me.
-----------------------1cba381e5730ef659c0ffae8fcc75dcf-- -----------------------516c6bf5f6d53e947ddc855f50df57c0-- -----------------------f121fcb26e7c59db9e041657097bc81a 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== -----------------------f121fcb26e7c59db9e041657097bc81a-- --------a1d25a7757c019896c79bfe6a479c239b3852ad4b0445fe28ebe5acb09cd3c3f Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wrsEARYKAG0FgmltaIcJEHgpbO2E9rPFRRQAAAAAABwAIHNhbHRAbm90YXRp b25zLm9wZW5wZ3Bqcy5vcmfZCJRXaVyr3jvP1o1XTyNdjS99U1nqwvOakMK5 JsLTrRYhBEdIka0CMtrLdg13a3gpbO2E9rPFAACgNAEAm9htipQ0/uTPrSbF mInSu0TgctTOwS1a0aY2y2CWnUcBALxCG4Y7IF80tfElnTP5h++V+HtyhRbn 7/x4Vu8oWH4J =49tG -----END PGP SIGNATURE----- --------a1d25a7757c019896c79bfe6a479c239b3852ad4b0445fe28ebe5acb09cd3c3f--