From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 27 Feb 2026 13:21:53 -0800 Received: from mail-oo1-f57.google.com ([209.85.161.57]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vw5HU-0001KA-Pi for bitcoindev@gnusha.org; Fri, 27 Feb 2026 13:21:53 -0800 Received: by mail-oo1-f57.google.com with SMTP id 006d021491bc7-67999892f00sf56918323eaf.3 for ; Fri, 27 Feb 2026 13:21:52 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1772227306; cv=pass; d=google.com; s=arc-20240605; b=LhyaV3Xw0GjAymYzMa6E8cgWbLUTjZEpIjrHTrGNmJx5D92xt5BvuflfRsFPCOGmyZ Wkdo5SWuo+4F02MBvVzI6weVHFzvL4+GoKOdTX14UMljRqvzb9N1qvQyV8axqCGJmYJV xLaxti5elVZ0I+9L/BSx9AmGfhBrTLuXvU6mwjaebVhlIM3c8cOtEA72+uSR7TDz7n4X l11dF0Qt3vEpbvIxcY03niWtM7gAAa6gMyicjTVvAEs9o+eLqbsvspdV1xmI2mOpF5fr JQ5YONZy6xIuGEGL/hS4iZF6js+VWdCLzDKz4aJrTfx78oby+I37/jWMYgcAnxs6NXSh uIIA== 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=7bmCsI+kMxeYdJXxaAByxz69vVJUa3tPqHmYatSG8jw=; fh=Ofwfnrcj4Gi1vO4w2mB6d2kGq3RozUhLdMB3YLu6kTU=; b=Z8RKDCpxVd9O5a3FmlVyWR5boV8cL2FNOy0lBaFiPYo0SlAjuZe5PvkPa1skONTysc CxzKBcoF7e0CN7XsCV4oxVBcYDxthFko6j3ypfczFX4sHwzlEf7iBnIPxsnA4bURLX+R ZabflR4X/QXWjAuesjrdTNcjiQCkKV1sThdcnRDYn12tr1PwiY7yediRHBVxkiIqzyWH Rjn1t6UG3JVMaxzS1NVRqJxqb8wjrVShLPhwG4QXeuiejWq+40VmSdrKzhJew59zmM7R EjVto/kxohvLSZixiIyg/3b6JuSVtyEEh/tsS7gBKfWVr9SNbf83Kx/6UORk6y2x+dkT YmVg==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=eh3hrpveona3hbt4z7rup5f47a.protonmail header.b=ZIUMX2M+; spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.104 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=1772227306; x=1772832106; 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=7bmCsI+kMxeYdJXxaAByxz69vVJUa3tPqHmYatSG8jw=; b=p8DbpgPYVLyjtBfqFnM7dHMGlcLpaXUjvDgkStzVhGSKlyrEW4piwmWZBzl6t91oVq eumnASy3bb7FKs3S8C/bZIyIMkqpSi+70pgvJZq7yG8B9jUoMqIx7FcY5sHLAUlwzoH2 y+F8/1RaLruyiZ2Ob2hkQRmwrsCffWH9NmFpkA+3W1XWkvwLG01cqgQPNvUrGrhlOXm6 Znhl6yG9p99ZLr1gvUPwLG53jyrtJL40zX6NZEjn+EfoZFYY9idGngZaPrT/nVZohrX6 Ae5wCIiv9C15ppjIRBAq0r7fb1MK4n8wD8DuZdPaJqU7WIvUrYvXYvyEvLoYRD1msf22 T/IQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772227306; x=1772832106; 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=7bmCsI+kMxeYdJXxaAByxz69vVJUa3tPqHmYatSG8jw=; b=Vr2bJ1zD4hyMViD07VSg12AydQ7zbTWQRkirOkTD+ZmF76T1NWJOtGncUtpBe5lDMb OpkDBUbrAuJRFcVxLl4yY6Ygk7IX+DGbtSfBH9IG5Qr38fn1YVpA4ZOCwAY0hguzDfqx GUqrSQ1gE7lR3ycAU3+6DIFChXaA+1BavWozcWvzA8/EJ0LxPGpSjapKsh2DGfjZ+naL rCJVsko+lqp1uQ2GNA4Ldn9bDhb0psUlp6fORsCvFMWYjHn7hW8mPuXVxES/qa3LCAos ObwdWnNa+n+woun+2et/q9zoT9f1YIROqCs1sUNAs+BiLhGXL7tG18Nkdd58nQcmPVzK 6ScQ== X-Forwarded-Encrypted: i=2; AJvYcCUmovlO2Ai6zDTMp2LeBGc3rn0w/9FVzJhYiRXTEBU0sZ5MVP1r0divw8fj8hPI+7YgU1bVQSWwMSvv@gnusha.org X-Gm-Message-State: AOJu0YyH0q0xW7SdG5eaIpLe+xWjciZF6PTG8lXVmA6MS6VYREIGpJPJ 9EwTjXH1uSKiCnVmJJcqlrLL+fMEK14L8Jb+Y2Tmb1oGQFXUvP6of3fa X-Received: by 2002:a05:6870:1642:b0:404:406d:97f0 with SMTP id 586e51a60fabf-41626fb9e88mr2861856fac.29.1772227306002; Fri, 27 Feb 2026 13:21:46 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+E1Ejw2+w12Kr2IN/IpBdvsjy6kpHv0vSWnKdfLleupPQ==" Received: by 2002:a05:6870:c0cc:b0:3e8:4817:7a50 with SMTP id 586e51a60fabf-415f07722cels1710896fac.0.-pod-prod-05-us; Fri, 27 Feb 2026 13:21:39 -0800 (PST) X-Forwarded-Encrypted: i=2; AJvYcCUPp/UO1neMfWN7UqZqzVdXU1F6LaM/QmP9+eun9+4hluJN8+SvMJmvs/Yslu055qbMkS98O9txJOKH@googlegroups.com X-Received: by 2002:a05:6808:318c:b0:45e:e173:f9ac with SMTP id 5614622812f47-464bec48242mr2786610b6e.55.1772227299061; Fri, 27 Feb 2026 13:21:39 -0800 (PST) Received: by 2002:ab3:115:0:b0:2d1:a602:e60f with SMTP id a1c4a302cd1d6-2f03fbd085amsc7a; Fri, 27 Feb 2026 11:31:24 -0800 (PST) X-Forwarded-Encrypted: i=2; AJvYcCXgA8cVtKfsI6Sv/AXARo9YSiZRpWUbuK4Yz69C3wy7lYapf0oe7ujtqavCByxWM4FquAk7SdrhJ3CV@googlegroups.com X-Received: by 2002:a05:651c:211c:b0:38a:27e:b904 with SMTP id 38308e7fff4ca-38a027ebb10mr20578481fa.4.1772220681837; Fri, 27 Feb 2026 11:31:21 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1772220681; cv=none; d=google.com; s=arc-20240605; b=ZWHtpERJCukLipVDEfaLzpN+eOfwF1+3jILKoTQJo0uHI6Wq1oSLMGSLVOppSiz2S6 DQ6Z24xCCp7Mf9fWgQEvfyhV2m+F7oq0z1DjyvcNdwvUHooLqlTW9lZ1NLVP9KJdlYCz jH+09hwY/amu5nFt5pELAS9ZUNJv0b5qXFQBq8JgvEtwE7DtRTtDrcPc7pkFBHYdwRNA vRmsaON8bUUWTgNfxssgR/MllRCkH/7q9Fcbzp7Dt0ezpPLfUsf2+qlutkIBG8NkL2/I GlNT6/s2C3hQo5Cv9HPpXfcUcZ97QiTkdiPuh9sBPUIo29C0yUXtZwwF47z7QPgUjU9e 1WXA== 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=WLY18NivFhT908nJx5mLdml+bXBQQJRzSn0SUi7WDRA=; fh=U1MteajMul5S3GOGR3OVntyyjrE+k3ay5b5KGhJMZh0=; b=NtM3eYvG4gOSJHBqq/4K3d64BIZA7PiXuopQzRw+o2OXOfxRrVcckC/kGlBRcvxZ73 4OoUZFEHQh9jDj/6RdkIe7YMF70aKfRA2xkI284faO8jgiJPhLGymmAIyoY3AB4wZjzW ntoDlQs2Vk+9NarH5WJnrEesEXDhpni7Epw+2lXUoDIXIV2r7oWRA3GaGYXTSa1t66nO wT7IBd3MF3F6EckQrAC+NFPDiNDY0CTrFNP8MJKadmnSa9IBaeFKn64VqLfFiIL1TVIe uoPeozhQa8+CG6+68tTwUzGpMVIls2m3jh7DiK2iJOMkdHSOykJ2sEiKe5GXsDYvyzv6 QO2w==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=eh3hrpveona3hbt4z7rup5f47a.protonmail header.b=ZIUMX2M+; spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.104 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me Received: from mail-106104.protonmail.ch (mail-106104.protonmail.ch. [79.135.106.104]) by gmr-mx.google.com with ESMTPS id 2adb3069b0e04-5a1093779e0si124201e87.2.2026.02.27.11.31.21 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 Feb 2026 11:31:21 -0800 (PST) Received-SPF: pass (google.com: domain of conduition@proton.me designates 79.135.106.104 as permitted sender) client-ip=79.135.106.104; Date: Fri, 27 Feb 2026 19:31:16 +0000 To: Erik Aronesty From: "'conduition' via Bitcoin Development Mailing List" Cc: "garlonicon@gmail.com" , Ethan Heilman , Jonas Nick , bitcoindev@googlegroups.com Subject: Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms Message-ID: In-Reply-To: References: Feedback-ID: 72003692:user:proton X-Pm-Message-ID: fc4eb55f0620110bede5a6ec9d229cc250ede985 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------b648699aa5506592578a78b53d4529443cc0ae3034e76c3bb329e8190ff0924a"; 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=eh3hrpveona3hbt4z7rup5f47a.protonmail header.b=ZIUMX2M+; spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.104 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.0 (++) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------b648699aa5506592578a78b53d4529443cc0ae3034e76c3bb329e8190ff0924a Content-Type: multipart/mixed;boundary=---------------------21cd99aa2f3902183f746fe7b3810566 -----------------------21cd99aa2f3902183f746fe7b3810566 Content-Type: multipart/alternative;boundary=---------------------fc2b0115fabaec7f43ad0ceac654ef3c -----------------------fc2b0115fabaec7f43ad0ceac654ef3c Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" > I thought "tweaking", in general, is lost in SPHINCS, as well as multipar= ty sigs. Be interested to see those solutions. This is correct, but you don't actually need public-key tweaking to use an = SLH-DSA pubkey as a backup for an ECC xpub. You can just append the SLH-DSA= public key to a BIP32 xpub, and use the result to construct PQ-hybridized = child addresses. For privacy we can attach a pseudorandom nonce derived fro= m the chaincode, to prevent on-chain fingerprinting of unused BIP360 leaves= . The resulting tap leaf hash looks random, and the SLH-DSA public key (and= nonce) is only revealed if used for spending.=C2=A0 All this will be spec'd out as part of a non-consensus BIP, to help wallets= build safe and robust quantum-resistant addresses. > I provided an example script that shows how it works: https://gist.github= .com/earonesty/ea086aa995be1a860af093f93bd45bf2. you don't pin to the final= destination in phase 0. This pseudocode seems to commit the CTV hashes T & E in the anchor_script= =C2=A0which is used to construct the funding UTXO. This is exactly the prob= lem I mentioned which would prevent this technique from being usable as a P= Q fallback script. > txhash is a partial-commitment, not over all fields. this give the flexib= ility needed for the final spend, since you don't commit to it. You've stated specifically in your post that TXHASH enforces that the `Anch= orPublishTx` creates a UTXO paying to `P_anchor`. > OP_TXHASH is used only in Phase 0 to enforce a partial covenant... [that]= =C2=A0pins the next envelope (P_anchor) You've also stated that=C2=A0`P_anchor` commits to the CTV template hashes= =C2=A0`T` &=C2=A0`E`.=C2=A0 > P_anchor: Taproot output key committing to an Anchor script tree that ...= =C2=A0enforces reveal-or-escape spending conditions This statement is backed up by the pseudocode which depends on=C2=A0`T` and= `E` when constructing `P_anchor`, as i pointed out earlier in this email. Thus, TXHASH (and by extension, the funding script pubkey) commits to CTV h= ashes=C2=A0`T` &=C2=A0`E`, yes? Perhaps it would help if you mentioned which `TxFieldSelector` you are usin= g, otherwise i'm just left to guess. The pseudocode is unclear. regards, conduition On Monday, February 23rd, 2026 at 11:08 AM, Erik Aronesty wr= ote: > >=20 > >=20 > > I'd be excited to learn about this as an option. Erik, could you please= answer my previous questions about the viability of your linked protocol? = I'm not questioning its quantum-resistance properties (yet). I'm wondering = how it is possible to instantiate this scheme in a way that allows a wallet= to actually use this commit/reveal scheme without knowing the final destin= ation CTV templates (denoted T & E in the delving post) in advance of creat= ing the phase 0 locking script. >=20 >=20 > I provided an example script that shows how it works: https://gist.github= .com/earonesty/ea086aa995be1a860af093f93bd45bf2. you don't pin to the final= destination in phase 0. >=20 > txhash is a partial-commitment, not over all fields. this give the flexib= ility needed for the final spend, since you don't commit to it. >=20 > however someone has pointed out a fee-problem that CCV's value-aware comp= osability can solve. coming around to thinking the ccv-based construction w= ould be necessary. CCV is more powerful but requires much more care in poli= cy and analysis. CTV is trivial, we could merge it tomorrow and hardly worr= y about surface area issues. TXHASH is only slightly more complicated. CCV = has a much bigger burden of proof around implementation and node safety... = but i think you could do many kinds of vaulting schemes with it alone. >=20 >=20 >=20 > > But in the case of hash-based signature (HBS) schemes, i disagree. HBS = is already mature. Whatever cryptanalytic breakthroughs the future holds, w= e can be reasonably sure that SHA256 preimage resistance will hold for a lo= ng time, so HBS security will hold. Even today md4 and md5 preimage resista= nce still holds. Securing coins using hashes alone is the ideal fallback, a= nd even if HBS is not the most efficient class of schemes, that doesn't mat= ter so much if we don't use HBS as our primary everyday signature scheme. I= ts value lies in security, not efficiency. >=20 >=20 > When I mean "too soon", I'm including SPHINCS, not sure what > 1. Earlier versions of the SPHINCS framework were found to be susceptible= to fault attacks > 2. Earlier "Tight" proof for v1 SPHINCS was flawed, leading to 60 bits of= security, not 128 > > If you're worried about stuff like how xpubs would work with HBS, we ha= ve solutions for that too, and they are mostly drop-in replacements for exi= sting standards. >=20 > I thought "tweaking", in general, is lost in SPHINCS, as well as multipar= ty sigs. Be interested to see those solutions. But, regardless, 17kb sigs a= re... not compatible with a decentralized bitcoin, imo. Lattice-sigs are th= e only reasonable PQ way forward and they aren't ready yet. --=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/= xGWRYbDSxkWxiv5eYH_LbX3hTXs1x2wrn6ar5EfMKKCwvRAT137keXQZqs9SaeTxOjrb5tziRcF= U82wSPGD-QVokCrA-Aikfr4vktqSvK7c%3D%40proton.me. -----------------------fc2b0115fabaec7f43ad0ceac654ef3c Content-Type: multipart/related;boundary=---------------------919b3a1de839f54261c60abc87137bb9 -----------------------919b3a1de839f54261c60abc87137bb9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I thought "tweaking", in general= , is lost in SPHINCS, as well as multiparty sigs. Be interested to see thos= e solutions.

=
This = is correct, but you don't actually need public-key tweaking to use an SLH-D= SA pubkey as a backup for an ECC xpub. You can just append the SLH-DSA publ= ic key to a BIP32 xpub, and use the result to construct PQ-hybridized child= addresses. For privacy we can attach a pseudorandom nonce derived from the= chaincode, to prevent on-chain fingerprinting of unused BIP360 leaves. The= resulting tap leaf hash looks random, and the SLH-DSA public key (and nonc= e) is only revealed if used for spending. 

All this will be spe= c'd out as part of a non-consensus BIP, to help wallets build safe and robu= st quantum-resistant addresses.

I provided an examp= le script that shows how it works: https://gist.github.com/earonesty/ea086aa995be1a860af093= f93bd45bf2. you don't pin to the final destination in phase 0.

This pseudocode see= ms to commit the CTV hashes T & E in the anchor_s= cript which is = used to construct the funding UTXO. This is exactly the problem I me= ntioned which would prevent this technique from being usable as a PQ fallba= ck script.

t= xhash is a partial-commitment, not over all fields. this give the flexibili= ty needed for the final spend, since you don't commit to it.

You've stated specifically in your post that TXHASH enforces that the= AnchorPublishTx=E2=80=8B creates a UTXO paying t= o P_anchor=E2=80=8B.

OP_TXHASH is used only in Phase 0 to enforce a partial covenant...= [that] pins the ne= xt envelope (P_anchor)

You've also stated that P_anchor=E2=80=8B commits= to the CTV template hashes T=E2=80=8B &&nbs= p;E<= /code>=E2=80=8B. 

P_anchor: Taproot output key committing to an Anchor sc= ript tree that ... enforces reveal-or-escape spending conditions=

This stateme= nt is backed up by the pseudocode which depends on T=E2= =80=8B and E=E2=80=8B when constructing P_anchor= =E2=80=8B, as i pointed out earlier in this email.

Thus, TXHASH (and by extension= , the funding script pubkey) commits to CTV hashes T=E2=80=8B & E=E2=80=8B= , yes?

Perhaps it would= help if you mentioned which TxFieldSelector=E2=80=8B you are = using, otherwise i'm just left to guess. The pseudocode is unclear.

regards,
conduition

=
On Monday, February 23rd, 2026 at 11:08 AM, Erik Aronesty <erik@= q32.com> wrote:


I'd be excited to learn about this as an option. Erik, could you pl= ease answer my previous questions about the viability of your linked protoc= ol? I'm not questioning its quantum-resistance properties (yet). I'm wonder= ing how it is possible to instantiate this scheme in a way that allows a wa= llet to actually use this commit/reveal scheme without knowing the final de= stination CTV templates (denoted T & E in the delving post) in advance = of creating the phase 0 locking script.

<= /div>
I provided an example script that shows how it works: https://gist.github.com/ea= ronesty/ea086aa995be1a860af093f93bd45bf2. you don't pin to the final de= stination in phase 0.

txhash is a partial-commitment, not over all f= ields. this give the flexibility needed for the final spend, since you don= 't commit to it.

however someone has pointed out a fee-problem th= at CCV's value-aware composability can solve. coming around to thinking t= he ccv-based construction would be necessary. CCV is more powerful but re= quires much more care in policy and analysis. CTV is trivial, we could mer= ge it tomorrow and hardly worry about surface area issues. TXHASH is only= slightly more complicated. CCV has a much bigger burden of proof around i= mplementation and node safety... but i think you could do many kinds of vau= lting schemes with it alone.


But in the case of hash-based s= ignature (HBS) schemes, i disagree. HBS is already mature. Whatever cryptan= alytic breakthroughs the future holds, we can be reasonably sure that SHA25= 6 preimage resistance will hold for a long time, so HBS security will hold.= Even today md4 and md5 preimage resistance still holds. Securing coins usi= ng hashes alone is the ideal fallback, and even if HBS is not the most effi= cient class of schemes, that doesn't matter so much if we don't use HBS as = our primary everyday signature scheme. Its value lies in security, not effi= ciency.

When I mean "too soon", I'm including SP= HINCS, not sure what

1. Earlier versions of the SPHINCS framework were found to be susceptible t= o fault a= ttacks
2. Earlier "Tight" proof for v1 SPHINCS was flawed, leading to 60= bits of security, not 128

> If you're worried about stuff= like how xpubs would work with HBS, we have solutions for that too, and th= ey are mostly drop-in replacements for existing standards.

I thought "tweaking", in general, is lost in SPHINCS, as well as m= ultiparty sigs. Be interested to see those solutions. But, regardless, 1= 7kb sigs are... not compatible with a decentralized bitcoin, imo. Lattice= -sigs are the only reasonable PQ way forward and they aren't ready yet.

--
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/xGWRYb= DSxkWxiv5eYH_LbX3hTXs1x2wrn6ar5EfMKKCwvRAT137keXQZqs9SaeTxOjrb5tziRcFU82wSP= GD-QVokCrA-Aikfr4vktqSvK7c%3D%40proton.me.
-----------------------919b3a1de839f54261c60abc87137bb9-- -----------------------fc2b0115fabaec7f43ad0ceac654ef3c-- -----------------------21cd99aa2f3902183f746fe7b3810566 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== -----------------------21cd99aa2f3902183f746fe7b3810566-- --------b648699aa5506592578a78b53d4529443cc0ae3034e76c3bb329e8190ff0924a Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wrsEARYKAG0Fgmmh8PUJEHgpbO2E9rPFRRQAAAAAABwAIHNhbHRAbm90YXRp b25zLm9wZW5wZ3Bqcy5vcmc9kSUe0HK1gcemarTi1v8KrQmFy6wOd0pD2tX0 D1xiLRYhBEdIka0CMtrLdg13a3gpbO2E9rPFAAAPpAD/ZgF0qI6XY8r5Nu3l 4QC56Q6e62DsvlM2NE3K0DTH9sABAIqmXyUETjzkzEkVitiZvV1xFy1P7R5G ynIczlUorikL =ySZ0 -----END PGP SIGNATURE----- --------b648699aa5506592578a78b53d4529443cc0ae3034e76c3bb329e8190ff0924a--