path: root/63/690239b671320a8e6e5eb8e6e092227ea6eee9

Delivery-date: Tue, 03 Jun 2025 09:55:09 -0700
Received: from mail-yw1-f189.google.com ([209.85.128.189])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBCL7RHHJZYJBBY6R7TAQMGQET6GSBDI@googlegroups.com>)
	id 1uMUuq-0000gy-N7
	for bitcoindev@gnusha.org; Tue, 03 Jun 2025 09:55:09 -0700
Received: by mail-yw1-f189.google.com with SMTP id 00721157ae682-70f8d28830asf65699777b3.1
        for <bitcoindev@gnusha.org>; Tue, 03 Jun 2025 09:55:08 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1748969703; cv=pass;
        d=google.com; s=arc-20240605;
        b=Y8GsY79GMvpMPogTqC/+7lLo1B9AMuaCi/atqP/EPN2QirPpnqjudYh2IHHWR4D+zF
         tjnZQCeTLnkR2rhywW/fliip0LL/04IVxhg+5lf6ROi2WYvYhHGfm2qwLssjKIoR/F6l
         eCMqNhjvvi0ZccUd2IP/3C6sRX3/xBYLnJpfaCrLoiiMfHd+yxoEkADyoA0g66WvYbsD
         5ntQLsrwT/5f9QTXTYRqgqYB6mIKA0KMCY7Fbe3J3SjMFHOCaP+C9xPg2DftorlnaD8M
         nq84LP8lpE/OWdl3Zk/DBPbxfinHfxz4uHAGhtMXAjiTHAOwwVMhEE1WvB4wEumK9N3y
         K5Ng==
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=CNMNqufKVcJQlP0+MrX4p+P6Kl/XU2Qjf2XASskAboY=;
        fh=/yMSX+YS/O4EK9kTpRLutQ9z+sr5LoFdTpvjjzTJ9L8=;
        b=fCpLb8nvRiQDGS4rGgtgpxZzuGOTnaoNPJ1J2/JvD16h8fKRf/OK2uAinH/6daOVQC
         XhnUtTheJ9kiTFfp+mF9Sf3e/fIuu8W8DQeMyFcKvjyNwmXW/FGFBn//0TsgVlqZokHE
         1F9JHs0Vl2nr1/k4ENuBtIKiG0HvXBkTwC66L7PLgEzFS4fhSuA1Mrmnt6hwOBJ+be7P
         4jWjk6bowCNtThR+HCX3EaQjX8RQDIFCIZUwGLxtKmoQFz4u8DT23DDMFNc/E9lI9Bcr
         2KDxjnmvTY/UjH9qC+D+tNkCQFqe1ADycyZWF6kL1bVCZL0HvghkVQE/AQ72PEynWmTa
         7/+g==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@proton.me header.s=protonmail header.b=UprnR08Q;
       spf=pass (google.com: domain of conduition@proton.me designates 109.224.244.16 as permitted sender) smtp.mailfrom=conduition@proton.me;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1748969703; x=1749574503; 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=CNMNqufKVcJQlP0+MrX4p+P6Kl/XU2Qjf2XASskAboY=;
        b=cFWne6JUOFrHtly7bxrE8S1Am5pW4L9h4nOFzQ3szD7r8wENf5cgRJrpvasSak2ILm
         fHKOooGsRdVttC7HrQ86Mls23moJo24YMwBFxDP6Wf29CN0Fx4bGkK/46R+/JKAPIrIz
         wkEx1kcJQ8E+xMglu81slGDHsxkI7/f8rcY13oWK8mVctMQ3BhTx5EKuQN1y8hPFjkWa
         c4BJVesrgyLqIcMwy9FRFro/yRjFPqaQTopQ7d/1iP6CaUYSEjac2GtYIAmZ9tAFB5Yf
         VGbz6JgYCxO+BzH9+KUEnXeMiTI5rh8ZKzgswbSdNJQzVWE8CEjr13QueoggQCFPHnYC
         K9BQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748969703; x=1749574503;
        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=CNMNqufKVcJQlP0+MrX4p+P6Kl/XU2Qjf2XASskAboY=;
        b=Na9sHuhBKVTroERkLcxwsQHDQ3oOrA8V4bhpaXnLnEL7FD8coWfC1IVJ1gg1v4uXCM
         oqwnLbleGGuJPR/fg0UbH7kSIsm8uMxzj8eDtLseJIN8VcSSAAsJRH6DJ40GpVps8wdY
         SvzuCYjdH56C6UMlfntrjx71ZgyvPhcMa+61zRQhED9VUuoo1gAzB5lIBOO6PX1/7sjl
         65zihwBF12HnzluwaICcD3RdanctMgs5A2Shlok7zq6A4QY8cuh+Gr39rGGjEBONF6yg
         gDxbul5aiR1e3b1rBRy0Alvh+vCfuD3opqB309rUkELMjIDXniZKwe46D5JWPSCiUm5X
         skJw==
X-Forwarded-Encrypted: i=2; AJvYcCUdakYAKK6q4cyJfFKR7JWRhXOfn/ws7lFN6Gv9JoLDe8WQeMG9JvGT2HMByBwk3wwvCGsd3wWbchvE@gnusha.org
X-Gm-Message-State: AOJu0YwQg1GFiXtjEtG4OzUPMo6qUtw/WQ8MwkuzhldbC5pIGs6n0B0z
	vmyAtMPeUTpJEBNtoY1kqDc2ImoepwpPqkJqJVOapFe4dFujKxf1yyeb
X-Google-Smtp-Source: AGHT+IEhrnQfnITQvh2MPVcxc+Sy6Zub5SBH+zNgSmpzmJW5Co0+KyzOfTkijX5BcZY3wnBEVlqD8g==
X-Received: by 2002:a05:6902:1203:b0:e81:2d89:4d with SMTP id 3f1490d57ef6-e812d8901d3mr15749067276.3.1748969702748;
        Tue, 03 Jun 2025 09:55:02 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZdL15LBC4lzTuV+iN7LUw+fzSRiFxcrHyCT0pm96gnSPw==
Received: by 2002:a25:ab13:0:b0:e7d:c43d:b109 with SMTP id 3f1490d57ef6-e7f6f7f25efls6287795276.1.-pod-prod-05-us;
 Tue, 03 Jun 2025 09:54:58 -0700 (PDT)
X-Forwarded-Encrypted: i=2; AJvYcCUAeZcOSG3ZLJT1c/FkXvCZvhsEXDtEiCliELmp8Grglw6w8be6Rr1gvOch/rXCVy9Gpo0URI0ar9XQ@googlegroups.com
X-Received: by 2002:a05:690c:4d08:b0:70e:2cf0:f66a with SMTP id 00721157ae682-710501db0c4mr245030417b3.6.1748969698695;
        Tue, 03 Jun 2025 09:54:58 -0700 (PDT)
Received: by 2002:a05:690c:6083:b0:70e:2cf8:9db8 with SMTP id 00721157ae682-70f980e43fams7b3;
        Tue, 3 Jun 2025 08:15:15 -0700 (PDT)
X-Forwarded-Encrypted: i=2; AJvYcCVFzF3SaY98kRtrpKg457AEfJvyV62KWvz+rX+Dk6zQAy0oKfkklciH3k5ojZFkJbBXdZS6EvAVb7g0@googlegroups.com
X-Received: by 2002:a05:6902:729:b0:e7d:77b6:22b0 with SMTP id 3f1490d57ef6-e7ff6321ec9mr21562463276.42.1748963713036;
        Tue, 03 Jun 2025 08:15:13 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1748963713; cv=none;
        d=google.com; s=arc-20240605;
        b=AT4cbjX4JHYxLN4WSszilzW8xyf0ZnwJyt3yKywU6SFu74lcHTZrSN0RzNjrTIWukf
         pnIYF4HjtoQXnpk1B+o+NAd6f9BibgBI/lSjitcGTKtZa8YiiJqoEUwwwh2+bmtfLiRe
         Cu/9qYUlHfWKIUVWAyXaiizf4h70KiZbGxPM5ezFId3AE9f93vuuEoFlqNT9AGFK96UL
         15xZa5kjVlrgB07/HSILzvNvDK7A5+7pOzH8Ut++ODJCVr5ioyP43Y38GXCieXvhBhEv
         zipJb13uCTIpzgRfnHoLGmZqbSmhfUNig3T9oMt8ppE0oLM67yM79RGtnkFsT+q9nwUN
         5qMg==
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=8h7UXTf/DsGvHg92JJIBybK45BZOoCbxe4BPtrXQMPI=;
        fh=WW6ee8eavknKoK1aDxZysyDWVs3ld7TP1poSNaqwL1U=;
        b=XnEqPhKu0K0qGDCSgFrmFDBXuVfFScaFWAzC0IcMNQ7PL2SY0SSDa/d0Xt9kPU8w89
         V8eKjvTM/+igJcQiRUIRZIwxG13gY2C7EnO+BmfDlL9gnE8IQAYmjLLGcqUXk0HokQVm
         G+inKRz6X9LO9rGvfQEPvG5NNumyGoprHi63MMq8htX/M4LJ2SiD0J1O6XMjjQY4ycwT
         UYLkF1DZPz4Nn8CKfJYfbBMiTjdHXNn498abuSoSMO6psmBZOumVjku+b5Y0o+UHFiIn
         0oolw5rZh+sKBTAi3WfB5IgqFU1qseuLLQI/5tazZujgiQoZWRLM4aCnFy4VaMKLtOW0
         /pvQ==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@proton.me header.s=protonmail header.b=UprnR08Q;
       spf=pass (google.com: domain of conduition@proton.me designates 109.224.244.16 as permitted sender) smtp.mailfrom=conduition@proton.me;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me
Received: from mail-24416.protonmail.ch (mail-24416.protonmail.ch. [109.224.244.16])
        by gmr-mx.google.com with ESMTPS id 3f1490d57ef6-e7f734a296bsi576621276.3.2025.06.03.08.15.12
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Tue, 03 Jun 2025 08:15:13 -0700 (PDT)
Received-SPF: pass (google.com: domain of conduition@proton.me designates 109.224.244.16 as permitted sender) client-ip=109.224.244.16;
Date: Tue, 03 Jun 2025 15:15:08 +0000
To: Leo Wandersleb <lwandersleb@gmail.com>
From: "'conduition' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
Cc: Nagaev Boris <bnagaev@gmail.com>, Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Pre-emptive commit/reveal for quantum-safe migration (poison-pill)
Message-ID: <ZmYpRwmVDoJBUhiCRb909Lgwws_dT9d_CNUjfddVt128pyjdH0UcYfXgA_uguwRu44ZC8_x_SwlrooqKhyvdwJjnO1h3BvzQxVRbdCpVfjg=@proton.me>
In-Reply-To: <33f67e84-5d1c-4c14-80b9-90a3fec3cb36@gmail.com>
References: <2c3b7e1c-95dd-4773-a88f-f2cdb37acf4a@gmail.com> <CAFC_Vt7z5Vj=r90J8RoH3sC5592BO4G9U3L9gdcX+D3DruC1PQ@mail.gmail.com> <33f67e84-5d1c-4c14-80b9-90a3fec3cb36@gmail.com>
Feedback-ID: 72003692:user:proton
X-Pm-Message-ID: 3a2c078a346fe751a391a35625857aa97c7dad38
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------3a4d372cd601a3dde878d1f591841e0a47971eefd428cf603ff05d89e7d9b597"; 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=UprnR08Q;       spf=pass
 (google.com: domain of conduition@proton.me designates 109.224.244.16 as
 permitted sender) smtp.mailfrom=conduition@proton.me;       dmarc=pass
 (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me
X-Original-From: conduition <conduition@proton.me>
Reply-To: conduition <conduition@proton.me>
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -1.0 (-)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------3a4d372cd601a3dde878d1f591841e0a47971eefd428cf603ff05d89e7d9b597
Content-Type: multipart/mixed;boundary=---------------------f3975a3126719f4b19acb2c213811b48

-----------------------f3975a3126719f4b19acb2c213811b48
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

Hey Leo, thanks for your ideas. I do see a couple issues though.

A prospective Quantum attacker could trivially break your scheme
as follows:

- Enumerate the entire UTXO set.
- Create a transaction to steal each available P2WPKH/P2TR UTXO one by one.
- Commit to all of those transactions' IDs in one big merkle root OP_RETURN=
.
- Repeat occasionally as the UTXO set changes.

This would give the QC attacker a valid pre-emptive commitment,
same as any honest user. It is possible because anyone can create
a valid unsigned transaction to spend a segwit UTXO without
knowing the pubkey. Segwit inputs don't include the witness
data (pubkeys, signatures) in the TXID.

I think instead you should commit to the witness TXIDs (wTXID) of
the recovery transactions, which include witness data like pubkeys
and signatures in the preimage, which the QC attacker shouldn't be
able to predict.

A second problem. An aggregated, pre-emptive commitment of the
fashion you describe would need to be updated constantly, as a
new merkle root would be needed every time you add a new UTXO
to your wallet. Rather than publishing this merkle root in your
own OP_RETURN, it'd be better for scaling if it were published
in something like OpenTimestamps, so that a majority of users
can aggregate their commitments together and save blockspace.

Finally a question: Why do we need to "require at least n
confirmations on quantum vulnerable transactions"? By the
way, I'm assuming here you mean that quantum vulnerable
UTXOs can only be spent after n blocks, like OP_CSV style.
Can you help me see why that helps here?

In my mind, the only thing we need a time-delay on is the
commitment opening. The commitment merkle root must be old
enough when opened to ensure the QC attacker couldn't have
forged one after learning a victim's pubkey.

regards,
conduition




On Tuesday, June 3rd, 2025 at 6:00 AM, Leo Wandersleb <lwandersleb@gmail.co=
m> wrote:

> Hi Boris,
>=20

> Actually, I think the poison pill approach could be implemented as a soft=
 fork
> after all, with a cleaner mechanism:
>=20

> After activation at block height X:
>=20

> 1. Vulnerable UTXOs cannot be spent directly - they require a prior annou=
ncement
> 2. Weak announcement with no private key needed: "I intend to spend UTXO =
A
> with transaction X after block B+144"
> 3. Strong announcement with a commitment proof: References a potentially
> old, pre-fork commitment and provides proof that this UTXO was included
> 4. After 144 blocks: The UTXO can be spent according to the strongest
> announcement (oldest commitment wins)
>=20

> This is a soft fork because:
> - We're not "undoing" transactions
> - We're adding new rules about when certain UTXOs can be spent
> - Old nodes still see valid transactions, just with different timing
>=20

> The key insight is that the "weak announcement" doesn't require private k=
eys -
> it just declares intent. This preserves the validity of pre-signed transa=
ctions
> (they can still be announced and executed, just with a delay).
>=20

> Meanwhile, anyone who created commitments before the fork can use "strong
> announcements" to override potential quantum attackers during the window.
>=20

> This gives us poison pill protection while maintaining backward compatibi=
lity.
> No transaction reversal needed - just a new spending process for vulnerab=
le UTXOs.
>=20

> Does this address your hard fork concern?
>=20

> ---
>=20

> This formulation avoids implementation details while focusing on the conc=
eptual
> mechanism that makes it a soft fork rather than a hard fork.
>=20

> On 6/3/25 01:11, Nagaev Boris wrote:
>=20

> > Hi Leo,
> >=20

> > Thanks for sharing your proposal, a very interesting approach! I have
> > a few questions and comments:
> >=20

> > > Users create and sign transactions moving their funds to quantum-safe=
 addresses
> > > 1. No consensus changes needed now - Users can start protecting thems=
elves
> > > immediately
> > > How would users prepare transactions moving funds to quantum-safe
> > > addresses now, before such address types exist? We would need to know
> > > the structure of a quantum-safe address to create the transaction.
> > > Either an existing address type would need to support some form of
> > > quantum protection already (e.g., WOTS implemented via BitVM), or we
> > > would still need a softfork to introduce a new address type.
> >=20

> > Additionally, a future softfork (or possibly a hardfork, see below)
> > would still be required to enforce the new spending rules.
> >=20

> > > - If attacked, the victim can reveal the commitment to execute the re=
covery
> > > transaction
> > > Wouldn't such a recovery transaction require a hardfork? As far as I
> > > understand, it wouldn't be valid under current consensus rules.
> > > Enabling it would require relaxing existing rules, which would imply =
a
> > > hardfork.
> >=20

> > Best,
> > Boris
> >=20

> > On Mon, Jun 2, 2025 at 6:12=E2=80=AFPM Leo Wandersleb lwandersleb@gmail=
.com wrote:
> >=20

> > > Hi all,
> > >=20

> > > I'd like to propose a variant of the commit/reveal schemes being disc=
ussed for
> > > quantum resistance, but with a different goal and timeline. This buil=
ds on ideas
> > > from the recent thread "Post-Quantum commit / reveal Fawkescoin varia=
nt as a
> > > soft fork" but targets a different use case.
> > >=20

> > > ## The Problem
> > >=20

> > > Current discussions focus on emergency reactive measures - what to do=
 after
> > > quantum computers arrive. But this leaves users in a difficult positi=
on:
> > >=20

> > > 1. They can't prove ownership of their coins without revealing pubkey=
s (and thus
> > > becoming vulnerable)
> > > 2. Moving coins to quantum-safe addresses early reveals which address=
es are
> > > active vs. abandoned
> > > 3. There's no way to prepare for migration without exposing yourself
> > >=20

> > > ## Pre-emptive Commit/Reveal
> > >=20

> > > What if users could commit today to future migration transactions, wi=
thout
> > > revealing which UTXOs they control?
> > >=20

> > > The idea is simple:
> > > - Users create and sign transactions moving their funds to quantum-sa=
fe addresses
> > > - They compute a Merkle tree of all these transactions
> > > - They publish only the root hash (e.g., in an OP_RETURN)
> > > - This can be done today, with no consensus changes
> > >=20

> > > If/when quantum computers become a threat:
> > > - We soft fork to require at least n confirmations on quantum vulnera=
ble
> > > transactions
> > > - Transactions work as always but can't be spent for n blocks
> > > - If attacked, the victim can reveal the commitment to execute the re=
covery
> > > transaction
> > >=20

> > > ## Key Advantages
> > >=20

> > > 1. No consensus changes needed now - Users can start protecting thems=
elves
> > > immediately
> > > 2. Privacy preserved - The commitment reveals nothing about which UTX=
Os you own
> > > 3. Efficient - One hash can commit to migrations for all your UTXOs o=
r even
> > > the UTXOs of several users
> > > 4. Flexible - Works whether or not a quantum computer ever actually a=
ppears
> > >=20

> > > ## Differences from Tadge's Proposal
> > >=20

> > > While Tadge's proposal solves post-quantum spending where any pubkey =
reveal is
> > > dangerous, this proposal is about preparation:
> > >=20

> > > - Timing: Pre-quantum (can start now) vs. post-quantum (activates aft=
er QC
> > > appears)
> > > - Scope: Migration to quantum-safe addresses for all address types in=
 the
> > > worst case vs. general spending of hashed pubkeys
> > >=20

> > > Both use the same cryptographic primitive (commit/reveal) but for dif=
ferent
> > > phases of the quantum transition.
> > >=20

> > > This approach lets users protect their funds without waiting for cons=
ensus
> > > changes or revealing their holdings. It's a "poison pill" against qua=
ntum
> > > attackers - they might steal coins, but pre-committed owners can recl=
aim them.
> > >=20

> > > Would love to hear thoughts on this approach.
> > >=20

> > > Leo Wandersleb
> > >=20

> > > --
> > > You received this message because you are subscribed to the Google Gr=
oups "Bitcoin Development Mailing List" group.
> > > To unsubscribe from this group and stop receiving emails from it, sen=
d an email to bitcoindev+unsubscribe@googlegroups.com.
> > > To view this discussion visit https://groups.google.com/d/msgid/bitco=
indev/2c3b7e1c-95dd-4773-a88f-f2cdb37acf4a%40gmail.com.
>=20

>=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/33f67e84-5d1c-4c14-80b9-90a3fec3cb36%40gmail.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/=
ZmYpRwmVDoJBUhiCRb909Lgwws_dT9d_CNUjfddVt128pyjdH0UcYfXgA_uguwRu44ZC8_x_Swl=
rooqKhyvdwJjnO1h3BvzQxVRbdCpVfjg%3D%40proton.me.

-----------------------f3975a3126719f4b19acb2c213811b48
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==
-----------------------f3975a3126719f4b19acb2c213811b48--

--------3a4d372cd601a3dde878d1f591841e0a47971eefd428cf603ff05d89e7d9b597
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: ProtonMail

wrsEARYKAG0Fgmg/EWwJkHgpbO2E9rPFRRQAAAAAABwAIHNhbHRAbm90YXRp
b25zLm9wZW5wZ3Bqcy5vcmfgi+OcodjX0qyGhy8/WAOeWyNb3TINmGyPTbG9
FcBPvBYhBEdIka0CMtrLdg13a3gpbO2E9rPFAABXkAD+JGMM5hNiKn+/D1zn
3XriYST9DRbvPqUqvy93WEccEdkBAN5swj1OBJVhlNNMKq6WvkZCgpbf7/OO
NzVrQoEqjvoF
=bHsh
-----END PGP SIGNATURE-----


--------3a4d372cd601a3dde878d1f591841e0a47971eefd428cf603ff05d89e7d9b597--