From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 16 Apr 2026 11:08:03 -0700 Received: from mail-oo1-f58.google.com ([209.85.161.58]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wDR8D-0002Iv-Uf for bitcoindev@gnusha.org; Thu, 16 Apr 2026 11:08:02 -0700 Received: by mail-oo1-f58.google.com with SMTP id 006d021491bc7-672c40f3873sf22084506eaf.2 for ; Thu, 16 Apr 2026 11:08:01 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1776362875; cv=pass; d=google.com; s=arc-20240605; b=UEEdJkbGqERhbDQncqf4i0Gm5vEl+5VFj9R5+kjSDouhZ9QSsFYI7grAsxmwk8/xCt sRqkKSb214zPGM6A1t7QLsU4CTX+FYNKlgnLTRZueZM4TPgk1OE/SbofyAC0o4ZGk+nL W59OuBP37BEPoQRb4tZ0NRvUFziA6Q+amwR4nxmMXDX95Wu9DjnfIOJPXySX1LbNT6jj mZ+5RGiiziOIa6qcsfzTIm5cT4FzMaMtSeMqMYqbbfIZBgFx7jf20ILUVEOKak+nYeZO +ZKCRdq98GINMIAqEWYRHeKfeFOsEMHfsKTFCTA/mnR+1HoOExwexGtpKSje+126W5I4 laCA== 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=ODsOfEP2ABBCBq7CtG3KCwZC2tqVka3MHHs28riC4/c=; fh=BZ9sFWnpBw0hK0DEqArAOsvP9NNf1UToieI0K2+mFUc=; b=W1SgHF3tBmJ6hAPnECP2ujLlTuuMlXS20xnhQ2ZBO3g/p1g3BxcrM2NSzLhh70Ht36 JPX/3sMNH8j9Iz+jrDSxy7RgF22bxd8LCb9TdrMPhG1eYr78UdxeHHLvxogIE45eTtU0 deGta6yMUiYeVXNFuTHrmcC1E8SIYUkoXIZmOVwlUZ+8A7oqPVKwtTOkbsnGtnPHwkJ7 TIDDUE98aHwmSQeyB4HaDKM8OaP0AwhDHmlrbT7Ke937rjO9iUj6EBuGjNWgtDks97H9 6/7IVS3RMlEzboixpLsAvP47AQgfZDomf2A5CwK6gSLE9quCyqLvo0bW+whJHQWBpm5v MiPw==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=jD3u+uH9; 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=1776362875; x=1776967675; 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=ODsOfEP2ABBCBq7CtG3KCwZC2tqVka3MHHs28riC4/c=; b=osP2E9YdFsPZiamIy6nNrftxAc+08rXHtCv7W1gtLahCD3ncjPKTBP6JDePmDalKvM AW8o8j7Zge4fLFYUfB9nyljabauRbmwpSoZNL2qXUkgsbcvaAsR6RgbMJ1ADADz91uTb EWDrlMIirbragmjWdAgZ+oizHOwMXpdaXJQk12pbczvVV4XgWjQah0SkxVNV/0Yr0kgQ yhcCZDDPgkpRTmeFwRuHrlQqYtRMcwM3IDx8Ow+Q414pjm/Hz1yobJekSIayVBD6LgPs TcV3NKj5NIpXIQGOQh4toi8Xi90FfnJ1qzsuMee1XaFPhkpf0JbvvTxNwZFT2+726aJA Q4+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776362875; x=1776967675; 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=ODsOfEP2ABBCBq7CtG3KCwZC2tqVka3MHHs28riC4/c=; b=jBhL2BVfkvAhn3OWq158DCMwpxH/wDiarlLT0s4hZrkU7qlHm4y/MpIKCU3BTCdwMo Gm+pE/hUhCvOHevN3/GBiR1QmiCg2uanf7vxMnKu9+JC9SIc+wDKpihEirfDsCm5DCYk PovqEZKSpOtGDaEX67Ub6W9HGs1fYKX1u7bYqcusbudWc6nYLu0D6wMEkUWa+LYTQyp4 FrFlhykg7gpoYo48qn5giBb9TaS2DE7YmVhhbBd5iCXYbk1w5tL/SWceOACMEnhOiBvy d7lhGrxtjetr2K8MyShohNF2YJBmluYEtIV9r41NKh3T/Nc7xmBZ83xTEC5VYzKvTfPN xocg== X-Forwarded-Encrypted: i=2; AFNElJ8HZKvz49CfxmFvuu2+dJVOWfoPveOgOQAgxrza1RyNJQGCmidNcDhdO88Guhr4zO/sZKLU6j7u8+W8@gnusha.org X-Gm-Message-State: AOJu0Yzk2uejRG5OIUWRWlFmYth7WIEqZvdFcbHpoqSwITSfRBIGcKgL orMLc597wfeVpA2uRnpIanTMbl+GtBZZXedzd66jtM9Lts31rCR68Q9L X-Received: by 2002:a05:6820:220f:b0:692:234a:e202 with SMTP id 006d021491bc7-69461c5eeffmr75365eaf.55.1776362874711; Thu, 16 Apr 2026 11:07:54 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AYAyTiLheeTbxhpyotWFF8F3FVZNDqbogwCmQfqoUXBVWLg0Gw==" Received: by 2002:a05:6870:c22f:b0:416:1b5c:16df with SMTP id 586e51a60fabf-4280c6a42f8ls632579fac.2.-pod-prod-08-us; Thu, 16 Apr 2026 11:07:50 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ/LA+0Z6hrZIZnvi9UbBNbH7K3W2vBWo/O82HQ5kKQvuywfUKcvXn0VZp7VKu1lVKPB5o8G7JmWyrbX@googlegroups.com X-Received: by 2002:a05:6808:3447:b0:467:15ad:9de5 with SMTP id 5614622812f47-4789d03d6b7mr13856063b6e.13.1776362870467; Thu, 16 Apr 2026 11:07:50 -0700 (PDT) Received: by 2002:a05:6504:1381:b0:2e5:dca6:8eb2 with SMTP id a1c4a302cd1d6-2f7410d1ab5msc7a; Thu, 16 Apr 2026 10:34:39 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ/LbW9OouB0wk4KxzLGmNF8QM+kSSHwHXUPtw0DnCpQSLSyMCuFxlEcr3H8GXIwhh2jpbMMsFSnMIlJ@googlegroups.com X-Received: by 2002:a05:6512:1248:b0:5a2:9d02:9498 with SMTP id 2adb3069b0e04-5a4154fede6mr114733e87.7.1776360877696; Thu, 16 Apr 2026 10:34:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1776360877; cv=none; d=google.com; s=arc-20240605; b=RztiTCnHchCKkE5v8kWfcaF4/aHMqosn6KRNDGD3QgvVqbFsddPDcef2xxhybWa9qt 2hrZ8xLU6k4+9X+F/A1ouysCgGm45JdeBIG3ZLvJI80MAgFDaRz+se0YQVL2oYmgrfx7 uWQS4Im698gAGGvgQFO+2LjyRU/ZuOrsFFa3iKwSrVzD6K3EukdLcrShPZTBzUe9DX1C 0qVVQ848WF71b1SFy1OKmAhHdJzUP4bII7y525AkF5ajJlJjuLpQeFK3COjL6ijFqjsJ /6/V7+pX2Xvz2Y33LQCInB7rw0nqIRcHoXI5mJHoCps3A0e6j/RM9ECPc25gTc59W/V5 90uw== 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=dH2CM6joLEEdrsqrqToyAzvjU+n7+YE1gYxf6b6NgjI=; fh=PW/9fvIDHCyQu+jV4+eWQLQnJQQ8hU0tjfHL/KkrYZU=; b=L/3gcxJ7731H8fsYgCGyxjGPriwmEhoxSIBHSL3KKQ1vkvWKkuYM40O3enIZzv3BT1 +A12ydfxxbhL/jEIPktJm5Vl3vMXQrLgwmee/nd2ozuXJXT4fL3okOY9VTPQ/Exp54nk +5YjEgz4k2W1c7OgRGgSf8kT34CXsEhPu421dzVRm1J+XRQ4shK3XWVIcSPYn/hYwWG2 JCietzDRliPhKigFOLYa9QWGYIjKh3oC39iMm4SP0YXfvyLdEkmmNCjCcHU/Z5uUuOki DQ1BXD466L2tCTHOQ4nruJEuA4GCBoACFHEjQlgly1m7koEWdtdL0NsXmijrkSDdlFHl q2dg==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=jD3u+uH9; 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 2adb3069b0e04-5a40a2a0330si97918e87.8.2026.04.16.10.34.37 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Apr 2026 10:34:37 -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: Thu, 16 Apr 2026 17:34:32 +0000 To: Matt Corallo From: "'conduition' via Bitcoin Development Mailing List" Cc: Erik Aronesty , Bitcoin Development Mailing List Subject: Re: [bitcoindev] PQC - What is our Goal, Even? Message-ID: In-Reply-To: References: <05E6D06B-1F72-48F6-B4F3-0225675BCC1F@mattcorallo.com> Feedback-ID: 72003692:user:proton X-Pm-Message-ID: d5a76e7e1a4d7712a91ca264efc29ca1aeedc15f MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------3c00a231a9ddbfdfc366bf9bd41e98fb666900b05df1b5df4f69f92c439c6f37"; 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=jD3u+uH9; 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) --------3c00a231a9ddbfdfc366bf9bd41e98fb666900b05df1b5df4f69f92c439c6f37 Content-Type: multipart/mixed;boundary=---------------------d9d4833e92758d34a429257fd528e21c -----------------------d9d4833e92758d34a429257fd528e21c Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Hi List, > Fundamentally, it seems to me the most reasonable goal is that we should = be seeking to increase the number of coins which are reasonably likely to b= e secured by the time a CRQC exists. Put another way, we should be seeking = to minimize the chance that the Bitcoin community feels the need to fork to= burn coins by reducing the number of coins which can be stolen to the mini= mum number [1]. I think that's a reasonable goal which we all share, but is not the only go= al. Real-life isn't about min-maxing a single metric of success. For instance, imagine we deploy P2TRv2, and we get EVERYONE to migrate to i= t before a CRQC appears. We maxed out our stated success metric. But we mig= ht not disable P2TRv2 key-spending in a timely manner. If the future commun= ity fails to deploy at the right time, a CRQC can steal at least as much bi= tcoin as they could've before the migration, if not more. We maxed out our = success metric but still failed, so that metric must not be our only goal. That's why we should achieve your stated goal only as a consequence of a mo= re general but less easily-quantifiable goal: to design an optimal, flexibl= e, and long-term-secure PQ migration path. If we standardize this and make = code available to help, migration will come as a natural consequence, as wi= ll other desirable goals like "not letting a CRQC screw us all over", and "= enabling long-term cryptographic agility". If we can agree on that, then any further disagreement will be due to a dif= ference of opinion as to what is "optimal" or "flexible", and the correct t= rade-offs to make on security. We all weigh different properties with diffe= rent values. For instance, I put more weight on conclusive security of P2MR, whereas Mat= t puts more weight on fee-efficiency and "privacy" of P2TRv2 [^1]. There are also differences of faith. Matt puts more faith in the future com= munity to activate follow-up soft forks. I put more faith in wallet develop= ers following standards and in users proactively migrating to PQ-safe walle= ts. Based on Matt's previous emails, I think we both share the same LACK of fai= th that a majority of the UTXO set will migrate in time, and we also share = the goal of mitigating that. > This naturally means focusing on the wallets which are the *least likely*= to migrate or otherwise get themselves in a safe spot. Focusing on those w= ho are the most likely to migrate does almost nothing to move the needle on= the total number of coins protected, nor, thus, on the probability of a fu= ture Bitcoin community feeling the need to burn coins. Also agreed.=20 I didn't find any public statements from your cited examples about quantum = security posture. Since it seems important to understand the wallets' stanc= es in this dilemma, I posted a tweet tagging 8 major multi-chain wallets [2= ] including the 3 wallets you cited as examples. I'm curious what they'll s= ay. Having worked with such wallets before, my expectation is that they'll foll= ow whatever is standardized, as long as it gives them more market share and= as long as they can "npm install whatever" to implement it. I'm not trivia= lizing here - These devs are just spread much thinner than those building s= ingle-chain wallets. The harder question to answer is whether the major wallets make the PQ outp= ut type the default for receiving Bitcoin. Big software companies are typic= ally very concerned about bugs in new code paths, and they weigh this risk = against the benefits of any new feature. When deploying new features as def= ault, they often do so using A/B testing and incremental rollout techniques= . So the earlier question shouldn't be binary. It becomes: How quickly will= major wallets roll out PQ outputs as default? Rollout pace will depend on the personal views of the wallets' corporate ex= ecutives and technical advisors. They will weigh the risk of introducing ne= w, riskier, less-efficient code paths against the risk of a CRQC appearing = in the near future. We and other users can try to lobby them, but ultimatel= y each wallet's decision makers must eventually convince themselves the CRQ= C risk is greater. Some will move too slowly, and many will likely regret t= heir choices one way or another. I believe we cannot effectively optimize away a problem like this by tempti= ng decision-makers with slightly lower fees, since that's not all they are = worried about. I believe we especially should not try to do so at the expen= se of conclusive PQ security and long-term optimization. I think the crux of the P2TRv2 vs P2MR disagreement here is that Matt belie= ves P2TRv2 will induce wallets to roll out default PQ outputs meaningfully = faster than P2MR would, and that this trumps arguments about post-quantum s= ecurity or efficiency. Whereas in my opinion, all we can do is build the best PQ standards we can,= and encourage wallets to migrate once they're worried enough by the CRQC r= isks and ready to accept some mild trade-offs. That "best PQ standard" is, = long-term, P2MR. > There is no possible ZKP that can fix this. There are several techniques which can. regards, conduition [^1]: I still have yet to hear a decent argument as to why P2TRv2 is meanin= gfully more private than P2MR. [2]: https://x.com/conduition_io/status/2044804746687525012 On Thursday, April 16th, 2026 at 5:44 AM, Matt Corallo wrote: > Hi Erik, > > It appears you missed Olaoluwa's posts on this very list where he did exa= ctly the thing you claim is > impossible - build a ZKP which allows someone to prove that they had the = private key to a > transaction in a way that no quantum computer can forge! > > Matt > > On 4/15/26 2:08 PM, Erik Aronesty wrote: > > Yes I agree, Matt. People are definitely talking past each other. To = me "safe coin maximization at > > the expense of decentralization and proof" seems like the completely wr= ong goal in almost every way. > > > > I would like you to bear in mind that there is no reasonable way to a c= ertain that someone is the > > owner of a coin unless they show proof of that private key. I think we= all can agree there. > > > > And that with the theoretical magical quantum computers compromising pr= ivate keys they will be no > > distinction between a coin holder and an attack. There is no possible Z= KP that can fix this. > > > > I think the fundamental thing we need to do is provide sovereign and ac= tive users the ability to > > protect their personal coins. Opting into this protection will occur a= s the interested users > > determine that it needs to occur. This is the only sure way to prevent= a premature optimization for > > a computing paradigm that may never exist > > > > Maximizing sovereignty Is the entire purpose of a decentralized and pee= r-to-peer protocol. > > > > Having decentralization and sovereignty be a secondary goal is like ign= oring freedom of speech and > > then pretending to be a democracy. > > > > > > > > > > > > On Wed, Apr 15, 2026, 9:52=E2=80=AFAM Matt Corallo > lists@mattcorallo.com>> wrote: > > > > Its become obvious in recent discussions that a large part of the P= QC discussion has people > > coming at it from very different fundamental goals, and as a result= the conversations often talk > > past each other without making real progress. So instead of doing t= hat more I'd like to write > > down what I think the actual, short-term goal *is*, what it it is n= ot. > > > > Fundamentally, it seems to me the most reasonable goal is that we s= hould be seeking to increase > > the number of coins which are reasonably likely to be secured by th= e time a CRQC exists. Put > > another way, we should be seeking to minimize the chance that the B= itcoin community feels the > > need to fork to burn coins by reducing the number of coins which ca= n be stolen to the minimum > > number [1]. > > > > This naturally means focusing on the wallets which are the *least l= ikely* to migrate or > > otherwise get themselves in a safe spot. Focusing on those who are = the most likely to migrate > > does almost nothing to move the needle on the total number of coins= protected, nor, thus, on the > > probability of a future Bitcoin community feeling the need to burn = coins. Sadly, this probably > > means the "top wallets" that are generally terrible at adopting Bit= coin standards. Wallets which > > are the top listing on app stores like (currently in the top few in= my app store): Bitcoin.com, > > Trust Wallet, Coinbase Wallet, Blockchain.com, etc. These wallets g= enerally use a single static > > address (because anything else confuses their users and they get ad= ditional support tickets for > > it!) and put very little time into Bitcoin, focusing instead on oth= er tokens and integrations. > > > > A few non-goals: > > > > * To ensure that advanced setups have the absolute best in post-qua= ntum security. I don't see > > how this moves the needle on the above goal, and in fact in many ca= ses detracts from the above > > goal. Of course if we can accomplish this without detracting from t= he top-line goal above, great. > > > > * To ensure we have the best possible design for the signature sche= me bitcoin will be using in a > > world where a CRQC exists and we've gotten past the mess. We'll alm= ost certainly know a lot more > > about the security of various schemes and have more options for how= to approach the problem by > > the point we're dealing with the mess of a CRQC being imminent, so = it seems like a fools errand > > to try to predict what we should build for this. But even if we kno= w no more then than we do > > today, likely ending up with hash-based signatures as the scheme ev= eryone uses, we'll almost > > certainly be having conversations about additional witness discount= s or increased block sizes to > > compensate for the sudden increase in transaction sizes. Maybe we w= ould decide against such an > > increase, but there's no question such a conversation would happen = and it would be premature to > > have it today. > > > > Matt > > > > [1] Of course I believe that the lost coin pool is large enough tha= t the Bitcoin community will, > > almost without question, fork to disable insecure spend paths and b= urn some coins in the > > process, but reducing the number of coins burned to the absolute mi= nimum is of course best for > > everyone. > > > > -- > > 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, s= end an email to > > bitcoindev+unsubscribe@googlegroups.com . > > To view this discussion visit https://groups.google.com/d/msgid/bit= coindev/05E6D06B-1F72-48F6- > > B4F3-0225675BCC1F%40mattcorallo.com > bitcoindev/05E6D06B-1F72-48F6-B4F3-0225675BCC1F%40mattcorallo.com>. > > > > -- > > You received this message because you are subscribed to the Google Grou= ps "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/bitcoin= dev/ > > CAJowKgLKkSrzKGZAe2sSgCafjKx_U%2BoWz%2B-FxSb%2BAtppAayQXA%40mail.gmail.= com > groups.google.com/d/msgid/bitcoindev/CAJowKgLKkSrzKGZAe2sSgCafjKx_U%2Bo= Wz%2B- > > FxSb%2BAtppAayQXA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoot= er>. > > -- > 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/c495b375-ebf5-4d9d-a9f6-a9d9922fd3dc%40mattcorallo.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/= dV07voa7X-341HghubWLcbTo4Pju0s0SfO4a1sRsC6VC_mJIOJIACq5INXizBC-Xg_8tcpBYRj-= 0LGDc9KTfs9OIhFWVoNvRwYdVwYLUk2o%3D%40proton.me. -----------------------d9d4833e92758d34a429257fd528e21c 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== -----------------------d9d4833e92758d34a429257fd528e21c-- --------3c00a231a9ddbfdfc366bf9bd41e98fb666900b05df1b5df4f69f92c439c6f37 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wrsEARYKAG0FgmnhHZoJEHgpbO2E9rPFRRQAAAAAABwAIHNhbHRAbm90YXRp b25zLm9wZW5wZ3Bqcy5vcmdwl0LyhAv4OVewrxIa7/SFzQAaI/kL79qdbZzu oSOJNRYhBEdIka0CMtrLdg13a3gpbO2E9rPFAACaRwEAml7UdCvvu/eChKVG QaxFTn0IiZ6vsLHSdLA3JNZjCtYBAJnnAsoGi1N16+T6hZXP0vx1cquMzAOP IEgxJ0o4UjQE =pSXD -----END PGP SIGNATURE----- --------3c00a231a9ddbfdfc366bf9bd41e98fb666900b05df1b5df4f69f92c439c6f37--