From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 03 Jun 2026 16:27:00 -0700 Received: from mail-oo1-f62.google.com ([209.85.161.62]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wUuzC-0006Gw-6V for bitcoindev@gnusha.org; Wed, 03 Jun 2026 16:27:00 -0700 Received: by mail-oo1-f62.google.com with SMTP id 006d021491bc7-69e3f2df5e4sf170376eaf.0 for ; Wed, 03 Jun 2026 16:26:57 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1780529199; cv=pass; d=google.com; s=arc-20240605; b=hqLSIXLJOrAWsNFFuyA+rl3jn6xbM2u5CMIiE1TjP4aKsYkKmmG8VoDBc4H3yAxup9 TCfJUmw4Ij9CXFk0VdoLGMyDAujOYcQ4BkLvSa88GpM88X/y944n5KgMVjKyGV4LAfnH vNcIIHUpDQD1ejLSG++fxRaDgELVKsTjsnKTNbvNiPQmmGE1aOWzyNtuMub5nKfCqXdK JiELGlPLXU60lBDc/FTfFI/8Nbf1ugI7j1WMOVzFd6p4s/NytakjdxYE5c4cAD+UksQ/ 7iMkB/O57rr1qLzrp9X/dY2tQIZ2uDb5fkBACcJxif4qugqmMcrc8K5TE9Z+xxtemsjN FRtg== 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 :message-id:subject:from:to:date:dkim-signature; bh=I3d67Ngsccwjf8JLPhrjI9RY9g7fMdm9J9pZNWpsBBo=; fh=CoYaUb0tQyGuY4TzC/hm6wR5uhEdVS9KEIdkvYzaYQ0=; b=SyHWP2Bx46evk4K1Mukt2552Ol5P9vDWiVNBMeA3uzJWuDu6ef9RrWTwzkrmXGg2U2 cJb0J4oZK5CEiLO/OrPVxptA7LNbDsnj/xsN9tcnbpg5bnTp8zLW5NWVQG2xeDLh28RB T3+TVVOOdjjyASRzylZrjShxC5jov0pnrkOht63jAN5K8zCrgruIFuJTEmSyaJeqnr+4 7rVcspPFlo+fTHZZtRDh5lQmpopVMkGnucM1x67sYM/eUaKYffEV5QTLzz/XfeRRJiQT 34xO5b4HWl8h7mlJNmRbdgHW//uFv5ZL35NpDHRghduUkgeWW1SRScwk1ltZEWx3Zj6/ 7OiA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=624qjmanmzcytaextdsj2bug6i.protonmail header.b=R3S46xiS; spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.99 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=1780529199; x=1781133999; 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:message-id:subject:from:to:date:from:to:cc:subject:date :message-id:reply-to; bh=I3d67Ngsccwjf8JLPhrjI9RY9g7fMdm9J9pZNWpsBBo=; b=ud6UlNB8Fvg13bjjeldrETc4CjXK6xkx7w9nLkPpSqUfVqpmdkvkJMLuRpzYKgakmD fB4stRbIR/1P/cgeY4Me4C6/dZcubLyUEzU7qXHYXJfjbaLz6ZvlYQtgFx8cqLEPLVZh V2F7yhuZjz7s/paNP4QYpU4xavoS/AvKCLlE/lTxXHW26eZpGmQ1Q5GK64H464JZE+iq yzzbbCbi2dxXjMDdBrs+DBj8jQALTWXyviq8hGoxFptIzpONQ9dL6phi8iltF0KtPAed MQheZTSrVjQbu36MFZ+a/uScx2pdWuK94FPW5dsOEZd/9QrktNcffwa48a+MNAKvw5ic wmDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780529199; x=1781133999; 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:message-id:subject:from:to:date:x-beenthere :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=I3d67Ngsccwjf8JLPhrjI9RY9g7fMdm9J9pZNWpsBBo=; b=GGELCJObJ8Eu5x1ZkO5NJ41OeGBhTKT9knxytlsWsu5XxMdRFx9Dd8IMt5CyVa6l0m iRUHYRYlbFvO8U2zFPA/tnCt+KWsgE3DmyrRwIARMWHT9H/CX+FgVPTqNK9GiHEzZ2nw nVZ6v1ccD+eFku+oaryBKjq9inj7xPTsu6MZOT5gRXd/Ykmd0s1Pwa3Jjk+G0vZ87cIi PsnLxxbiJkuiD9IG9n8efgIqtydj/ZlCh0Rj2gVyKkWsiDsYiiu2eThe5gRzLLbKuRcx sklrFA7GPongA50jnhtbcYGSOOgus8uSxleGE6nv9Cu7KROTD/GpSPxoEnrRA3YRtTU1 Ea+g== X-Forwarded-Encrypted: i=2; AFNElJ/V3KzJ3aIZ4pCnaUplpW9ZyQqvqOIKmVCyOzhDg5GmXv6qxqk9V6VZfLbYHJcYB/0FOMVkGxfHeX39@gnusha.org X-Gm-Message-State: AOJu0YzYqhPhvO7ee3CvhkRNRi2pNOz+UNOoUmRfxZnfonxWa9blJ8JJ KcKQmz7MFBcxUCG4JYPnlKx47DTsnOnLBFaB2weNgNcHJKmFU3b126xe X-Received: by 2002:a05:6820:212:b0:69e:2bb7:daea with SMTP id 006d021491bc7-69e480d395cmr3280581eaf.53.1780529199188; Wed, 03 Jun 2026 16:26:39 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AUV6zMNlaaHSx7Iq+G1IWysnbo8yYrfqXGfSEucZh1aSWAndyQ==" Received: by 2002:a05:6820:61c:b0:69d:a6ef:f02a with SMTP id 006d021491bc7-69e591d73d9ls305201eaf.1.-pod-prod-05-us; Wed, 03 Jun 2026 16:26:34 -0700 (PDT) X-Received: by 2002:a05:6808:4491:b0:485:6129:10ff with SMTP id 5614622812f47-4865ac16166mr3525281b6e.34.1780529193923; Wed, 03 Jun 2026 16:26:33 -0700 (PDT) Received: by 2002:a05:6504:518e:20b0:302:4fe1:d22 with SMTP id a1c4a302cd1d6-302a3d2d43emsc7a; Wed, 3 Jun 2026 16:12:22 -0700 (PDT) X-Received: by 2002:a05:6512:3d8c:b0:5aa:6fff:c3e7 with SMTP id 2adb3069b0e04-5aa7c0a7517mr2001658e87.34.1780528340915; Wed, 03 Jun 2026 16:12:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1780528340; cv=none; d=google.com; s=arc-20240605; b=BEXKY33BraMA4kvgd/oPg02J4B+4P0CTkZqxOcDj2HYdgwLNNrDASVk3neBCoZTWxW qMXTGh8zNdUaquKs9G77Ab/BSELJTDXafdL7K91Ebpb7VqVj6odtn0+Qr1OaSpAYQmBJ eXDAiZ/N7/YWOrsBCiy8yJXAU+0c06eU6UKA/NoMisAff5wVQiDddQRvGS66+ECpTSFl 7nDsWQJ/ABI0BFQDFaS7+OZIUpn9Sb3X5cE78GNBoYAYc904E8VgRcp+bhJFaZXGDms9 wwOsQPvyiO1frd2UDIclckNtGT2mld16M4unAgBgVDwPghL26AkpwYGe9/deJHJU39Xn +SKg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=mime-version:feedback-id:message-id:subject:from:to:date :dkim-signature; bh=NRGITThOXSBFb3tHyCNh8084t1W0ZzbIXfH1Rv74GAY=; fh=lhFSo2W/mHC0QoJ9oNg3A35n0DTltt3CQl1/0RggJlk=; b=inRudu81LgBRv+5e4APJNnksD2ryFq2XGGmyj0EkWF1g35LK81H9gOVDUuU96WDhls CyTAH1DWVr4YEdjtG6VU+YH/Rs4K+dYthei5tTxrTBau7T0DF7umg35ZVOKV1llbUkQm M3z7lGjRunRYl9286oFUUX0W4Rnt03AbYRkoXXgoaKxURye8vFQWdwRkzbetkH7Y0ZKD TwAPPq+TRMIpnvlbqNsdVDqFcnip5fkqyWLyMm/MCj6Ligm0AN8HuP3EB3pC2BHqfPMx 4ljbMfPOS6UbBb+gx1ZEKpNo910FeP+HBuI/grwVypqO/+p8KhAEsah8GaWH2UW6Iilc VXBA==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=624qjmanmzcytaextdsj2bug6i.protonmail header.b=R3S46xiS; spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.99 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me Received: from mail-10699.protonmail.ch (mail-10699.protonmail.ch. [79.135.106.99]) by gmr-mx.google.com with ESMTPS id 2adb3069b0e04-5aa7b8f4bf6si96143e87.1.2026.06.03.16.12.20 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Jun 2026 16:12:20 -0700 (PDT) Received-SPF: pass (google.com: domain of conduition@proton.me designates 79.135.106.99 as permitted sender) client-ip=79.135.106.99; Date: Wed, 03 Jun 2026 23:12:15 +0000 To: "bitcoindev@googlegroups.com" From: "'conduition' via Bitcoin Development Mailing List" Subject: [bitcoindev] Aligning privacy incentives in P2MR Message-ID: Feedback-ID: 72003692:user:proton X-Pm-Message-ID: 6797cdb1e40af3a5329a47b52b0ec266b8b9d216 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------ca12257782717bd1f513f5b9d001eaec50b136ce96670d26c8b644af02c2ba23"; 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=624qjmanmzcytaextdsj2bug6i.protonmail header.b=R3S46xiS; spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.99 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) --------ca12257782717bd1f513f5b9d001eaec50b136ce96670d26c8b644af02c2ba23 Content-Type: multipart/mixed;boundary=---------------------375742e166234baf338823c085eeb67c -----------------------375742e166234baf338823c085eeb67c Content-Type: multipart/alternative;boundary=---------------------d0153f078c563da7d177120237475cf6 -----------------------d0153f078c563da7d177120237475cf6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Hi list. I'm following up on an idea I sketched in=C2=A0this thread debatin= g P2MR vs P2TRv2.=C2=A0 The premise is this: What if we modified this line of BIP360: > The last stack element is called the control block c, and must have lengt= h 1 + 32 * m, for a value of m that is an integer between 0 and 128, inclus= ive. Fail if it does not have such a length. To this: > The last stack element is called the control block c, and must have lengt= h 1 + 32 * m, for a value of m that is an integer between=C2=A01=C2=A0and 1= 28, inclusive. Fail if it does not have such a length. The key change is that the control block must now include at least one merk= le authentication path. This effectively bans depth-zero script trees in P2= MR, and requires every P2MR address to always pay the cost of having at lea= st two spending conditions. This seems like a reduction in P2MR's features and efficiency. Why would we= want to ban depth-zero script trees?=C2=A0Well these seem to be the source= of a perverse incentive, as pointed out by Matt Corallo and Antoine Poinso= t in=C2=A0prior threads. Bitcoin script users are economically and practica= lly incentivized by P2MR to use depth-zero script trees because their witne= sses are smaller than if the same script were used in a taproot script spen= d. Furthermore, depending on the exact scripts and the developers' resources, = devs using P2MR for a multi-party scripting protocol may not be sufficientl= y incentivized to add a cooperative spending path, even if their protocol m= ight allow it. Doing so would require a depth-1 tree, which increases the w= itness size of the non-cooperative script spend path by 32 bytes. For some = short scripts, e.g ` CLTV CHECKSIG`, the devs may actually= have incentive not to add a cooperative spending path, because the coopera= tive path would actually be less-efficient than just using the non-cooperat= ive path as the single leaf of a depth-zero tree.=C2=A0This leads to easy f= ingerprinting of scripting protocols, less privacy for everyone else, and u= ndoes a key design goal of P2TR. In=C2=A0Matt's words: > The value=C2=A0of taproot is that its design natively adds [a cooperative= spending path] *for free* to every contracting protocol, and not only adds= it for free but *forces* every contracting protocol to carry at least some= of the cost if they decline to do this. This results in a massive net priv= acy win across the entire Bitcoin=C2=A0ecosystem... > a goal of taproot is *privacy* while=C2=A0offering efficiency for the com= mon (all-sign) case. That is generally true across contracting protocols an= d makes things net-cheaper with a taproot-style system where you hit the co= mmon case=C2=A0often. This is another reason why P2MR is quite a loss By eliminating depth-zero script trees, we'd force all P2MR users to pay fo= r the cost of having at least two spending conditions. We'd eliminate the i= ncentive for script devs to use P2MR over P2TR because both are equally eff= icient, and incentivize P2MR users to add a cooperative spending path using= BIP340, since those users are already paying for the cost of having a dept= h-1 tree anyway. This change to BIP360 wouldn't affect the recommended standard use-cases fo= r single-signer and multisig P2MR: hybrid addresses with one Schnorr leaf a= nd one PQ leaf. If anything, this change would encourage the proper use of = PQ fallback scripts, because the incentive logic can be applied to someone = who tries to use P2MR with only a single EC Schnorr leaf: This user must pa= y for the cost of a second leaf script anyway, so why not follow best-pract= ices and add a PQ leaf? AFAICT this change only affects use cases which would otherwise degrade the= fungibility of the UTXO set according to BIP360 critics, and encourages th= ose use-cases to adopt a cooperative spending path which (assuming all othe= r factors equal) will be indistinguishable from a regular single-signer P2M= R wallet with a PQ fallback leaf. I've already chatted about this off-list with some BIP360 proponents and th= ey seem receptive, but I'm really curious about the opinions of those who a= re leaning towards P2TRv2. Would this change to BIP360 address your concern= s surrounding P2MR's privacy incentives? If not, why? regards, conduition --=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/= Q8YTY1ArMzia7tRvcZ5v769WPxCMxAl_0rUy-byOBjBcTd4HXj7IB7Yt4gxLbKqk7EXFWy-PuGB= 6QtI28qRjE5Vob-l44UmBH6L8aXInoSk%3D%40proton.me. -----------------------d0153f078c563da7d177120237475cf6 Content-Type: multipart/related;boundary=---------------------16d942891347b8ba0c2471873c732ada -----------------------16d942891347b8ba0c2471873c732ada Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi list. I'= m following up on an idea I sketched in this thread debating P2MR vs P2TRv2. 

The premise is this: What if we modified this line of BIP360:
<= br>
The last stack element is called the control block c, a= nd must have length 1 + 32 * m, for a value of m that is an integer between= 0 and 128, inclusive. Fail if it does not have such a length.

To this:

The last = stack element is called the control block c, and must have length 1 + 32 * = m, for a value of m that is an integer between 1 and 128, inclusive. Fail if it does not have such a length= .

The key change is that the control = block must now include at least one merkle authentication path. This effect= ively bans depth-zero script trees in P2MR, and requires every P2MR address= to always pay the cost of having at least two spending conditions.

This seems like a reduction in P2MR's features and = efficiency. Why would we want to ban depth-zero script trees? W= ell these seem to be the source of a perverse incentive, as pointed out by = Matt Corallo and Antoine Poinsot in prior threads. B= itcoin script users are economically and practically incentivized by P2MR t= o use depth-zero script trees because their witnesses are smaller th= an if the same script were used in a taproot script spend.
=

Furthermore, depending on the exact scripts = and the developers' resources, devs using P2MR for a multi-party scripting = protocol may not be sufficiently incentivized to add a cooperative spending= path, even if their protocol might allow it. Doing so would require a dept= h-1 tree, which increases the witness size of the non-cooperative script sp= end path by 32 bytes. For some short scripts, e.g <height> CLTV= <pubkey> CHECKSIG=E2=80=8B, the devs may actually have incent= ive not to add a cooperative spending path, because the cooperative = path would actually be less-efficient than just using the non-cooper= ative path as the single leaf of a depth-zero tree. This leads = to easy fingerprinting of scripting protocols, less privacy for everyone el= se, and undoes a key design goal of P2TR.

I= n Matt's words:=

The value of taproot is that its design natively adds [a cooperative spending pat= h] *for free* to every contracting protocol, and not only adds it for free = but *forces* every contracting protocol to carry at least some of the cost = if they decline to do this. This results in a massive net privacy win acros= s the entire Bitcoin ecosystem...

a goal of taproot is *privacy* while offering efficiency for= the common (all-sign) case. That is generally true across contracting prot= ocols and makes things net-cheaper with a taproot-style system where you hi= t the common case often. This is another reason why P2MR is quit= e a loss

By eliminat= ing depth-zero script trees, we'd force all P2MR users to pay for the cost = of having at least two spending conditions. We'd eliminate the incen= tive for script devs to use P2MR over P2TR because both are equally efficie= nt, and incentivize P2MR users to add a cooperative spending path using BIP= 340, since those users are already paying for the cost of having a depth-1 = tree anyway.

This change to BIP360 wo= uldn't affect the recommended standard use-cases for single-signer and mult= isig P2MR: hybrid addresses with one Schnorr leaf and one PQ leaf. If anyth= ing, this change would encourage the proper use of PQ fallback scripts, bec= ause the incentive logic can be applied to someone who tries to use P2MR wi= th only a single EC Schnorr leaf: This user must pay for the cost of a seco= nd leaf script anyway, so why not follow best-practices and add a PQ leaf?<= /span>

AFAICT this change only affects use cases = which would otherwise degrade the fungibility of the UTXO set according to = BIP360 critics, and encourages those use-cases to adopt a cooperative spend= ing path which (assuming all other factors equal) will be indistinguishable= from a regular single-signer P2MR wallet with a PQ fallback leaf.

I've already chatted about this off-list with s= ome BIP360 proponents and they seem receptive, but I'm really curious about= the opinions of those who are leaning towards P2TRv2. Would this change to= BIP360 address your concerns surrounding P2MR's privacy incentives? If not= , why?

regards,
conduition


--
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/Q8YTY1= ArMzia7tRvcZ5v769WPxCMxAl_0rUy-byOBjBcTd4HXj7IB7Yt4gxLbKqk7EXFWy-PuGB6QtI28= qRjE5Vob-l44UmBH6L8aXInoSk%3D%40proton.me.
-----------------------16d942891347b8ba0c2471873c732ada-- -----------------------d0153f078c563da7d177120237475cf6-- -----------------------375742e166234baf338823c085eeb67c 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== -----------------------375742e166234baf338823c085eeb67c-- --------ca12257782717bd1f513f5b9d001eaec50b136ce96670d26c8b644af02c2ba23 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wrsEARYKAG0FgmogtL8JEHgpbO2E9rPFRRQAAAAAABwAIHNhbHRAbm90YXRp b25zLm9wZW5wZ3Bqcy5vcmdDQ+B6IrExDt/mHqBCIWsF+08BQnHvhGLpf1JT VATMbBYhBEdIka0CMtrLdg13a3gpbO2E9rPFAAC7wQD/c0wM9V9K07GBrau5 ASx+ih2/1QFF0nGRbrjz26GC+I4BAM0t9fH8hQogkQqZmWBl1KF7jlxHkt5Z M8lPZ2tepIIJ =9Cnf -----END PGP SIGNATURE----- --------ca12257782717bd1f513f5b9d001eaec50b136ce96670d26c8b644af02c2ba23--