From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 12 Jun 2026 00:34:58 -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 1wXwPn-0001C6-MH for bitcoindev@gnusha.org; Fri, 12 Jun 2026 00:34:57 -0700 Received: by mail-oo1-f58.google.com with SMTP id 006d021491bc7-69e300e03dfsf954933eaf.0 for ; Fri, 12 Jun 2026 00:34:55 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1781249689; cv=pass; d=google.com; s=arc-20240605; b=ZJPMIQCSiYcV/2a/UB1t+oU5FMNbhA7BSEL1B5rnTi3qrcKFrsGgk2khvLKt0Bnbgb qLMQSUNUHoFbjWrnmnaekLFWpSDVJtctng4wVjMowOwq9/iWc7HP1NXzn1oOGwMCeALZ 7umDAT3e0wsX8QOWTn21mJ/DZSbHTKbjcnVXt35QHOy/6f8zjzUOcp8YCFUp9V7M/T96 +jXRISnSnHsNtaFRdgFuUbZWpWCQqZWfSXXwtfJsZSn4yZ84SwNMaHpWSvYRKkYQOde2 niw5ZU0Ufh/vN2EPWZZIC/I3XJeR7jX5ETFYDfowLKYOOPjN1ghejWrSjQKTmpFESAtG w7CQ== 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=j25UJ0UTed2nklGJUYjQs+SvKmIalm3mfc/YgrWYlsQ=; fh=5Zm4pIjxNr6hiOCWj5bIY5CzDS5f2ol0h0gFF3IhzxI=; b=HYGDqvquiEcqfhczMi32o2chGvrG8tf9jD53WIBFOYdu/JDcfM9Orpz138/z0+wxwd dra83g1EUgjDIXUOlH1PkXSRrSfJMQIXkOVhDk89F/JoUOWsgjmCktWwyu2JoDTqRy+R RLqz/PTvoiqy2xSB3eRFXQRupBVTbN18QWBN8dL6Gr/05fXfS3XW/LjjOjwUVAHUQEYp QljB7dj8gWwhDEM7leLDai6l0at4hdCppJRh8ACSX9oOrcudpIiMDHyhgsQ7hyn89sWr 7wu+/k0U94irw+tSPOvsL0GsgZ2+shK+2+8HsNjP3PZafDP9BYBcOjKfsqUN2mvCnoo3 Q9RA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=nwobFBxb; spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.103 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=1781249689; x=1781854489; 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=j25UJ0UTed2nklGJUYjQs+SvKmIalm3mfc/YgrWYlsQ=; b=tAVD+MsrNncuDDj5CuLRg4FQKRDDDFq4pJaQSbzT+rErdZk3U1sHkq5R5j0yO9H9OX o9B8zRzWGoTXzbWaBKJ6MbC3p7vWX1ii0HKlxAdYgrrwsdIMHAP2SHWx6f33PLxEfd64 Acjzhy8WexHg/VX12zQ2fiCFW5Ql5ZPWziOBTHV3Nx0XP105gxekdcUnVrITrcJm2hbF L6nSdtib/U7lsiTAOrBxbJKKGJlWwxD+fm8cPMW9FyCulBMXqDJV9NZhC7UUeG99PkHX rPJ5xBlCWaOjKY41FUcubVFMlwZIoRAouM+ZZPuBazS04775qjOqnK7AfoY8oIjB3aeG TjlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781249689; x=1781854489; 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=j25UJ0UTed2nklGJUYjQs+SvKmIalm3mfc/YgrWYlsQ=; b=cmEuBrZtoTH6omDG/CAsLo7CV5GOY8fibXvvmThjLRMURdfkvY9zKP1yGJBIy1OUIq CefFnYrP9VzbWBjL4RwLplgkcwROS44HJZsloMcbPs9jZSPBueaF90cXo/PjZwoRNkjH 4Vxnm5fslccqbLiJ1M0EnpV3ZF124zyvaDKIRDwOOQTJ4UKCb5kBVu02wU5UzSvpiwPM 4ud0PHIWc0pExbfcBN40O2T6myYm4crZjl1FzCTa8wyyxVzDvhkrWtY68UxW3eYF5g05 5NO+VbQJxpHEuNPE+CZ9GVe46Pn+JVWppjJ+pRF86OBmyhmVgor0/wuEg835BXVFZ4IU yynA== X-Forwarded-Encrypted: i=2; AFNElJ9YoR+3SOH2cd8DPHqXpo4IylHVN8X9yZvexlrPq9RwII5pux+jcL+R6iVzG8WUkL8A4rQIisji/hw4@gnusha.org X-Gm-Message-State: AOJu0Yw37hN1Ld9Ozyq+Xj2HnnODlMzIW2pGq6/oTiewvF9dvt0zP+4z 9DNhQE1qrH/51+gg3zEzbx2PB2QnFenretl58uAHqRVU/dGAbr98w0bq X-Received: by 2002:a05:6820:f003:b0:69e:9c80:2fa0 with SMTP id 006d021491bc7-69edc62d495mr1048715eaf.17.1781249688685; Fri, 12 Jun 2026 00:34:48 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AX0PUUdpx2b5oxydwAhCeCaNV9pJdQPf1aCApUMRxaeiNyaMDQ==" Received: by 2002:a05:6871:290f:20b0:416:1b5c:16df with SMTP id 586e51a60fabf-44262742a28ls312332fac.2.-pod-prod-08-us; Fri, 12 Jun 2026 00:34:44 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ+gG1HsB6LNBHmk+LhEsvCmSndZaC6V8iS1G7kFX000Km7JRPCSUbKzeOPvqS/gm92epLIeBHZZ0a9H@googlegroups.com X-Received: by 2002:a05:6808:5190:b0:486:978f:7b1f with SMTP id 5614622812f47-4872f5a3a7dmr1292633b6e.36.1781249684340; Fri, 12 Jun 2026 00:34:44 -0700 (PDT) Received: by 2002:a05:6504:10c2:b0:302:4fe1:d22 with SMTP id a1c4a302cd1d6-30478f42ea1msc7a; Thu, 11 Jun 2026 21:43:49 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ8C69Omom70NUiHE1ju4m1O3unqNReGsYWBigH9XQQK6/PVSe6ZB0/yHDNj61bZO82rk5duzOZaTX48@googlegroups.com X-Received: by 2002:a2e:be04:0:b0:396:71a5:783 with SMTP id 38308e7fff4ca-3992afe7162mr3855231fa.10.1781239426920; Thu, 11 Jun 2026 21:43:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1781239426; cv=none; d=google.com; s=arc-20240605; b=fOdrr3NE/TXhn/anoByKGj+s89n5dlmqMRXDuZFpGajumVQDfdbc6yqX6FmaKlf1hU h5NlVZYNgilWT4ACb5aNUk9n0wDMnwBmlF2njlg1khD+aJDhkpriJ05TYMgzu05+82pF MmuQs8tT0xPlj96+zXRfp45Fbw4OZqOkpdNp9MpE53bJJDwA9+evPM8HM4Gv7pgbRhRg 32m9eFP3Gs152bInzhB3xWmZmz37mSrsjM7A+otZbfevoftP0GqEzS9IqPdOgNXpk4MZ 8it1WeHZK494NlqOX4uBXuvo1q9Gotu7btN2N7EEKmajY26xQ5HNU0cUz++2cIIJnqsO 1IrQ== 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=P/zPOVcA/uv+VUiBGQBCKElKZQHyvnazY43TpjvOOgg=; fh=U9ccRNGf+BW2NF32FKpsuS15uCE2U1idoXsNEmQleBg=; b=YOoUPTzgyAxq7aLnKdbVEuBtN0rWBAL9w261rJXzppLus5EIihfEKet7kGDaOWPT27 /AJE8+SOLwWh9R2DUQoEUTMbx3ZakzvrZPRmU7/VwzbEolfsM93U1zGN73L87OXgFK2s lpgcDDcjBwucfmb/YbN6Q9wYUJO8Pf3ocYxIFrIkfSyhXEY8Clhj6gNchHfbg2KSMqtZ 3SAnXH7qgl9Ybcslp8q2V4dEzqWZjgDBei5KLie2GQuYyxSsb/WNIsFC60RdB3JJqlK/ AgIaTm9Ms6oi6Pnh/XVg4aSpF5VGjmuB5+gll+tJTD6pB0T3P0z6IYCOp/LqAiaMvXaB krgg==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=nwobFBxb; spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.103 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me Received: from mail-106103.protonmail.ch (mail-106103.protonmail.ch. [79.135.106.103]) by gmr-mx.google.com with ESMTPS id 38308e7fff4ca-39929f612a9si271791fa.6.2026.06.11.21.43.46 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Jun 2026 21:43:46 -0700 (PDT) Received-SPF: pass (google.com: domain of conduition@proton.me designates 79.135.106.103 as permitted sender) client-ip=79.135.106.103; Date: Fri, 12 Jun 2026 04:43:41 +0000 To: Pieter Wuille From: "'conduition' via Bitcoin Development Mailing List" Cc: Antoine Poinsot , "bitcoindev@googlegroups.com" Subject: Re: [bitcoindev] Aligning privacy incentives in P2MR Message-ID: In-Reply-To: <_z6_JUmphCkUYvI6gemSFMD9Sb_rDL03IQbtZQCNlk6pmioGEQBir_gMyZCfticFa8Ttfc0xoFHdxR07_MNuAfBu8do_h5IDf2apVk1w1BM=@wuille.net> References: <_z6_JUmphCkUYvI6gemSFMD9Sb_rDL03IQbtZQCNlk6pmioGEQBir_gMyZCfticFa8Ttfc0xoFHdxR07_MNuAfBu8do_h5IDf2apVk1w1BM=@wuille.net> Feedback-ID: 72003692:user:proton X-Pm-Message-ID: 6672d314d9a792da175388bf1b7a8465bd225791 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------140bf57b802d841575d160c5d6afeb57f44f19ab034df729681988bc670f89e5"; 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=nwobFBxb; spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.103 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) --------140bf57b802d841575d160c5d6afeb57f44f19ab034df729681988bc670f89e5 Content-Type: multipart/mixed;boundary=---------------------55b83315454d21f469cdc54957bc5477 -----------------------55b83315454d21f469cdc54957bc5477 Content-Type: multipart/alternative;boundary=---------------------bebd4c86eb1e3ee3c3b116d1282cac24 -----------------------bebd4c86eb1e3ee3c3b116d1282cac24 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Hi Pieter, > I think it improves one aspect of the incentive differences (relative cos= ts within the output type for common vs. uncommon). The key recovery idea i= mproves another (relative costs w.r.t. P2TR in the common case). Even with = both, the result is still worse than P2TR today in both aspects (key-based = spend is still more expensive compared to P2TR, and the incentive for key-b= ased over script-based spend is weaker within P2MR). Yep, all agreed there. These changes would make P2MR better, but still not = as good as taproot for pre-Q-day spending. > my reasoning is primarily that the "Never" and/or "Immediately" options a= re just insufficient with current technology for any worthwhile migration a= ttempt (independent of which commitment structure is used), and thus that w= e simply need the "Later" option. Also agreed. Though I take things a step further as I suspect we will also = be forced to restrict legacy coins by deploying a rescue protocol, but so f= ar i'm following w.r.t the new output type. Whether it's P2MR or P2TRv2, EC= disabling will be highly desirable. > Once you accept that, there is a secondary line of reasoning about which = specific structure(s) are , and that is where taproot-based constructions c= ome out ahead by having better incentives in the short- to medium term (the= numbers above mean essentially less/zero economical friction). This is where you lose me. Why does P2TRv2 incentivize migration better tha= n P2MR? You'd have to assume EC disabling will happen and will be timed per= fectly. Then assume everyone using Bitcoin will have utter confidence in th= is TBD timing solution, and no reason to doubt it will work perfectly. Even then, AFAICT the only distinction to the lay user between P2MR and P2T= Rv2 is that P2TRv2 is more efficient pre-Q-day, and P2MR is more efficient = afterward, and both by about the same margin: 32 witness bytes (counting Bo= ris' EC recovery improvement). That's=C2=A08 vbytes per Schnorr spend - les= s than a cent at current rates. Theorycrafting for a second here. It's reasonable to conjecture fee rates w= ill be much higher post-Q-day, and thus P2MR's 32 byte advantage over P2TRv= 2 will yield significant savings for end-users in absolute terms. If fee ra= tes inflate 10x higher after Q-day, then 8 vbytes becomes significant (100 = sats per spend or more). In other words, the P2TRv2 internal key will be mu= ch more expensive to a user after Q-day than P2MR's PQ leaf script hash wil= l be to a user today. There are other DX considerations, like P2TRv2 being easier to deploy initi= ally, while P2MR is easier to maintain in the long term since it has no EC = code. Etc. But i'm discounting those trade-offs to focus only on the end-us= ers here. > There is one technical difference where the specific commitment structure= matters: P2MR ("Merkle-Never") can be used in a Q-safe way and a hypotheti= cal "Taproot-Never" cannot (which includes P2TRv2, if you don't believe in = being able to rely on the future narrow disabling), which seems to be the p= rimary reason people like it. However, I think this is extremely restrictiv= e, and simply not an option for most users, because it means: >=20 > - Not using wallet indexing services that transmit public keys/xpubs. > =20 > - ... You're saying that P2MR without an EC disable fork is not perfectly secure = assuming current Bitcoin usage patterns continue. I agree, which is why an = EC disabling soft-fork will almost certainly be needed.=C2=A0"Merkle-Never"= is impossible IMO. Sooner or later we will disable EC spending in P2MR. I think our disagreement comes from your assumption we must always time the= disabling fork perfectly to coincide with Q-day. On the other hand, I expe= ct we will not solve the fork timing problem, so an EC disable fork will be= a messy, panicked affair, arriving possibly quite late (months or years af= ter Q-day). With P2MR, at least holders who used it properly will have shel= ter, and those who didn't will have an opportunity to move coins somewhere = safe to ride things out. P2TRv2 has no such room for compromise: either everyone is exposed, or nobo= dy is. Well except for all the people who didn't migrate, they're still exp= osed (which is why we'll need a rescue protocol either way). > And if you accept that at least a "Later" option is needed, I think addin= g more PQC options actually weakens it! If some people have their coins in = "Never" or "Now" outputs in a PQC-safe manner (subject to the restriction /= costs those bring), then that reduces the incentive to get the "Later" nar= row EC freeze to occur, and indirectly reduces the value of that output typ= e. Interesting. It sounds like you're arguing that because P2TRv2 is blatantly= PQ-vulnerable, it will incentivize future bitcoin users to lock it down la= ter.=C2=A0I mean yes, that's technically true, but that would be like putti= ng a spike on the steering wheels of cars, to incentivize drivers to wear s= eatbelts. Should we really bet the entire network on that incentive working out? Even= if you're right and we all want very-badly to deploy EC disabling later, h= ow can we know we'll time it correctly? Remember, it's not just me you have to convince. You'd have to convince eve= ryone to deploy and then adopt P2TRv2 today=C2=A0under the public knowledge= that it is insecure and their coins are more likely to be stolen. That's a= hard sell. How does one pitch P2TRv2 to users? "It will be quantum secure one day we p= romise because everyone is incentivized to fix it later as Bitcoin will die= if we don't." How do you pitch P2MR? "It's quantum secure if you use it correctly." > I don't understand this, can you elaborate? Having a knowledge-asymmetry = seems like something that matters for ZK machinery. Gladly! Any hard relation that can be proven in ZK can also be proven with = commit/reveal. It's less flexible because it's not zero-knowledge, so you h= ave to reveal the secret data, and you can only do that once securely. Esse= ntially any PQ-hard relation for which you have knowledge-asymmetry grants = you a one-time use signature that cannot be forged by a QC. If you use that= OTS to certify a public key (e.g. a SHRINCS key), you can then sign multip= le messages. The simplest example is a hash preimage. With preimage `P` and message `m`,= I publish `H(P)` and `H(P, m)` at time `T`. Then I reveal `(P, m)` at time= `T+1`. A verifier checks=C2=A0`H(P, m)` was published first, and confirms = there exist no earlier reveals for `P (by looking for` `H(P)`). This confir= ms I must have also approved the message `m`. A similar mechanism is used a= s the core coin authentication system of FawkesCoin. There are complexities= to handle especially regarding censorship attacks, but ultimately it's doa= ble. I used a hash function as the relation here, but this can be used to prove = any quantum-hard relation: BIP32 derivation, taproot tweaking, musig keys, = hashed addresses, etc. You just have to endow the verifier with the correct= validation procedures. We're still finding new relevant knowledge-asymmetr= ies today. I really ought to start cataloging them better... I'm hoping to = spend more time on this field in the near future because I think it's going= to be very important, and right now all the knowledge just lives in mailin= g list archives. > It sounds like you're really saying that the systemic migration to PQC is= something that will happen through a commit/reveal, not through what we're= discussing now. So what is the point of having something like P2MR or P2TR= v2 in the near term? Because consensus changes take years to deploy, and we're running out of th= ose. Many people seem to think so at least, I'm no physicist. Essentially yes though, I expect the majority of holders will probably migr= ate to PQ addresses via rescue protocols, either on Bitcoin or a fork there= of. Even if we can't come to consensus and deploy a new output type, we'll = still be able to rescue most coins. It's just that we'd have nowhere to res= cue them to, so we ought to make PQ wallets available soon, so we're not in= a rush to build them later when we need them. If a PQ wallet can use cheap= EC signatures while they're still trustworthy, all the better. regards, conduition On Thursday, June 11th, 2026 at 5:35 AM, Pieter Wuille wrote: > Hi conduition, >=20 > See more comments inline below. >=20 > On Saturday, June 6th, 2026 at 3:33 PM, conduition = wrote: >=20 > > Hey Pieter, nice to hear from you too on this.=C2=A0 > >=20 > >=20 > > Do you have any take on the OP idea about P2MR depth restrictions? >=20 >=20 > I think it improves one aspect of the incentive differences (relative cos= ts within the output type for common vs. uncommon). The key recovery idea i= mproves another (relative costs w.r.t. P2TR in the common case). Even with = both, the result is still worse than P2TR today in both aspects (key-based = spend is still more expensive compared to P2TR, and the incentive for key-b= ased over script-based spend is weaker within P2MR). >=20 > I want to take a step back however and separate the discussion into two s= omewhat orthogonal dimensions along which P2MR and P2TRv2 differ, because d= iscussing the details sometimes conflates them: >=20 > - The exact commitment structure (Merkle root, variations with branch l= ength / key recovery, Taproot structure, ...). > - The expectation of when an=C2=A0EC-disabling consensus change happens= : >=20 > - "Never", or as part of a wide (not-output-specific) EC disabling/free= ze (P2MR) > - "Later", through a later softfork that specifically disables EC narro= wly in that output type (P2TRv2) > - "Now", Immediately in that output type ("P2QR", i.e., P2MR with all E= C opcodes disabled from the start). >=20 >=20 >=20 > Tweaking the commitment structure modifies the incentives of one over the= other under some conditions, but I think the question of when/how the EC-d= isabling happens is the more fundamental one, and it is largely independent= of the commitment structure. I'll go into more detail below, but my reason= ing is primarily that the "Never" and/or "Immediately" options are just ins= ufficient with current technology for any worthwhile migration attempt (ind= ependent of which commitment structure is used), and thus that we simply ne= ed the "Later" option. Once you accept that, there is a secondary line of r= easoning about which specific structure(s) are , and that is where taproot-= based constructions come out ahead by having better incentives in the short= - to medium term (the numbers above mean essentially less/zero economical f= riction). >=20 >=20 > I also want to point out there that Merkle-Never and Merkle-Later are two= very fundamentally different things, and we can't just decide at a later p= oint in time whether a narrow fork should still be applied. If the expectat= ion is no EC-disabling in it, then disabling is confiscatory. >=20 >=20 > There is one technical difference where the specific commitment structure= matters: P2MR ("Merkle-Never") can be used in a Q-safe way and a hypotheti= cal "Taproot-Never" cannot (which includes P2TRv2, if you don't believe in = being able to rely on the future narrow disabling), which seems to be the p= rimary reason people like it. However, I think this is extremely restrictiv= e, and simply not an option for most users, because it means: >=20 > - Not using wallet indexing services that transmit public keys/xpubs. > - Not using hardware wallets with watchonly software wallets that rely = on xpubs/descriptors. > - Not using multisig (or MuSig/threshold schemes/...). Even a PKH-based= multisig (as you suggested elsewhere) is icky due to parties needing to sh= are signatures with each with each other, of coins that aren't necessarily = going to be spent. > - Not using Lightning. > - Not using silent payments. > - Not using escrow services (like Blockstream's or BitGo's 2-of-3 walle= t services). > - Not spending fork coins / airdrops. > - Never reusing addresses. >=20 > Of course, with evolving technology and other developments, some of these= =C2=A0restrictions may weaken. Alternatives for some of these may be develo= ped, but I don't think think fundamentally everything can be addressed. By = their nature, public keys are designed to be public, and I don't believe we= can realistically migrate the whole ecosystem (even in the long term) off = that premise. The real solution is feature-rich efficient PQC signature sch= emes of course, but those do not exist today. If we want to start a migrati= on in the near-term, with today's technology, it needs to be compatible wit= h today's ecosystem. >=20 >=20 > > If PQ fear is indeed such a strong motivating factor as you hypothesize= , wouldn't this be an argument against P2TRv2? P2TRv2 isn't quantum-resista= nt by default but P2MR is. Personally, if I thought a CRQC is imminent, I w= ould rather sell my coins or stow them in a P2WSH address than migrate to a= n address format which requires a follow-up fork to be secure.=C2=A0 > >=20 > > To borrow a phrase, P2TRv2 bears a systemic risk=C2=A0(solving the fork= timing problem), whereas P2MR has only=C2=A0local risk (address reuse,=C2= =A0which btw would also be solved if we could solve fork-timing). Antoine d= rew this comparison on his post too but we apparently disagree on which is = preferable. >=20 >=20 > This indeed touches on a fundamental difference in viewpoint. >=20 > I believe the primary risk in both approaches ("Never" and "Later") is sy= stemic! Bitcoin either as a whole migrates to PQC resistance, or not and ev= eryone loses. If too many(*) vulnerable coins/users remain on Q-day, I beli= eve the remaining options are all damaging for everyone, because a wide EC = freeze may be necessary to remain relevant (who would use a currency where = many coins are vulnerable to theft?), but doing so likely undermines Bitcoi= n's long-term value proposition (how does it differ from an native-PQC altc= oin bootstrapped with some arbitrary subset of Bitcoin's UTXO set?).=C2=A0I= ndividual users adopting a quantum-resistant workflow without an expectatio= n that most other users will do the same is not a migration strategy, but a= hedge against Bitcoin's ability to meaningfully migrate in time. Yes, if a= vailable there will certainly be users taking it, but I'm not convinced it = is beneficial for the success probability of currency-wide migration if a "= Later" option is available too, and possibly worse. >=20 > The "Later" option does not have all the restrictions listed above, and I= believe has a chance of getting adopted in the medium term by everyone if = available with sufficiently low friction. That of course brings us to how t= he expectation of a future EC softfork can be relied upon. And it is someth= ing of a self-fulfilling prophecy I think. If literally all PQC defense of = Bitcoin were to be done through one new output type, then it seems almost a= given that the EC disabling will happen in time: even if "Bitcoin" doesn't= , someone will create a fork that does so in time, and if it's that essenti= al, that fork will win. A concern may exist about potential disagreement wi= thin the community about when the disable-fork should occur, but I think it= 's still a far better prospect than... essentially making Q-day a guarantee= d disaster apart from a few people that get to save their coins, if it happ= ens before the future feature-rich efficient PQC signature schemes can be a= dopted. >=20 > And if you accept that at least a "Later" option is needed, I think addin= g more PQC options actually weakens it! If some people have their coins in = "Never" or "Now" outputs in a PQC-safe manner (subject to the restriction /= costs those bring), then that reduces the incentive to get the "Later" nar= row EC freeze to occur, and indirectly reduces the value of that output typ= e. >=20 > (*) =3D I don't know what numbers are the threshold here, or how users vs= . coins compares. Still, reducing the number of coins/users for which the "= theft vs freeze" applies always seems like a win. >=20 >=20 > > Users and devs can control local risk with very simple software tweaks = (to avoid address reuse) but they can't do anything about systemic risks. >=20 >=20 > I think you're vastly underestimating what is simple for most uses. Not s= haring public keys or signatures with untrusted parties is a wildly differe= nt world than we have today. >=20 >=20 > > This is why I prefer P2MR. If the fork-timing problem can be solved con= clusively then maybe P2TRv2 would be viable, but as you've alluded to, we h= ave yet to hear any passable solution that doesn't require a cooperative CR= QC. >=20 >=20 > I think it has a much higher chance of getting ~everyone on it in time, e= ven if there is no certainty. >=20 >=20 >=20 > > I lack data, but I suspect that by Q-day most coins will have some know= ledge-asymmetry with a CRQC (hash preimages, BIP32 parent keys, hidden P2TR= script paths, etc) and so can be rescued with simple commit/reveal protoco= ls - no heavy ZK machinery or hard-forks needed. >=20 >=20 > I don't understand this, can you elaborate? Having a knowledge-asymmetry = seems like something that matters for ZK machinery. >=20 >=20 > > With that in mind, then it doesn't really matter how many recoverable c= oins migrate before Q-day, does it? If you can assume P2TRv2's PQ-security = promise will be deployed on-time, then you can also assume any BIP32 wallet= in-use today can be rescued. What we really must care about is migrating t= he unrecoverable fraction of coins (e.g. JBOK wallets with exposed pubkeys)= . These should already be rare and will only become rarer as more time pass= es. >=20 >=20 > I think anything relying on BIP32 recovery is disaster-recovery territory= , not interesting migration, because it'll inevitably be an arbitrary subse= t that survives. It's something people can think about of course for use in= case of a Q-day before migration to PQC-safe outputs at scale happens. As = I've argued, that's probably an uninteresting outcome for everyone. People = will want to do what they to save what remains, but I don't think it should= really matter in this discussion today. >=20 > Also, It sounds like you're really saying that the systemic migration to = PQC is something that will happen through a commit/reveal, not through what= we're discussing now. So what is the point of having something like P2MR o= r P2TRv2 in the near term? >=20 > > On a more positive note, if we can someday say "Look, quantum computers= appeared and screwed some people over, but most people can recover their c= oins as long as they fulfill any one of these common criteria," then that s= eems like Bitcoin's unique value and confiscation resistance is surprisingl= y intact to me. Certainly better than certain other altcoin migrations I've= seen in the past, but I guess this is a subjective question, and everyone = will have their own opinion. >=20 >=20 > Yeah, I have a pretty different view here. >=20 > --=C2=A0 > Pieter >=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/_z6_JUmphCkUYvI6gemSFMD9Sb_rDL03IQbtZQCNlk6pmioGEQBir_gMyZCfticFa8Ttfc0xo= FHdxR07_MNuAfBu8do_h5IDf2apVk1w1BM%3D%40wuille.net. --=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/= E2-B_JaZeZg3tFHhiGcp-Mitl34-_uxcTVga5ogSMKOfeCvjHuzox7EXNw6GdlC4ggEIehP2elA= 3xnmvBSvIMnNu-QSHqGW81MzvD8BKRRI%3D%40proton.me. -----------------------bebd4c86eb1e3ee3c3b116d1282cac24 Content-Type: multipart/related;boundary=---------------------0ead965a8412657853ba1253f54fd411 -----------------------0ead965a8412657853ba1253f54fd411 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Pieter,
<= br>
I think it improves one aspect of the incentive dif= ferences (relative costs within the output type for common vs. uncommon). T= he key recovery idea improves another (relative costs w.r.t. P2TR in the co= mmon case). Even with both, the result is still worse than P2TR today in bo= th aspects (key-based spend is still more expensive compared to P2TR, and t= he incentive for key-based over script-based spend is weaker within P2MR).<= /span>

Yep, all agreed there. These cha= nges would make P2MR better, but still not as good as taproot for pre-Q-day= spending.

my reasoning is primarily that t= he "Never" and/or "Immediately" options are just insufficient with current = technology for any worthwhile migration attempt (independent of which commi= tment structure is used), and thus that we simply need the "Later" option.<= /span>

Also agreed. Though I take thing= s a step further as I suspect we will also be forced to restrict legacy coi= ns by deploying a rescue protocol, but so far i'm following w.r.t the new o= utput type. Whether it's P2MR or P2TRv2, EC disabling will be highly desira= ble.

Once you accept that, there is a= secondary line of reasoning about which specific structure(s) are , and th= at is where taproot-based constructions come out ahead by having better inc= entives in the short- to medium term (the numbers above mean essentially le= ss/zero economical friction).

This is where you lose me. Why does P2TRv2 incentivize migration better = than P2MR? You'd have to assume EC disabling wil= l happen and will be timed perfectly. Then assume everyone using Bitcoin wi= ll have utter confidence in this TBD timing solution, and no reason to doub= t it will work perfectly.

Even then, AF= AICT the only distinction to the lay user between P2MR and P2TRv2 is that P= 2TRv2 is more efficient pre-Q-day, and P2MR is more efficient afterward, an= d both by about the same margin: 32 witness bytes (counting Boris' EC recov= ery improvement). That's <= span style=3D"font-size: 10.5pt; line-height: normal; font-family: Arial, s= ans-serif; display: inline !important; background-color: rgb(255, 255, 255)= ;">8 vbytes per Schnorr spend - less than a cent at current rates.

Theorycrafting for a second here. It's reasonable t= o conjecture fee rates will be much higher post-Q-day, and thus P2MR's 32 b= yte advantage over P2TRv2 will yield significant savings for end-users in a= bsolute terms. If fee rates inflate 10x higher after Q-day, then 8 vbytes b= ecomes significant (100 sats per spend or more). In other words, the P2TRv2= internal key will be much more expensive to a user after Q-day than P2MR's= PQ leaf script hash will be to a user today.

There are other DX considerations, like P2TRv2 bei= ng easier to deploy initially, while P2MR is easier to maintain in the long= term since it has no EC code. Etc. But i'm discounting those trade-offs to= focus only on the end-users here.

There is one technical dif= ference where the specific commitment structure matters: P2MR ("Merkle-Neve= r") can be used in a Q-safe way and a hypothetical "Taproot-Never" cannot (= which includes P2TRv2, if you don't believe in being able to rely on the fu= ture narrow disabling), which seems to be the primary reason people like it= . However, I think this is extremely restrictive, and simply not an option = for most users, because it means:
  • Not using wallet indexing services that transmit public keys/xpu= bs.
  • ...<= /span>

You're saying that P2MR without an EC disable fork is not pe= rfectly secure assuming current Bitcoin usage patterns continue. I agree, w= hich is why an EC disabling soft-fork will almost certainly be needed. = ;"Merkle-Never" is impossible= IMO. Sooner or later we will disable EC spending in P2MR.

I think our disagreement comes from your assumption we must= always time the disabling fork perfectly to coincide with Q-day. On the ot= her hand, I expect we will not solve the fork timing problem, so an EC disa= ble fork will be a messy, panicked affair, arriving possibly quite late (mo= nths or years after Q-day). With P2MR, at least holders who used it properl= y will have shelter, and those who didn't will have an opportunity to move = coins somewhere safe to ride things out.

P2= TRv2 has no such room for compromise: either everyone is exposed, or nobody= is. Well except for all the people who didn't migrate, they're still expos= ed (which is why we'll need a rescue protocol either way).

And if you accept = that at least a "Later" option is needed, I think adding more PQC options a= ctually weakens it! If some people have their coins in "Never" or "Now" out= puts in a PQC-safe manner (subject to the restriction / costs those bring),= then that reduces the incentive to get the "Later" narrow EC freeze to occ= ur, and indirectly reduces the value of that output type.
=

Interesting. It sounds like you're arguin= g that because P2TRv2 is blatantly PQ-vulnerable, it will incentivize futur= e bitcoin users to lock it down later. I mean yes, that's technically= true, but that would be like putting a spike on the steering wheels of car= s, to incentivize drivers to wear seatbelts.

Should we really bet = the entire network on that incentive working out? Even if you're right and = we all want very-badly to deploy EC disabling later, how can we know we'll = time it correctly?

Remember, it's not just me you have to convince. = You'd have to convince everyone to deploy and then adopt P2TRv2 today = under the public = knowledge that it is insecure and their coins are more likely to be stolen<= /i>. That's a hard s= ell.

How does one pitch P2TRv2 to users? "It will be quantum secure = one day we promise because everyone is incentivized to fix it later as Bitc= oin will die if we don't."

How do you pitch P2MR? "It's quantum secu= re if you use it correctly."

I don't under= stand this, can you elaborate? Having a knowledge-asymmetry seems like some= thing that matters for ZK machinery.

Gladly! Any hard relation that can be proven in ZK can also be proven= with commit/reveal. It's less flexible because it's not zero-knowledge, so= you have to reveal the secret data, and you can only do that once securely= . Essentially any PQ-hard relation for which you have knowledge-asymmetry g= rants you a one-time use signature that cannot be forged by a QC. If you us= e that OTS to certify a public key (e.g. a SHRINCS key), you can then sign = multiple messages.

The simplest exa= mple is a hash preimage. With preimage P=E2=80=8B and message m=E2=80=8B, I publish H(P)=E2=80=8B and H(P, m)<= /code>=E2=80=8B at time T=E2=80=8B=E2=80=8B. Then I reveal (P, m)=E2=80=8B=E2=80=8B=E2=80=8B at time T+1=E2=80=8B. A verifier checks <= code>H(P, m)<= span style=3D"font-family: Arial, sans-serif;">=E2=80=8B was published firs= t, and confirms there exist no earlier reveals for P (by looking for = H(P)=E2=80=8B=E2=80=8B). This confirms I=E2=80=8B=E2=80=8B. A similar mechanism = is used as the core coin authentication system of FawkesCoin. There are complexities to handle especiall= y regarding censorship attacks, but ultimately it's doable.

I used a hash function as the relation here, but this can = be used to prove any quantum-hard relation: BIP32 derivation, taproot tweak= ing, musig keys, hashed addresses, etc. You just have to endow the verifier= with the correct validation procedures. We're still finding new relevant k= nowledge-asymmetries today. I really ought to start cataloging them better.= .. I'm hoping to spend more time on this field in the near future because I= think it's going to be very important, and right now all the knowledge jus= t lives in mailing list archives.

It = sounds like you're really saying that the systemic migration to PQC is some= thing that will happen through a commit/reveal, not through what we're disc= ussing now. So what is the point of having something like P2MR or P2TRv2 in= the near term?

Because = consensus changes take years to deploy, and we're running out of those. Many people seem to think so at least, I'm no physicist.<= /div>

= Essentially yes though, I expect the majority of holders will probably migr= ate to PQ addresses via rescue protocols, either on Bitcoin or a fork there= of. Even if we can't come to consensus and deploy a new output type, we'll = still be able to rescue most coins. It's just that we'd have nowhere to res= cue them to, so we ought to make PQ wallets available soon, so we're not in= a rush to build them later when we need them. If a PQ wallet can use cheap= EC signatures while they're still trustworthy, all the better.

regards,
conduition

=


On Thursday, June 11th, 2026 at 5:35 AM, Pieter Wuille <bitcoin-= dev@wuille.net> wrote:
Hi conduition,

See more comments inlin= e below.

On Saturday, June 6th, 2026 at 3:33 PM, conduition <condu= ition@proton.me> wrote:
Hey Pieter, ni= ce to hear from you too on this. 

Do you have any take on the OP idea about P2MR de= pth restrictions?

I= think it improves one aspect of the incentive differences (relative costs = within the output type for common vs. uncommon). The key recovery idea impr= oves another (relative costs w.r.t. P2TR in the common case). Even with bot= h, the result is still worse than P2TR today in both aspects (key-based spe= nd is still more expensive compared to P2TR, and the incentive for key-base= d over script-based spend is weaker within P2MR).

I want to take a step back however and separate the discussion i= nto two somewhat orthogonal dimensions along which P2MR and P2TRv2 differ, = because discussing the details sometimes conflates them:
  • The = exact commitment structure (Merkle root, variations with branch length / ke= y recovery, Taproot structure, ...).
  • The expectation of when an EC-disabling consensus chan= ge happens:
    • "Never", or as part of a = wide (not-output-specific) EC disabling/freeze (P2MR)
      • "Later", through a later softfork that specifically= disables EC narrowly in that output type (P2TRv2)
    • "Now", Immediately in that output type ("P2QR", i.e., = P2MR with all EC opcodes disabled from the start).
    <= /ul>

    Tweaking the = commitment structure modifies the incentives of one over the other under so= me conditions, but I think the question of when/how the EC-disabling happen= s is the more fundamental one, and it is largely independent of the commitm= ent structure. I'll go into more detail below, but my reasoning is primaril= y that the "Never" and/or "Immediately" options are just insufficient with = current technology for any worthwhile migration attempt (independent of whi= ch commitment structure is used), and thus that we simply need the "Later" = option. Once you accept that, there is a secondary line of reasoning about = which specific structure(s) are , and that is where taproot-based construct= ions come out ahead by having better incentives in the short- to medium ter= m (the numbers above mean essentially less/zero economical friction).

    I a= lso want to point out there that Merkle-Never and Merkle-Later are two very= fundamentally different things, and we can't just decide at a later point = in time whether a narrow fork should still be applied. If the expectation i= s no EC-disabling in it, then disabling is confiscatory.

    There is one tec= hnical difference where the specific commitment structure matters: P2MR ("M= erkle-Never") can be used in a Q-safe way and a hypothetical "Taproot-Never= " cannot (which includes P2TRv2, if you don't believe in being able to rely= on the future narrow disabling), which seems to be the primary reason peop= le like it. However, I think this is extremely restrictive, and simply not = an option for most users, because it means:
    • Not using wallet ind= exing services that transmit public keys/xpubs.
    • Not using hardware = wallets with watchonly software wallets that rely on xpubs/descriptors.
    • Not using multisig (or MuSig/threshold schemes/...). Even a PKH-based = multisig (as you suggested elsewhere) is icky due to parties needing to sha= re signatures with each with each other, of coins that aren't necessarily g= oing to be spent.
    • Not using Lightning.
    • Not using silent payments.
    • N= ot using escrow services (like Blockstream's or BitGo's 2-of-3 wallet servi= ces).
    • Not spending fork coins / airdrops.
    • Never reusing add= resses.

    Of course, with evolving technolog= y and other developments, some of these restrictions may weaken.= Alternatives for some of these may be developed, but I don't think think f= undamentally everything can be addressed. By their nature, public keys are = designed to be public, and I don't believe we can realistically migrate the= whole ecosystem (even in the long term) off that premise. The real solutio= n is feature-rich efficient PQC signature schemes of course, but those do n= ot exist today. If we want to start a migration in the near-term, with toda= y's technology, it needs to be compatible with today's ecosystem.

    If PQ fear i= s indeed such a strong motivating factor as you hypothesize, wouldn't this = be an argument against P2TRv2? P2TRv2 isn't quantum-resistant by default bu= t P2MR is. Personally, if I thought a CRQC is imminent, I would rather sell= my coins or stow them in a P2WSH address than migrate to an address format= which requires a follow-up fork to be secure. 

    To borrow a phrase, P2TRv2 bears a systemic risk = (solving the fork timing problem), whereas P2MR has only local risk= (address reuse, which btw would also be solved if we could= solve fork-timing). Antoine drew this comparison on his post too but we ap= parently disagree on which is preferable.

    This indeed touches on a fundamental difference in viewpoin= t.

    I believe the primary risk in both a= pproaches ("Never" and "Later") is systemic! Bitcoin either as a whole m= igrates to PQC resistance, or not and everyone loses. If too many(*) vu= lnerable coins/users remain on Q-day, I believe the remaining options are all damaging for everyone, because a wide EC freeze may be necessary to remain relevant (who would use a currency where many coins are vulnerable to theft?), but doing so likely undermines Bitcoin's long-term value proposition (how does it differ from an native-PQC altcoin bootstrapped with some arbitrary subset of Bitcoin's UTXO set?). Individual users adopting a quantum-resistant wo= rkflow without an expectation that most other users will do the same is not= a migration strategy, but a hedge against Bitcoin's ability to meaningfull= y migrate in time. Yes, if available there will certainly be users taking i= t, but I'm not convinced it is beneficial for the success probability of cu= rrency-wide migration if a "Later" option is available too, and possibly wo= rse.

    The "Later" option does not have all the restrictions listed above, and = I believe has a chance of getting adopted in the medium term by everyone if= available with sufficiently low friction. That of course brings us to how = the expectation of a future EC softfork can be relied upon. And it is somet= hing of a self-fulfilling prophecy I think. If literally all PQC defense of= Bitcoin were to be done through one new output type, then it seems almost = a given that the EC disabling will happen in time: even if "Bitcoin" doesn'= t, someone will create a fork that does so in time, and if it's that essent= ial, that fork will win. A concern may exist about potential disagreement w= ithin the community about when the disable-fork should occur, but I think i= t's still a far better prospect than... essentially making Q-day a guarante= ed disaster apart from a few people that get to save their coins, if it hap= pens before the future feature-rich efficient PQC signature schemes can be = adopted.

    And if you accept that at least a "Later"= option is needed, I think adding more PQC options actually weakens it! If = some people have their coins in "Never" or "Now" outputs in a PQC-safe mann= er (subject to the restriction / costs those bring), then that reduces the = incentive to get the "Later" narrow EC freeze to occur, and indirectly redu= ces the value of that output type.


Users and d= evs can control local risk with very simple software tweaks (to avoid addre= ss reuse) but they can't do anything about systemic risks.

I think you're vastly underestimating what= is simple for most uses. Not sharing public keys or signatures with untrus= ted parties is a wildly different world than we have today.

T= his is why I prefer P2MR. If the fork-timing problem can be solved conclusi= vely then maybe P2TRv2 would be viable, but as you've alluded to, we have y= et to hear any passable solution that doesn't require a cooperative CRQC.

=
I think it has a much= higher chance of getting ~everyone on it in time, even if there is no cert= ainty.

I lack data, but I s= uspect that by Q-day most coins will have some knowledge-= asymmetry with a CRQC (hash preimages, BIP32 parent keys, hidden P2TR scrip= t paths, etc) and so can be rescued with simple commit/reveal protocols - n= o heavy ZK machinery or hard-forks needed.

I don't understand this, can you elaborate? Having a knowl= edge-asymmetry seems like something that matters for ZK machinery.

With that in mind, then it doesn't really matter how man= y recoverable coins migrate before Q-day, does it? If you can assume= P2TRv2's PQ-security promise will be deployed on-time, then you can also a= ssume any BIP32 wallet in-use today can be rescued. What we really must car= e about is migrating the unrecoverable fraction of coins (e.g. JBOK = wallets with exposed pubkeys). These should already be rare and will only b= ecome rarer as more time passes.

I think anything relying on BIP32 recovery is disaster-recovery terr= itory, not interesting migration, because it'll inevitably be an arbitrary = subset that survives. It's something people can think about of course for u= se in case of a Q-day before migration to PQC-safe outputs at scale happens= . As I've argued, that's probably an uninteresting outcome for everyone. Pe= ople will want to do what they to save what remains, but I don't think it s= hould really matter in this discussion today.

Also, It sounds like you're really saying that the systemic migration to PQC is som= ething that will happen through a commit/reveal, not through what we're discussing now. So what is the point of having something like P2MR or P2TRv= 2 in the near term?
=

On a more positive note, if we ca= n someday say "Look, quantum computers appeared and screwed some people = over, but most people can recover their coins as long as they fulfill any o= ne of these common criteria," then that seems like Bitcoin's unique val= ue and confiscation resistance is surprisingly intact to me. Certainly bett= er than certain other altcoin migrations I've seen in the past, but I guess= this is a subjective question, and everyone will have their own opinion.

=
Yeah, I have a pretty diffe= rent view here.

-- 
Pieter

--
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+u= nsubscribe@googlegroups.com.
To view this discussion visit = https://groups.google.com/d/msgid/bitcoindev/_z6_JUmphCkUYvI6gemSFMD9Sb_rDL= 03IQbtZQCNlk6pmioGEQBir_gMyZCfticFa8Ttfc0xoFHdxR07_MNuAfBu8do_h5IDf2apVk1w1= BM%3D%40wuille.net.

--
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/E2-B_J= aZeZg3tFHhiGcp-Mitl34-_uxcTVga5ogSMKOfeCvjHuzox7EXNw6GdlC4ggEIehP2elA3xnmvB= SvIMnNu-QSHqGW81MzvD8BKRRI%3D%40proton.me.
-----------------------0ead965a8412657853ba1253f54fd411-- -----------------------bebd4c86eb1e3ee3c3b116d1282cac24-- -----------------------55b83315454d21f469cdc54957bc5477 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== -----------------------55b83315454d21f469cdc54957bc5477-- --------140bf57b802d841575d160c5d6afeb57f44f19ab034df729681988bc670f89e5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wrsEARYKAG0FgmorjmsJEHgpbO2E9rPFRRQAAAAAABwAIHNhbHRAbm90YXRp b25zLm9wZW5wZ3Bqcy5vcmetCGZJdBjAkFx58exfnTeX/Sfjt/40PaN/6AaS zRvlghYhBEdIka0CMtrLdg13a3gpbO2E9rPFAAB5TwEA7dR+qV/s6mI/4XO/ 8bugWcz77gzgGmwGk5DbS8HiwxYA/1Ph9XSNw1FVE6KQTwhYVlef6R2Lqcq8 hprLNq73b1IB =hMOC -----END PGP SIGNATURE----- --------140bf57b802d841575d160c5d6afeb57f44f19ab034df729681988bc670f89e5--