path: root/d3/38ac57303774eea8e045ad54b0bae2632de34b

Return-Path: <michaelfolkson@gmail.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 246BBC013A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  5 Feb 2021 12:44:11 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by whitealder.osuosl.org (Postfix) with ESMTP id 068D886A7A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  5 Feb 2021 12:44:11 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 1BdIMcCivTd5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  5 Feb 2021 12:44:09 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-ot1-f50.google.com (mail-ot1-f50.google.com
 [209.85.210.50])
 by whitealder.osuosl.org (Postfix) with ESMTPS id 834BB871D0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  5 Feb 2021 12:44:09 +0000 (UTC)
Received: by mail-ot1-f50.google.com with SMTP id 100so48635otg.3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 05 Feb 2021 04:44:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:from:date:message-id:subject:to;
 bh=fsQ5kU3Z87wVztw2EZyIWLdgVWsR+Jwf9UALp3VeW4Y=;
 b=EGRBO7kuLD4En2O82yS3OE/K8qXASZOj98idUidIwjjwItEL94b5g4T2Tt5/TSakjh
 JqCThbfpvy1vV5IKJUyDpKR+Otly6F4yb4N1y0B4kvYR4mGThAIo8mAzExSXNj7EOYiq
 Oa1GH6/hxOPdf4SXJHAkzhp+vanW4dAPfw9H6ZFbaDlXcPCPSijSbsrlUlkChXYBL3WY
 6HRQFK3FSRxSYk1DPgr4O77mSEnXVsqdtdkPOtK+F+rgcIF9exTjnjZjDAjkfzveunUs
 WhZdQeyx9XB/+/11WfZ2P6dg7YWsTZUC0fG62sh3l3t4fMNeeHq8Pjq+6jHZIM4kY8Q6
 KniQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
 bh=fsQ5kU3Z87wVztw2EZyIWLdgVWsR+Jwf9UALp3VeW4Y=;
 b=DsU+df/d5zhNDxhNeGZGHLd3SHlKoE8tEEMIo75mgCHW5R4smEjiI6pqo0BvxBPG1N
 1Krx9syoV1Mkzc7mCiklN5f6h2WsfFU8eNY6x966JV0xO2jZJl4HN0sOsD/QR4iBJZWH
 kBI1I3poIpezm9KnMZGU3tKmnGoUIiMaNpWLvztrGwjmR4wxLn9J1jbcXfyVCR539v9E
 aynxmnbJruG65Uh4jvySNPL6o66rs2BxoEI2h3Nkpz5tG1MrA2KpHMbhY6n43i+0vpEG
 jE2ViGC92E4D9zhwpiA6ZNFPezoP9G8yW7suAEzKV4KTaq5cSwDovhP4oMNfkJcKWUv/
 FS6w==
X-Gm-Message-State: AOAM532yDpK1fkroeCliG21UoaHw/cuql231J6TrXg5Ya55UQXK1Ycp4
 PJpxErFAOSk1okcecsKwL+HLOgbqy2614EIMK6sE6uIkVvc=
X-Google-Smtp-Source: ABdhPJzqdBZf04p1+hdRP84Dn6hO7lXCt0EgToT+064cuVrxkMiG4g3daEeroz+KJ04Pz4gMfx9OUCj3t21oacthS7A=
X-Received: by 2002:a9d:1d64:: with SMTP id m91mr3201275otm.290.1612529048444; 
 Fri, 05 Feb 2021 04:44:08 -0800 (PST)
MIME-Version: 1.0
From: Michael Folkson <michaelfolkson@gmail.com>
Date: Fri, 5 Feb 2021 12:43:57 +0000
Message-ID: <CAFvNmHSnd4OM+c0_L8fFXRNrxo23WdQpNdBjTJjhmGuHumgLDA@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary="0000000000001f633105ba962d1f"
X-Mailman-Approved-At: Fri, 05 Feb 2021 13:40:43 +0000
Subject: [bitcoin-dev] Taproot activation meeting 2 - Tuesday 16th February
	19:00 UTC
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Feb 2021 12:44:11 -0000

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

A summary of the first Taproot activation meeting (February 3rd) is here:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/01837=
9.html


It appears there is one (hopefully) last stumbling block before we are
ready to propose Taproot activation parameters to the mailing list.


Hence we are organizing a follow up meeting on IRC on the
##taproot-activation channel on Tuesday 16th February at 19:00 UTC.


As I said in the summary of the first Taproot activation meeting whether
lockinontimeout (LOT) is set to true or false in a Bitcoin Core release
attracted discussion during the meeting and has continued to attract
discussion afterwards.


I will weigh up the arguments I have seen for both true and false here. I
won=E2=80=99t comment on the strength of the arguments, merely attempt to s=
ummarize
them. Any errors are my own.


Arguments for setting lockinontimeout (LOT) to true in a Core release

T1) This entirely eradicates the possibility (however unlikely) that
Taproot fails to activate within a year. Although approximately 90 percent
of mining pools have already pledged to activate Taproot there is no reason
to open the door to possible delays and political shenanigans for no
reason, however unlikely.

T2) Given users can change LOT=3Dtrue at any point (and some have declared
they will be setting LOT=3Dtrue regardless), setting LOT=3Dfalse in Core op=
ens
up edge case scenarios where different proportions of users on the network
change to LOT=3Dtrue at different points in time in an uncoordinated fashio=
n.
Given the end state we all want is Taproot activated it doesn=E2=80=99t mak=
e sense
to open the door to these edge cases. Setting LOT=3Dtrue in Core would mean
there is no motivation for users to change LOT in the software they are
running.

T3) We should not be putting users in a place where they feel they need to
change LOT. The urge to change LOT will be strong if miners delay for an
unreasonable period. We are then in a situation where a decision has to be
made on whether Core releases a new version with LOT=3Dtrue and this whole
discussion kicks off again. We should definitely seek to avoid the need to
rehash this discussion later in the year.

T4) LOT is only relevant if miners fail to activate. It doesn=E2=80=99t mak=
e sense
to set it to false as that is essentially saying if miners fail to activate
early, LOT should also let them not activate.

T5) Activation should only be attempted once community consensus for the
soft fork has been reached. Miner signaling is not voting for the changes,
it is signaling readiness. There is no reasonable rationale for not being
ready within a year.

T6) An argument belcher outlined on IRC. If LOT was set to true and a chain
split happened then the Taproot chain doesn=E2=80=99t have wipeout risk so =
there=E2=80=99s
a really strong incentive to be on the Taproot activating LOT=3Dtrue chain
and therefore using LOT=3Dtrue means the risk of a chain split is actually
lower.



Arguments for setting lockinontimeout (LOT) to false in a Core release

F1) The probability of Taproot not being activated by miners is small. This
is not 2017, this is not SegWit, there is no need to worry.

F2) The worst case scenario is we have to wait over a year for Taproot to
be activated. Even the worst case scenario is not a disaster.

F3) If in the unlikely scenario miners did not activate Taproot for a year
for no apparent reason we would never set LOT to false again for any
potential future soft fork. If miners fail to activate Taproot despite
pledging support and there being overwhelming community consensus for it,
it would set a precedent that miners cannot be relied upon *at all* to
activate soft forks.

F4) If in the highly unlikely scenario that a bug or some problem with the
Taproot implementation was found during the signaling period miners could
choose not to activate it which is cleaner than needing an emergency Core
release.


Then some additional arguments nullc posted on Reddit

https://old.reddit.com/r/Bitcoin/comments/lcjhl6/taproot_activation_pools_w=
ill_be_able_to_veto/gm2l02w/

F5) LOT =3D false is more similar to what was done previously (unless you g=
o
way back to the earliest soft forks which were more similar to LOT =3D true=
)

F6) It is more important that no rules that harm users are deployed than it
is that new useful rules are deployed quickly. If there is a choice between
=E2=80=9Cfaster=E2=80=9D and =E2=80=9Cmore clear that this isn=E2=80=99t a =
mechanism to force bad things on
users=E2=80=9D we should prefer the latter. Plenty of people just don=E2=80=
=99t like
LOT=3Dtrue very much absent evidence that miners are blocking deployment. T=
o
some it just feels needlessly antagonistic and distrusting towards part of
our community.


There are some additional parameters other than LOT we will discuss in this
meeting such as activation threshold, start time etc but personally I don=
=E2=80=99t
think they will attract the same discussion as LOT.


As I=E2=80=99ve stated before please continue to engage productively and in=
 good
faith. I can see arguments with merit on both sides of the LOT discussion
but there appears to be overwhelming consensus that Taproot is activated
this year and there appears to be no reason it shouldn=E2=80=99t be. This
discussion on LOT really should not derail that.

--=20
Michael Folkson
Email: michaelfolkson@gmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3

--0000000000001f633105ba962d1f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">





<p class=3D"gmail-p1" style=3D"margin:0px;font-variant-numeric:normal;font-=
variant-east-asian:normal;font-stretch:normal;font-size:12px;line-height:no=
rmal;font-family:Helvetica">A summary of the first Taproot activation meeti=
ng (February 3rd) is here: <a href=3D"https://lists.linuxfoundation.org/pip=
ermail/bitcoin-dev/2021-February/018379.html">https://lists.linuxfoundation=
.org/pipermail/bitcoin-dev/2021-February/018379.html</a></p>
<p class=3D"gmail-p2" style=3D"margin:0px;font-variant-numeric:normal;font-=
variant-east-asian:normal;font-stretch:normal;font-size:12px;line-height:no=
rmal;font-family:Helvetica;min-height:14px"><br></p>
<p class=3D"gmail-p1" style=3D"margin:0px;font-variant-numeric:normal;font-=
variant-east-asian:normal;font-stretch:normal;font-size:12px;line-height:no=
rmal;font-family:Helvetica">It appears there is one (hopefully) last stumbl=
ing block before we are ready to propose Taproot activation parameters to t=
he mailing list.</p>
<p class=3D"gmail-p2" style=3D"margin:0px;font-variant-numeric:normal;font-=
variant-east-asian:normal;font-stretch:normal;font-size:12px;line-height:no=
rmal;font-family:Helvetica;min-height:14px"><br></p>
<p class=3D"gmail-p1" style=3D"margin:0px;font-variant-numeric:normal;font-=
variant-east-asian:normal;font-stretch:normal;font-size:12px;line-height:no=
rmal;font-family:Helvetica">Hence we are organizing a follow up meeting on =
IRC on the ##taproot-activation channel on Tuesday 16th February at 19:00 U=
TC.</p>
<p class=3D"gmail-p2" style=3D"margin:0px;font-variant-numeric:normal;font-=
variant-east-asian:normal;font-stretch:normal;font-size:12px;line-height:no=
rmal;font-family:Helvetica;min-height:14px"><br></p>
<p class=3D"gmail-p1" style=3D"margin:0px;font-variant-numeric:normal;font-=
variant-east-asian:normal;font-stretch:normal;font-size:12px;line-height:no=
rmal;font-family:Helvetica">As I said in the summary of the first Taproot a=
ctivation meeting whether lockinontimeout (LOT) is set to true or false in =
a Bitcoin Core release attracted discussion during the meeting and has cont=
inued to attract discussion afterwards.</p>
<p class=3D"gmail-p2" style=3D"margin:0px;font-variant-numeric:normal;font-=
variant-east-asian:normal;font-stretch:normal;font-size:12px;line-height:no=
rmal;font-family:Helvetica;min-height:14px"><br></p>
<p class=3D"gmail-p1" style=3D"margin:0px;font-variant-numeric:normal;font-=
variant-east-asian:normal;font-stretch:normal;font-size:12px;line-height:no=
rmal;font-family:Helvetica">I will weigh up the arguments I have seen for b=
oth true and false here. I won=E2=80=99t comment on the strength of the arg=
uments, merely attempt to summarize them. Any errors are my own.</p>
<p class=3D"gmail-p2" style=3D"margin:0px;font-variant-numeric:normal;font-=
variant-east-asian:normal;font-stretch:normal;font-size:12px;line-height:no=
rmal;font-family:Helvetica;min-height:14px"><br></p>
<p class=3D"gmail-p1" style=3D"margin:0px;font-variant-numeric:normal;font-=
variant-east-asian:normal;font-stretch:normal;font-size:12px;line-height:no=
rmal;font-family:Helvetica">Arguments for setting lockinontimeout (LOT) to =
true in a Core release</p>
<p class=3D"gmail-p1" style=3D"margin:0px;font-variant-numeric:normal;font-=
variant-east-asian:normal;font-stretch:normal;font-size:12px;line-height:no=
rmal;font-family:Helvetica">T1) This entirely eradicates the possibility (h=
owever unlikely) that Taproot fails to activate within a year. Although app=
roximately 90 percent of mining pools have already pledged to activate Tapr=
oot there is no reason to open the door to possible delays and political sh=
enanigans for no reason, however unlikely.</p>
<p class=3D"gmail-p1" style=3D"margin:0px;font-variant-numeric:normal;font-=
variant-east-asian:normal;font-stretch:normal;font-size:12px;line-height:no=
rmal;font-family:Helvetica">T2) Given users can change LOT=3Dtrue at any po=
int (and some have declared they will be setting LOT=3Dtrue regardless), se=
tting LOT=3Dfalse in Core opens up edge case scenarios where different prop=
ortions of users on the network change to LOT=3Dtrue at different points in=
 time in an uncoordinated fashion. Given the end state we all want is Tapro=
ot activated it doesn=E2=80=99t make sense to open the door to these edge c=
ases. Setting LOT=3Dtrue in Core would mean there is no motivation for user=
s to change LOT in the software they are running.</p>
<p class=3D"gmail-p1" style=3D"margin:0px;font-variant-numeric:normal;font-=
variant-east-asian:normal;font-stretch:normal;font-size:12px;line-height:no=
rmal;font-family:Helvetica">T3) We should not be putting users in a place w=
here they feel they need to change LOT. The urge to change LOT will be stro=
ng if miners delay for an unreasonable period. We are then in a situation w=
here a decision has to be made on whether Core releases a new version with =
LOT=3Dtrue and this whole discussion kicks off again. We should definitely =
seek to avoid the need to rehash this discussion later=C2=A0in=C2=A0the yea=
r.</p>
<p class=3D"gmail-p1" style=3D"margin:0px;font-variant-numeric:normal;font-=
variant-east-asian:normal;font-stretch:normal;font-size:12px;line-height:no=
rmal;font-family:Helvetica">T4) LOT is only relevant if miners fail to acti=
vate. It doesn=E2=80=99t make sense to set it to false as that is essential=
ly saying if miners fail to activate early, LOT should also let them not ac=
tivate.</p>
<p class=3D"gmail-p1" style=3D"margin:0px;font-variant-numeric:normal;font-=
variant-east-asian:normal;font-stretch:normal;font-size:12px;line-height:no=
rmal;font-family:Helvetica">T5) Activation should only be attempted once co=
mmunity consensus for the soft fork has been reached. Miner signaling is no=
t voting for the changes, it is signaling readiness. There is no reasonable=
 rationale for not being ready within a year.</p>
<p class=3D"gmail-p1" style=3D"margin:0px;font-variant-numeric:normal;font-=
variant-east-asian:normal;font-stretch:normal;font-size:12px;line-height:no=
rmal;font-family:Helvetica">T6) An argument belcher outlined on IRC. If LOT=
 was set to true and a chain split happened then the Taproot chain doesn=E2=
=80=99t have wipeout risk so there=E2=80=99s a really strong incentive to b=
e on the Taproot activating LOT=3Dtrue chain and therefore using LOT=3Dtrue=
 means the risk of a chain split is actually lower.</p>
<p class=3D"gmail-p2" style=3D"margin:0px;font-variant-numeric:normal;font-=
variant-east-asian:normal;font-stretch:normal;font-size:12px;line-height:no=
rmal;font-family:Helvetica;min-height:14px"><br></p>
<p class=3D"gmail-p2" style=3D"margin:0px;font-variant-numeric:normal;font-=
variant-east-asian:normal;font-stretch:normal;font-size:12px;line-height:no=
rmal;font-family:Helvetica;min-height:14px"><br></p>
<p class=3D"gmail-p1" style=3D"margin:0px;font-variant-numeric:normal;font-=
variant-east-asian:normal;font-stretch:normal;font-size:12px;line-height:no=
rmal;font-family:Helvetica">Arguments for setting lockinontimeout (LOT) to =
false in a Core release</p>
<p class=3D"gmail-p1" style=3D"margin:0px;font-variant-numeric:normal;font-=
variant-east-asian:normal;font-stretch:normal;font-size:12px;line-height:no=
rmal;font-family:Helvetica">F1) The probability of Taproot not being activa=
ted by miners is small. This is not 2017, this is not SegWit, there is no n=
eed to worry.<span class=3D"gmail-Apple-converted-space">=C2=A0</span></p>
<p class=3D"gmail-p1" style=3D"margin:0px;font-variant-numeric:normal;font-=
variant-east-asian:normal;font-stretch:normal;font-size:12px;line-height:no=
rmal;font-family:Helvetica">F2) The worst case scenario is we have to wait =
over a year for Taproot to be activated. Even the worst case scenario is no=
t a disaster.</p>
<p class=3D"gmail-p1" style=3D"margin:0px;font-variant-numeric:normal;font-=
variant-east-asian:normal;font-stretch:normal;font-size:12px;line-height:no=
rmal;font-family:Helvetica">F3) If in the unlikely scenario miners did not =
activate Taproot for a year for no apparent reason we would never set LOT t=
o false again for any potential future soft fork. If miners fail to activat=
e Taproot despite pledging support and there being overwhelming community c=
onsensus for it, it would set a precedent that miners cannot be relied upon=
 *at all* to activate soft forks.</p>
<p class=3D"gmail-p1" style=3D"margin:0px;font-variant-numeric:normal;font-=
variant-east-asian:normal;font-stretch:normal;font-size:12px;line-height:no=
rmal;font-family:Helvetica">F4) If in the highly unlikely scenario that a b=
ug or some problem with the Taproot implementation was found during the sig=
naling period miners could choose not to activate it which is cleaner than =
needing an emergency Core release.</p>
<p class=3D"gmail-p2" style=3D"margin:0px;font-variant-numeric:normal;font-=
variant-east-asian:normal;font-stretch:normal;font-size:12px;line-height:no=
rmal;font-family:Helvetica;min-height:14px"><br></p>
<p class=3D"gmail-p1" style=3D"margin:0px;font-variant-numeric:normal;font-=
variant-east-asian:normal;font-stretch:normal;font-size:12px;line-height:no=
rmal;font-family:Helvetica">Then some additional arguments nullc posted on =
Reddit</p>
<p class=3D"gmail-p1" style=3D"margin:0px;font-variant-numeric:normal;font-=
variant-east-asian:normal;font-stretch:normal;font-size:12px;line-height:no=
rmal;font-family:Helvetica"><a href=3D"https://old.reddit.com/r/Bitcoin/com=
ments/lcjhl6/taproot_activation_pools_will_be_able_to_veto/gm2l02w/">https:=
//old.reddit.com/r/Bitcoin/comments/lcjhl6/taproot_activation_pools_will_be=
_able_to_veto/gm2l02w/</a></p>
<p class=3D"gmail-p1" style=3D"margin:0px;font-variant-numeric:normal;font-=
variant-east-asian:normal;font-stretch:normal;font-size:12px;line-height:no=
rmal;font-family:Helvetica">F5) LOT =3D false is more similar to what was d=
one previously (unless you go way back to the earliest soft forks which wer=
e more similar to LOT =3D true)</p>
<p class=3D"gmail-p1" style=3D"margin:0px;font-variant-numeric:normal;font-=
variant-east-asian:normal;font-stretch:normal;font-size:12px;line-height:no=
rmal;font-family:Helvetica">F6) It is more important that no rules that har=
m users are deployed than it is that new useful rules are deployed quickly.=
 If there is a choice between =E2=80=9Cfaster=E2=80=9D and =E2=80=9Cmore cl=
ear that this isn=E2=80=99t a mechanism to force bad things on users=E2=80=
=9D we should prefer the latter. Plenty of people just don=E2=80=99t like L=
OT=3Dtrue very much absent evidence that miners are blocking deployment. To=
 some it just feels needlessly antagonistic and distrusting towards part of=
 our community.</p>
<p class=3D"gmail-p2" style=3D"margin:0px;font-variant-numeric:normal;font-=
variant-east-asian:normal;font-stretch:normal;font-size:12px;line-height:no=
rmal;font-family:Helvetica;min-height:14px"><br></p>
<p class=3D"gmail-p1" style=3D"margin:0px;font-variant-numeric:normal;font-=
variant-east-asian:normal;font-stretch:normal;font-size:12px;line-height:no=
rmal;font-family:Helvetica">There are some additional parameters other than=
 LOT we will discuss in this meeting such as activation threshold, start ti=
me etc but personally I don=E2=80=99t think they will attract the same disc=
ussion as LOT.</p>
<p class=3D"gmail-p2" style=3D"margin:0px;font-variant-numeric:normal;font-=
variant-east-asian:normal;font-stretch:normal;font-size:12px;line-height:no=
rmal;font-family:Helvetica;min-height:14px"><br></p>
<p class=3D"gmail-p1" style=3D"margin:0px;font-variant-numeric:normal;font-=
variant-east-asian:normal;font-stretch:normal;font-size:12px;line-height:no=
rmal;font-family:Helvetica">As I=E2=80=99ve stated before please continue t=
o engage productively and in good faith. I can see arguments with merit on =
both sides of the LOT discussion but there appears to be overwhelming conse=
nsus that Taproot is activated this year and there appears to be no reason =
it shouldn=E2=80=99t be. This discussion on LOT really should not derail th=
at.</p><div><br></div>-- <br><div dir=3D"ltr" class=3D"gmail_signature" dat=
a-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div=
><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div d=
ir=3D"ltr"><font face=3D"arial, helvetica, sans-serif" color=3D"#000000">Mi=
chael Folkson</font><div><font face=3D"arial, helvetica, sans-serif" color=
=3D"#000000">Email:=C2=A0<a href=3D"mailto:michaelfolkson@gmail.com" target=
=3D"_blank">michaelfolkson@gmail.com</a></font></div><div><font face=3D"ari=
al, helvetica, sans-serif" color=3D"#000000">Keybase: michaelfolkson</font>=
</div><div><font face=3D"arial, helvetica, sans-serif" color=3D"#000000">PG=
P: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3</font></div></div></di=
v></div></div></div></div></div></div></div></div></div>

--0000000000001f633105ba962d1f--