From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 19 Apr 2026 10:19:40 -0700 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 1wEVo3-0006Z4-7N for bitcoindev@gnusha.org; Sun, 19 Apr 2026 10:19:40 -0700 Received: by mail-oo1-f57.google.com with SMTP id 006d021491bc7-68b313c42e7sf2172493eaf.2 for ; Sun, 19 Apr 2026 10:19:38 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1776619173; cv=pass; d=google.com; s=arc-20240605; b=eDOqyUx9HaEEjNYVHY1lDVSvmhbz2Jgk59/XExIeUi5SPeTUFGAwv0KEkFBcoHs0jl OM1ZYSZXag5DXK3MK4BbBoYP6pWxT0FWaJOIboIOfLFYr5rXNXMNrcGcLwlSSyJF3txT V4snjjaCLQUU5uW4RxZfp+Hq3oPhSaaPrhYcIYbftuj/z2jLSSd58d6gk9hMtDlZXVvV u5Plyy37Cx4dMLPauE65+2BVAZ9jIyx1nNU8M1hAIlZSdaIl0rNCgYQPIGrcH6K8ZpHp 5N9E/A0ykM7z0gZ/rOKDM/Sg8ETjK5hXyL2IR269lLBDkpDR5z9wnqtYkZItK521hngk vv6w== 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=61zUBPNuLEgJ7CZJGAyukDyFwYcJHlyYqi2Jmv8voRo=; fh=wMmVTXgo8TRzyeDrufsrwwXPo9/mJ7Rf4ymXGoegQNg=; b=ez8l0mwZCpzw3uU9XPb2K7++cnE/1jqaUw/N35Qb0XS3O3HDtEN7sQ/zaVMW6RpKYo ggXC3feoYU8DiXlKEN8v7aVYW/hu5/00tzIUiu0iShPftZX2XmrvkMYgtBE+5M0a/Zqm 7UL2B9R/ZJQBjz56X2SgPnpyUpxAoURzQ74vvKS78x0fM1OA4JoY7xT1JwktSpbvokPX noaLpbnY/Qv+U/b1vQJeYB8WaMEOUSXCNzRet3S4LvHPSiYjwi7OqMJb1/5c3DGbwKYw kXKQKeoDbfog9jOxELM51yfnkjy6TilABYhdhMf5BiufSBFUCzHM4jlcwj8NftHMOtzC t/3A==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=5mm7dexnp5ahlib4j4u2endnim.protonmail header.b=ADKRAZrX; 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=1776619173; x=1777223973; 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=61zUBPNuLEgJ7CZJGAyukDyFwYcJHlyYqi2Jmv8voRo=; b=He25AHHmpKXRJF1XNmEX5+I+lo7CRQ1Ft5zGxS4P8q4ZIxvt+cDl3enzIxDrloyGJ4 iHGByDH2RN9VxJEmrbKgvEtXvpNJglsfUDikFlAM2JWYByHNmmtMoQqitwhaV9ERPfzq TCtT5IGbkVEwRC1dATEL3d81MVJaxUux0g6f1Aa0fxluWvpj2P/lqKVzJaOD5NuAVK+S czNk0FDKGpi8g9I0VOguJFx/qkFPdF3pdCfH2oCJXoW6Jst3mOfk9vqnnD/52u42s6vx hoBqrHNbNEIciPkUntxki481wIkX4Ka12uZ8/JM8CjedPx9pRq6l9Hfb/E6d5NdykIGE oPrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776619173; x=1777223973; 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=61zUBPNuLEgJ7CZJGAyukDyFwYcJHlyYqi2Jmv8voRo=; b=Eyff+dDaubMOFyc5kujUPpHIrATVnQzNQHHxmeqKUkdbwQCJwXG105OQX3RZL4JRro xRuLjad8ZwwWfGSC1rVUTkzcxF53JRO8rI8mbN2kQqH3YfTDReGHCoeXMqZXe3D2ViHT xc/9EkrRt7zWudlE887Ls5MuBFl7/rj+At4IBSEwGoPCFg6vTTj64C3UsYcq3eHqBNAK z3e0clj/sP2cAy+10ZTJXgsWab0sjjJJdLawIF3am523K+TmMFZlpEfe8WkmqCyRmP3x kKnR4DpmclcanGILz/aWuKAaT6lh37tOU2T/TKQB7iEXV70jM45DEOaG4MLuoI8jSFep rN3Q== X-Forwarded-Encrypted: i=2; AFNElJ9kfNmL9hF4k0Vv/rNO33I21udSFNYJOQdiOf36UOIMSFpY3zb4OdCCEpOUHP1gNgGbitoUuqAImjAC@gnusha.org X-Gm-Message-State: AOJu0YyiIYx8+/bLirQX9RzJr9vUdEdS74V9w4Tk5SR/WLeJDh1XH4UK kZ7xXELGh3plgVKstHst/lZ3gTum0DAdgdEygEPPKdXsNGaUhI+Xu799 X-Received: by 2002:a05:6820:218:b0:685:c39e:583a with SMTP id 006d021491bc7-69462ee69fbmr4900160eaf.30.1776619172488; Sun, 19 Apr 2026 10:19:32 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AYAyTiJJ3neuNvyqppImWTNxZ5JFJqQd5gzvxbLzD0d5HYBd0w==" Received: by 2002:a05:6820:61f:b0:694:8490:21c2 with SMTP id 006d021491bc7-6948490251cls23573eaf.2.-pod-prod-02-us; Sun, 19 Apr 2026 10:19:26 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ+cgBxcLGmO5FXUmTe1ZkHZZeD63UnwSZYv3YCPmy0k1a71BbCxiqLzugdUGjCkVZhalabqYqbnCCIf@googlegroups.com X-Received: by 2002:a05:6808:2f0c:b0:466:fd51:6a65 with SMTP id 5614622812f47-4799ca0ba3amr5124355b6e.23.1776619166624; Sun, 19 Apr 2026 10:19:26 -0700 (PDT) Received: by 2002:a05:6402:31af:b0:670:416a:5ab4 with SMTP id 4fb4d7f45d1cf-672c1ac84f8msa12; Sun, 19 Apr 2026 09:27:46 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ/Ltx9lFW9JHLzVYvkF3UMZSg6ijLyokTTPrP+dTXfsaE9wFUzd/knCQFWdnRsP31Hy6OWdw5CvciBb@googlegroups.com X-Received: by 2002:a17:907:948c:b0:ba7:6a43:3036 with SMTP id a640c23a62f3a-ba76a433c46mr62034966b.17.1776616065004; Sun, 19 Apr 2026 09:27:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1776616064; cv=none; d=google.com; s=arc-20240605; b=kCXuHaqwCcfSdrsiKNkDmAuL39N9u4VEZkliSxEgtoWKEOwl3XBZFDUeX423wqGQtY phkYe+a0w7LrmrrTxQcE7WLESGXUi0n/OblaSgoP96Ed78PEU8SE2izs26aFNOe0936A U7ikgHJ4tIJWwDYvftLwcLe8g5DlC7CZd17cv7X/RLbgY7bDJVksxfp3ybQjDZ8FOzod X5A2Xp2zxX/69eicCCKUJ9eL227bzB4TO9TD0xPd9dgPKdYXGuCozLRJtUeOOK33ZLmy Wf6th350krI0pTJaimQOybQbQ6eiVG3QScKNBf9joNypiILn+XxrTp4c31LltUV5t/E9 QmLQ== 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=0kWGHbAF4fZxym67ZQHhX6W4VDtqTVC4NdLYKQ9mEeA=; fh=IjYa98c7my0nVXoG8SJpYxL6k52v3VCTFD4Ls94Ijlk=; b=lNgRfkzQgDLT0CU1/7C97pVaxyaaBxZHO/+MmFeJyxmakrJravA5BRy/3ndjDxHScX GbQGEz8dUQ0h8xRnWb6gZs8ZcLOW7FaYUQ+aPvZCJon/JRAwzm43VaE+VpNjXc9RQxJ8 J0oo7tD/250om5tgzBRdHJGY/pSDhR404EI3SZee9AIgXSvQceuF7bLLw8P00Xo0QFt3 ZUUxWAuHN1FIP69tJO2cfFbcuX2yK0Ci78hKc2MhjNkY2naARpZJsVY5hsrpsMyW/dqW jobgFMrGQwtPtfUBqkdyjvVXYLIJBDSwLDDjwLCNZwVvSKfkA6WeNz6Gtj6mD+i/dV/F Z0sw==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=5mm7dexnp5ahlib4j4u2endnim.protonmail header.b=ADKRAZrX; 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 4fb4d7f45d1cf-672c4d68844si114538a12.8.2026.04.19.09.27.44 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 19 Apr 2026 09:27:44 -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: Sun, 19 Apr 2026 16:27:39 +0000 To: Matt Corallo From: "'conduition' via Bitcoin Development Mailing List" Cc: Ethan Heilman , bitcoindev@googlegroups.com Subject: Re: [bitcoindev] PQC - What is our Goal, Even? Message-ID: In-Reply-To: <39f3c26e-2cb5-4dcb-a269-78c793174b2a@mattcorallo.com> References: <2b8d2a1b-9e9c-4918-9ac7-4bdcb15f5886@mattcorallo.com> <39f3c26e-2cb5-4dcb-a269-78c793174b2a@mattcorallo.com> Feedback-ID: 72003692:user:proton X-Pm-Message-ID: 389888927c1b2178ae4aef160e0937bb934761b6 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------3f96bfe8811ed29d3ba8b4660d619ba4d22e2cc189533aa32745ce730501e4c9"; 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=5mm7dexnp5ahlib4j4u2endnim.protonmail header.b=ADKRAZrX; 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: -0.5 (/) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------3f96bfe8811ed29d3ba8b4660d619ba4d22e2cc189533aa32745ce730501e4c9 Content-Type: multipart/mixed;boundary=---------------------f9cb95e7050ed19784531853b9923cef -----------------------f9cb95e7050ed19784531853b9923cef Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Hi Matt, thanks for elaborating. But I think you didn't address the overall= point of my last email, which is that address reuse is a null argument in = the P2MR vs P2TRv2 debate. What difference does it make if wallets use P2MR or P2TRv2 when they reuse = addresses? EC pubkeys are exposed on-chain either way. The only diff is tha= t in reused-P2MR, EC pubkeys are exposed slightly later at spend time, rath= er than at receive time. Even if you take the highly pessimistic view that 100% of P2MR usage will a= lways be through reused addresses, then those coins would be no more secure= in P2TRv2 than they were in P2MR. To protect coins in this context, an EC = restriction is needed either way, and that can be applied equally to either= P2MR or P2TRv2. > I think the gap between our views is that I don't buy that the "percentag= e harm reduction" outcome is all that interesting. Sure, there's some % whe= re it certainly is, but its probably in the 99+% range, not in the 75-90% r= ange. I think maybe the biggest gap is I just don't find any "solution" tha= t results in 10-20% of bitcoin (*especially* active bitcoin people hold key= s to that made some progress in migrating but maybe screwed up address reus= e) being stolen as at all interesting. If we manage to get 90% of active co= ins secured and then 10-20% of active wallets get some of their funds stole= n, have we actually accomplished something grand, or is Bitcoin's reputatio= n so shot that we might as well pack it up and go work on some new fresh ch= ain that is PQC from day one? I'm fairly confident the answer is the second= , not just in that "we"'ve failed, but that the market will see it the same= way. Am I reading this right? You think it'd be better to abandon the entire cha= in if a CRQC can steal more than 10% of the active coin supply? That's a bl= eak outlook. I hope you change your mind on this. I hope even more that we = can prevent such theft from happening in the first place. But again, debati= ng P2TRv2 and P2MR is irrelevant to that goal if you assume address reuse w= ill be rampant and exploitable. > In a world where there's material address reuse, and those folks are usin= g P2MR, suddenly it becomes "their fault" for "using it wrong" (even in cas= es when it isn't). People will blame whoever they like. Our concern isn't to direct the blame = for theft correctly; Our concern is to reduce theft by deploying the right = upgrades. If CRQCs become a threat and too many pubkeys are exposed, we dep= loy a restriction on EC spending. If we can do that on P2TRv2, we can do it= on P2MR too. > On address reuse, as far as I'm aware, its driven by at least three facto= rs All address reuse scenarios, including the examples you gave, can be protec= ted by restricting EC spending regardless of whether we deploy P2MR or P2TR= v2 as a first step. regards, conduition [1]: https://groups.google.com/g/bitcoindev/c/JA3kDl8AmQg/m/kUhTTSpVAwAJ On Sunday, April 19th, 2026 at 8:05 AM, Matt Corallo wrote: > > > On 4/18/26 8:29 PM, Matt Corallo wrote: > > > > > > On 4/18/26 11:44 AM, conduition wrote: > >> I think I maybe under-stated my concern over the no-address-reuse = requirement for P2MR. We've > >> been trying to convince wallets to not reuse addresses for 15+ yea= rs and have not only had no > >> success, popular wallets have been actively migrating the opposite= direction instead. In the > >> face of address reuse, P2MR has zero advantages over P2TRv2. > >> > >> > >> I think we agree that merely spec-ing out P2MR as "not safe to reuse" = in a BIP will be > >> insufficient to prevent all address reuse. We also agree that /reused = /P2MR and P2TRv2 share the > >> same security profile, with or without a future EC restriction (which = can be applied to either > >> output type). > >> > >> But we seem to disagree in our conclusions. You believe that because o= f this overlap in security > >> profiles, that we therefore ought to prefer P2TRv2 - presumably becaus= e of its short-term > >> efficiency. I think that's a huge leap of logic. The overall security = profile of P2TRv2 and P2MR > >> are wildly different and you are only taking a subset of P2MR's profil= e into account. > >> > >> To reach your conclusion that P2TRv2 is preferable, you'd need to assu= me that the vast majority > >> users who migrate to P2MR will reuse addresses - vast enough of a majo= rity that the short-term > >> efficiency savings of P2TRv2 key-spending outweighs the safety of the = (presumed) tiny minority of > >> users who actually use P2MR properly. > >> > >> We have historical evidence this assumption won't hold. Take a look at= Project Eleven's bitcoin > >> risk list metrics dashboard . The volume > >> of bitcoin exposed today due to address reuse is only a minority fract= ion of the overall supply - > >> about 5 million BTC at present. Still significant, but not an overwhel= ming majority by any means. > >> We have no reason to expect everyone will suddenly start reusing addre= sses consistently with P2MR, > >> at least not any more than they already do. > >> > >> If anything, address-reuse will reduce, and not just because we ask th= em to. If you look at the > >> highest-value addresses at fault of address-reuse today, they are most= ly corporate cold wallets: > >> binance, robinhood, bitfinex, tether, etc, and these make up a signifi= cant chunk of those 5 > >> million exposed coins. We can reasonably expect those players to use P= 2MR properly out of self- > >> interest - These coins will be the lowest-hanging fruit targets if the= y fail to do so. > >> > >> So yes, even after taking address reuse into account, P2MR is more sec= ure than P2TRv2, and > >> personally I think the safety delta between them is wide enough to exc= use the minor handicap in > >> P2MR's pre-quantum efficiency. > > > > I think the gap between our views is that I don't buy that the "percent= age harm reduction" outcome > > is all that interesting. Sure, there's some % where it certainly is, bu= t its probably in the 99+% > > range, not in the 75-90% range. I think maybe the biggest gap is I just= don't find any "solution" > > that results in 10-20% of bitcoin (*especially* active bitcoin people h= old keys to that made some > > progress in migrating but maybe screwed up address reuse) being stolen = as at all interesting. If we > > manage to get 90% of active coins secured and then 10-20% of active wal= lets get some of their funds > > stolen, have we actually accomplished something grand, or is Bitcoin's = reputation so shot that we > > might as well pack it up and go work on some new fresh chain that is PQ= C from day one? I'm fairly > > confident the answer is the second, not just in that "we"'ve failed, bu= t that the market will see it > > the same way. > > > > Sure, in any solution set here there is going to be coins lost, but if = someone did the work to > > migrate, having a high % chance of screwing it up isn't an interesting = scenario to consider - > > bitcoin is simply dead in that case. > > I wanted to expand on my answer here for a moment. I think the reasoning = of "well, some people will > be able to use P2MR correctly" isn't just not fixing an interesting probl= em, I think its somewhat > dangerous. > > First of all, the more I think about the address reuse problem (its been = a while since I've really > thought about address reuse, so it took a day to come back to me...) the = more I don't think its > going away. As you note about a quarter of all coins have an address-reus= e issue, and if you remove > the large cold wallets its probably half that again. But when we consider= both the uses of Bitcoin > that drive address reuse and look at the chain, there's a lot more risk h= ere than just 1/8 of coins > (not to mention just 1/8 of coins is way too much). > > In a world where there's material address reuse, and those folks are usin= g P2MR, suddenly it becomes > "their fault" for "using it wrong" (even in cases when it isn't). Blaming= bitcoin users when the > protocol was too hard to use is something we've tried very hard to avoid = through engineering that > makes it harder to misuse. Instead, here, we're encouraging it. This does= n't just discourage any > future fork which might disable EC path spends (maybe some of that can be= headed off with clear > documentation in a P2MR BIP, but this blaming has already started...), bu= t it encourages a culture > of blaming bitcoin holders for the mistakes made at the protocol layer. > > On address reuse, as far as I'm aware, its driven by at least three facto= rs - > > * There's the somewhat obnoxious "wallets get user complaints when thei= r address changes cause > they're used to address-based blockchains so wallet devs turn off the add= ress rotation feature to > save on support costs" one which is the most frustrating, and may well dr= ive the most wallets, but > certainly doesn't drive the most coins. Maybe this one is fixable. I'm qu= ite skeptical, but you and > Ethan certainly seem to think it is. > > * For funds, family offices, many custodians, and exchange hot wallets,= address reuse is an > important security feature - much of the large-bitcoin-wallet industry is= built around keeping a > list of allowed addresses (exchange accounts for sales, but also on the f= lip side a list of their > own wallets which their exchange accounts are limited to withdraw *to*). = They have processes in > place to verify every transaction only goes to one of the addresses in th= eir list. When I go to look > at the addresses with the most bitcoin transacted in the last year, there= 's some cold wallets, but > number two is 1KNm4K8GUK8sMoxc2Z3zU8Uv5FDVjrA72p, which some random websi= te seems to think is jump > trading...it has received a total of 97M bitcoin across its lifetime. May= be the large players will > rewrite their logic to use a combination of xpubs for EC key generation a= nd a static PQ pubkey, > building the tree as required, but exchanges are gonna struggle with the = extra address > generation/chain scanning burden and I'd think would instead just switch = to PQ-only and charge the > extra cost as a deposit/withdraw fee, or more likely "use it wrong" and u= pgrade "when the time > comes", blaming their customers for sending coins to a "revoked address" = when they do so. Maybe a > new output type really (finally) needs a new address type that has an exp= iry date... > > * But maybe most importantly, sadly ultimately no one can control when = someone else sends them > bitcoin. For spending wallets that are used to receive coins, the sending= wallet having a "contacts" > feature or users just reusing an address that was provided to them is eno= ugh to potentially screw a > wallet. While the first isn't so common (though certainly growing), the s= econd presumably is > somewhat more. Here too, maybe the solution is just an address format wit= h an expiry date, but of > course that would slow down any migration by probably five years and like= ly isn't a great tradeoff > either. > > * Its probably worth noting that dusting attacks could trigger many wal= lets to reveal a public key > too soon. Of course any "quantum safe" wallet should handle this in the w= ay Bitcoin Core does - > ensuring it spends all outputs with the same address at once, but this is= just one more way relying > on this stuff can so easily go wrong. > > Matt > > -- > 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/39f3c26e-2cb5-4dcb-a269-78c793174b2a%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/= MPXPgim-vthykBFwesBlyBfxPxeE9SVEulMF_EmwSp8GB4lZQLzdFu5QCTPpYwX1O-T8ZWqqIQi= RwBdw4frjnDH9JzBaRx2cnoS40MUhGAw%3D%40proton.me. -----------------------f9cb95e7050ed19784531853b9923cef 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== -----------------------f9cb95e7050ed19784531853b9923cef-- --------3f96bfe8811ed29d3ba8b4660d619ba4d22e2cc189533aa32745ce730501e4c9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wrsEARYKAG0FgmnlAmsJEHgpbO2E9rPFRRQAAAAAABwAIHNhbHRAbm90YXRp b25zLm9wZW5wZ3Bqcy5vcmfAtzN10Dn8a9egWJIMpbaig8j8SOZ+pEF6S+ut Qd+1jhYhBEdIka0CMtrLdg13a3gpbO2E9rPFAABdtQD9E9Sp9LnQbFiQJQ+S ZCdLc1PivU9e6+s+oefIWoysKHoBANoK/fYPDwPuuqR+NYpUujpLFKxZWSIT Hr+fb5QzxcII =yHJ6 -----END PGP SIGNATURE----- --------3f96bfe8811ed29d3ba8b4660d619ba4d22e2cc189533aa32745ce730501e4c9--