path: root/66/6f216dc8212d443a947c3bcffd9d24d0bed245

Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id CA1FCC000D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 19 Feb 2021 11:30:22 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id AC5086068A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 19 Feb 2021 11:30:22 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id IR900OKtZhCn
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 19 Feb 2021 11:30:19 +0000 (UTC)
Received: by smtp3.osuosl.org (Postfix, from userid 1001)
 id 71A5E606D7; Fri, 19 Feb 2021 11:30:19 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch
 [185.70.40.135])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 21E99606D8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 19 Feb 2021 11:30:14 +0000 (UTC)
Date: Fri, 19 Feb 2021 11:30:08 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail; t=1613734209;
 bh=7YKfckDAIxEgXJfR06tjEEm2qx389JMMyYN3/NAdEH4=;
 h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
 b=j7ZL93H9jALcjcOjaeS+aA4Bt5JHgGNvoRw3wUzlWxS3ASHKtiasGD1DZFdKiB2cX
 5FQkTbHFjQCF8wDiQmZJJX7N0al0tZBQlmVzeW9LtKg2BehDUb4vcvZSsbhUWEizHN
 tLShD1ohWzEH1LLIvPIrvC90+vcWTrB/OG16n2T4=
To: Matt Corallo <lf-lists@mattcorallo.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <3MD7z0ETqJZtDw2expUQkoDEwES5BnvCkgjBz4q8h9QRJTK86U9A-EL8pGTprlvjExItC3bz9AxGBNJuk0vqHBX6lnrKqmTEThy9VLA3pNs=@protonmail.com>
In-Reply-To: <a1ae49f7-049f-cda5-19af-e02a8952e5a4@mattcorallo.com>
References: <CAFvNmHSHu0gqVgWxOCJnSTf5mxpWsMF9FrMQ+_X+uyR3P4QCsg@mail.gmail.com>
 <8591CF93-E574-4C23-90D5-FA410637DECD@mattcorallo.com>
 <CAFvNmHSwRGEy-kE8OA4mcDJ+fJjO7J1ckThWY=wqv4yge-MA1Q@mail.gmail.com>
 <7b8543c3-8ff2-3a6a-b2d4-f4a6cf150d78@mattcorallo.com>
 <CALeFGL1e+q2mrCox99sUOAXYu3qcC7Xce7AfkuKuLPmxh1oSiA@mail.gmail.com>
 <a1ae49f7-049f-cda5-19af-e02a8952e5a4@mattcorallo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Michael Folkson <michaelfolkson@gmail.com>
Subject: Re: [bitcoin-dev] Yesterday's Taproot activation meeting on
	lockinontimeout (LOT)
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, 19 Feb 2021 11:30:22 -0000

Good morning list,

> This is absolutely the case, however note that the activation method itse=
lf is consensus code which executes as a part
> of a fork, and one which deserves as much scrutiny as anything else. Whil=
e taproot is a model of how a soft-fork should
> be designed, this doesn't imply anything about the consensus code which r=
epresents the activation thereof.
>
> Hence all the debate around activation - ultimately its also defining a f=
ork, and given the politics around it, one
> which almost certainly carries significantly more risk than Taproot.
>
> Note that I don't believe anyone is advocating for "try to activate, and =
if it fails, move on". Various people have
> various views on how conservative and timelines for what to do at that po=
int, but I believe most in this discussion are
> OK with flag-day-based activation (given some level of care) if it become=
s clear Taproot is supported by a vast majority
> of Bitcoin users and is only not activating due to lagging miner upgrades=
.


Okay, I am backing off this proposal to force the LOT=3Dfalse/true decision=
 on users, it was not particularly serious anyway (and was more a reaction =
to the request of Samson Mow to just release both versions, which to my min=
d is no different from such a thing).


Nonetheless, as a thought experiment: the main issue is that some number of=
 people run LOT=3Dtrue when miners do not activate Taproot early for some r=
eason and we decide to leave LOT=3Dfalse for this particular bit until it t=
imes out.
The issue is that those people will get forked off the network at the end o=
f this particular deployment attempt.

I suspect those people will still exist whether or not Bitcoin Core support=
s any kind of LOT=3Dtrue mode.
("Never again" for some people)

How do we convince them to go run LOT=3Dfalse instead of getting themselves=
 forked off?
Or do we simply let them?

(and how is that different from asking each user to decide on LOT=3Dfalse/t=
rue right now?)
("reasonable default"?)
(fundamentally speaking you still have to educate the users on the ramifica=
tions of accepting the default and changing it.)


Another thought experiment: From the point of view of a user who strongly s=
upports LOT=3Dtrue, would dev consensus around releasing LOT=3Dfalse be con=
sidered as "developers forcing their views on users"?
Why or why not?


Regards,
ZmnSCPxj

> Matt
>
> On 2/18/21 10:04, Keagan McClelland wrote:
>
> > Hi all,
> > I think it's important for us to consider what is actually being consid=
ered for activation here.
> > The designation of "soft fork" is accurate but I don't think it adequat=
ely conveys how non-intrusive a change like this
> > is. All that taproot does (unless I'm completely missing something) is =
imbue a previously undefined script version with
> > actual semantics. In order for a chain reorg to take place it would mea=
n that someone would have to have a use case for
> > that script version today. This is something I think that we can easily=
 check by digging through the UTXO set or
> > history. If anyone is using that script version, we absolutely should n=
ot be using it, but that doesn't mean that we
> > can't switch to a script version that no one is actually using.
> > If no one is even attempting to use the script version, then the change=
 has no effect on whether a chain split occurs
> > because there is simply no block that contains a transaction that only =
some of the network will accept.
> > Furthermore, I don't know how Bitcoin can stand the test of time if we =
allow developers who rely on "undefined behavior"
> > (which the taproot script version presently is) to exert tremendous inf=
luence over what code does or does not get run.
> > This isn't a soft fork that makes some particular UTXO's unspendable. I=
t isn't one that bans miners from collecting
> > fees. It is a change that means that certain "always accept" transactio=
ns actually have real conditions you have to
> > meet. I can't imagine a less intrusive change.
> > On the other hand, choosing to let L=3DF be a somewhat final call sets =
a very real precedent that 10% of what I estimate
> > to be 1% of bitcoin users can effectively block any change from here on=
 forward. At that point we are saying that miners
> > are in control of network consensus in ways they have not been up until=
 now. I don't think this is a more desirable
> > outcome to let ~0.1% of the network get to block /non-intrusive/=C2=
=A0changes that the rest of the network wants.
> > I can certainly live with an L=3DF attempt as a way to punt on the disc=
ussion, maybe the activation happens and this will
> > all be fine. But if it doesn't, I hardly think that users of Bitcoin ar=
e just going to be like "well, guess that's it
> > for Taproot". I have no idea what ensues at that point, but probably an=
other community led UASF movement.
> > I wasn't super well educated on this stuff back in '17 when Segwit went=
 down, as I was new at that time, so if I'm
> > missing something please say so. But from my point of view, we can't tr=
eat all soft forks as equal.
> > Keagan
> > On Thu, Feb 18, 2021 at 7:43 AM Matt Corallo via bitcoin-dev <bitcoin-d=
ev@lists.linuxfoundation.org
> > mailto:bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> >     We've had several softforks in Bitcoin which, through the course of=
 their activation, had a several-block reorg. That
> >     should be indication enough that we need to very carefully consider=
 activation to ensure we reduce the risk of that as
> >     much as absolutely possible. Again, while I think Taproot is a huge=
 improvement and am looking forward to being able to
> >     use it, getting unlucky and hitting a 4-block reorg that happens to=
 include a double-spend and some PR around an
> >     exchange losing millions would be worse than having Taproot is good=
.
> >
> >     Matt
> >
> >     On 2/18/21 09:26, Michael Folkson wrote:
> >      > Thanks for your response Matt. It is a fair challenge. There is =
always going to be an element of risk with soft
> >     forks,
> >      > all we can do is attempt to minimize that risk. I would argue th=
at risk has been minimized for Taproot.
> >      >
> >      > You know (better than I do in fact) that Bitcoin (and layers bui=
lt on top of it) greatly benefit from upgrades
> >     such as
> >      > Taproot. To say we shouldn't do Taproot or any future soft forks=
 because there is a small but real risk of chain
> >     splits
> >      > I think is shortsighted. Indeed I think even if we collectively=
=C2=A0decided not to do any future soft fork upgrades ever
> >      > again on this mailing list that wouldn't stop soft fork attempts=
 from other people in future.
> >      >
> >      > I don't think there is anything else we can do to minimize that =
risk for the Taproot soft fork at this point
> >     though I'm
> >      > open to ideas. To reiterate that risk will never be zero. I don'=
t think I see Bitcoin as fragile as you seem to
> >     (though
> >      > admittedly you have a much better understanding than me of what =
happened in 2017).
> >      >
> >      > The likely scenario for the Taproot soft fork is LOT turns out t=
o be entirely irrelevant and miners activate Taproot
> >      > before it becomes relevant. And even the unlikely worst case sce=
nario would only cause short term disruption and
> >      > wouldn't kill Bitcoin long term.
> >      >
> >      > On Thu, Feb 18, 2021 at 2:01 PM Matt Corallo <lf-lists@mattcoral=
lo.com <mailto:lf-lists@mattcorallo.com>
> >     <mailto:lf-lists@mattcorallo.com <mailto:lf-lists@mattcorallo.com>>=
> wrote:
> >      >
> >      >=C2=A0 =C2=A0 =C2=A0If the eventual outcome is that different imp=
lementations (that have material *transaction processing* userbases,
> >      >=C2=A0 =C2=A0 =C2=A0and I=E2=80=99m not sure to what extent that=
=E2=80=99s true with Knots) ship different consensus rules, we should stop =
here
> >     and not
> >      >=C2=A0 =C2=A0 =C2=A0activate Taproot. Seriously.
> >      >
> >      >=C2=A0 =C2=A0 =C2=A0Bitcoin is a consensus system. The absolute w=
orst outcome at all possible is to have it fall out of consensus.
> >      >
> >      >=C2=A0 =C2=A0 =C2=A0Matt
> >      >
> >      >>=C2=A0 =C2=A0 =C2=A0On Feb 18, 2021, at 08:11, Michael Folkson v=
ia bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org
> >     <mailto:bitcoin-dev@lists.linuxfoundation.org>
> >      >>=C2=A0 =C2=A0 =C2=A0<mailto:bitcoin-dev@lists.linuxfoundation.or=
g <mailto:bitcoin-dev@lists.linuxfoundation.org>>> wrote:
> >      >>
> >      >>=C2=A0 =C2=A0 =C2=A0=EF=BB=BF
> >      >>=C2=A0 =C2=A0 =C2=A0Right, that is one option. Personally I woul=
d prefer a Bitcoin Core release sets LOT=3Dfalse (based on what I have
> >      >>=C2=A0 =C2=A0 =C2=A0heard from Bitcoin Core contributors) and a =
community effort releases a version with LOT=3Dtrue. I don't think
> >     users
> >      >>=C2=A0 =C2=A0 =C2=A0should be forced to choose something they ma=
y have no context on before they are allowed to use Bitcoin Core.
> >      >>
> >      >>=C2=A0 =C2=A0 =C2=A0My current understanding is that roasbeef is=
 planning to set LOT=3Dfalse on btcd (an alternative protocol
> >      >>=C2=A0 =C2=A0 =C2=A0implementation to Bitcoin Core) and Luke Das=
hjr hasn't yet decided on Bitcoin Knots.
> >      >>
> >      >>
> >      >>
> >      >>=C2=A0 =C2=A0 =C2=A0On Thu, Feb 18, 2021 at 11:52 AM ZmnSCPxj <Z=
mnSCPxj@protonmail.com <mailto:ZmnSCPxj@protonmail.com>
> >     <mailto:ZmnSCPxj@protonmail.com <mailto:ZmnSCPxj@protonmail.com>>> =
wrote:
> >      >>
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Good morning all,
> >      >>
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> "An activation mechanism is =
a consensus change like any other change, can be contentious like any other
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0change, and we must resolve it=
 like any other change. Otherwise we risk arriving at the darkest timeline.=
"
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> Who's we here?
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> Release both and let the net=
work decide.
> >      >>
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A thing that could be done, wi=
thout mandating either LOT=3Dtrue or LOT=3Dfalse, would be to have a releas=
e that
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0requires a `taprootlot=3D1` or=
 `taprootlot=3D0` and refuses to start if the parameter is not set.
> >      >>
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This assures everyone that nei=
ther choice is being forced on users, and instead what is being forced on
> >     users,
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is for users to make that choi=
ce themselves.
> >      >>
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Regards,
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ZmnSCPxj
> >      >>
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> On Thu, Feb 18, 2021 at 3:08=
 AM Michael Folkson via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org
> >     <mailto:bitcoin-dev@lists.linuxfoundation.org>
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:bitcoin-dev@lists.linu=
xfoundation.org <mailto:bitcoin-dev@lists.linuxfoundation.org>>> wrote:
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > Thanks for your response A=
riel. It would be useful if you responded to specific points I have made
> >     in the
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mailing list post or at least =
quote these ephemeral "people" you speak of. I don't know if you're respond=
ing
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to conversation on the IRC cha=
nnel or on social media etc.
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> >
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > The argument comes from =
a naive assumption that users MUST upgrade to the choice that is submitted
> >     into
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0code. But in fact this isn't t=
rue and some voices in this discussion need to be more humble about what us=
ers
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0must or must not run.
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> >
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > I personally have never ma=
de this assumption. Of course users aren't forced to run any particular
> >     software
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0version, quite the opposite. D=
efaults set in software versions matter though as many users won't change
> >     them.
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> >
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > Does no one realize that=
 it is a very possible outcome that if LOT=3Dtrue is released there may be
> >     only a
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0handful of people that begin r=
unning it while everyone else delays their upgrade (with the very good
> >     reason of
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0not getting involved in politi=
cs) and a year later those handful of people just become stuck at the
> >     moment of
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MUST_SIGNAL, unable to mine ne=
w blocks?
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> >
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > It is a possible outcome b=
ut the likely outcome is that miners activate Taproot before LOT is even
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0relevant. I think it is pruden=
t to prepare for the unlikely but possible outcome that miners fail to
> >     activate
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and hence have this discussion=
 now rather than be unprepared for that eventuality. If LOT is set to
> >     false in a
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0software release there is the =
possibility (T2 in
> >      >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-Fe=
bruary/018380.html
> >     <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-Febru=
ary/018380.html>
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://lists.linuxfoundation=
.org/pipermail/bitcoin-dev/2021-February/018380.html
> >     <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-Febru=
ary/018380.html>>) of individuals or a
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0proportion of the community ch=
anging LOT to true. In that sense setting LOT=3Dfalse in a software release
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0appears to be no more safe tha=
n LOT=3Dtrue.
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> >
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > The result: a wasted yea=
r of waiting and a minority of people who didn't want to be lenient with
> >     miners
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0by default.
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> >
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > There is the (unlikely but=
 possible) possibility of a wasted year if LOT is set to false and miners f=
ail
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to activate. I'm not convinced=
 by this perception that LOT=3Dtrue is antagonistic to miners. I actually
> >     think it
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0offers them clarity on what wi=
ll happen over a year time period and removes the need for coordinated or
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uncoordinated community UASF e=
fforts on top of LOT=3Dfalse.
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> >
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > An activation mechanism =
is a consensus change like any other change, can be contentious like any ot=
her
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0change, and we must resolve it=
 like any other change. Otherwise we risk arriving at the darkest timeline.
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> >
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > I don't know what you are =
recommending here to avoid "this darkest timeline". Open discussions have
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0occurred and are continuing an=
d in my mailing list post that you responded to **I recommended we propose
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0LOT=3Dfalse be set in protocol=
 implementations such as Bitcoin Core**. I do think this apocalyptic langua=
ge
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0isn't particularly helpful. In=
 an open consensus system discussion is healthy, we should prepare for bad =
or
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0worst case scenarios in advanc=
e and doing so is not antagonistic or destructive. Mining pools=C2=A0have p=
ledged
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0support for Taproot but we don=
't build secure systems based on pledges of support, we build them to minim=
ize
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0trust in any human actors. We =
can be grateful that people like Alejandro have worked hard on
> >      >> taprootactivation.com <http://taprootactivation.com> <http://ta=
prootactivation.com
> >     <http://taprootactivation.com>> (and this effort has informed the d=
iscussion) without
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0taking pledges of support as c=
ast iron guarantees.
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> >
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > TL;DR It sounds like you a=
gree with my recommendation to set LOT=3Dfalse in protocol implementations =
in my
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0email :)
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> >
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > On Thu, Feb 18, 2021 at 5:=
43 AM Ariel Lorenzo-Luaces <arielluaces@gmail.com
> >     <mailto:arielluaces@gmail.com>
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:arielluaces@gmail.com =
<mailto:arielluaces@gmail.com>>> wrote:
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> >
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > Something what strikes m=
e about the conversation is the emotion surrounding the letters UASF.
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > It appears as if people =
discuss UASF as if it's a massive tidal wave of support that is
> >     inevitable, like
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0we saw during segwit activatio=
n. But the actual definition is "any activation that is not a MASF".
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > A UASF can consist of a =
single node, ten nodes, a thousand, half of all nodes, all business' nodes,=
 or
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0even all the non mining nodes.=
 On another dimension it can have zero mining support, 51% support, 49%
> >     support,
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0or any support right up agains=
t a miner activation threshold.
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > Hell a UASF doesn't even=
 need code or even a single node running as long as it exists as a possibil=
ity
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in people's minds.
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > The only thing a UASF do=
esn't have is miner support above an agreed activation threshold (some numb=
er
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0above %51).
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > I say this because it st=
rikes me when people say that they are for LOT=3Dtrue with the logic that
> >     since a
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0UASF is guaranteed to happen t=
hen it's better to just make it default from the beginning. Words like
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0coordination and safety are so=
metimes sprinkled into the argument.
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > The argument comes from =
a naive assumption that users MUST upgrade to the choice that is submitted
> >     into
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0code. But in fact this isn't t=
rue and some voices in this discussion need to be more humble about what us=
ers
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0must or must not run.
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > Does no one realize that=
 it is a very possible outcome that if LOT=3Dtrue is released there may be
> >     only a
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0handful of people that begin r=
unning it while everyone else delays their upgrade (with the very good
> >     reason of
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0not getting involved in politi=
cs) and a year later those handful of people just become stuck at the
> >     moment of
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MUST_SIGNAL, unable to mine ne=
w blocks? Or attracting a minority of miners, activating, and forking off
> >     into a
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0minority fork. Then a lot=3Dfa=
lse could be started that ends up activating the feature now that the stubb=
orn
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0option has ran its course.
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > The result: a wasted yea=
r of waiting and a minority of people who didn't want to be lenient with
> >     miners
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0by default. The chains could b=
e called BitcoinLenient and BitcoinStubborn.
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > How is that strictly saf=
er or more coordinated?
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > I may be in the minority=
, or maybe a silent majority, or maybe a majority that just hasn't consider=
ed
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0this as a choice but honestly =
if there is contention about whether we're going to be stubborn or lenient
> >     with
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0miners for Taproot and in the =
future then I prefer to just not activate anything at all. I'm fine for
> >     calling
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bitcoin ossified, accepting th=
at segwit is Bitcoin's last network upgrade. Taproot is amazing but no new
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0feature is worth a network spl=
it down the middle.
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > Maybe in 10 or 20 years,=
 when other blockchains implement features like Taproot and many more, we w=
ill
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0become envious enough to put a=
side our differences on how to behave towards miners and finally activate
> >     Taproot.
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > An activation mechanism =
is a consensus change like any other change, can be contentious like any ot=
her
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0change, and we must resolve it=
 like any other change. Otherwise we risk arriving at the darkest timeline.
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > Cheers
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > Ariel Lorenzo-Luaces
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > On Feb 17, 2021, at 7:05=
 AM, Michael Folkson via bitcoin-dev
> >     <bitcoin-dev@lists.linuxfoundation.org <mailto:bitcoin-dev@lists.li=
nuxfoundation.org>
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:bitcoin-dev@lists.linu=
xfoundation.org <mailto:bitcoin-dev@lists.linuxfoundation.org>>> wrote:
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > >
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > Yesterday (February 16=
th) we held a second meeting on Taproot
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > activation on IRC whic=
h again was open to all. Despite what appeared
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > to be majority support=
 for LOT=3Dfalse over LOT=3Dtrue in the first
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > meeting I (and others)=
 thought the arguments had not been explored in
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > depth and that we shou=
ld have a follow up meeting almost entirely
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > focused on whether LOT=
 (lockinontimeout) should be set to true or
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > false.
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > >
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > The meeting was announ=
ced here:
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > https://lists.linuxfou=
ndation.org/pipermail/bitcoin-dev/2021-February/018380.html
> >     <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-Febru=
ary/018380.html>
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://lists.linuxfoundation=
.org/pipermail/bitcoin-dev/2021-February/018380.html
> >     <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-Febru=
ary/018380.html>>
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > >
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > In that mailing list p=
ost I outlined the arguments for LOT=3Dtrue (T1 to
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > T6) and arguments for =
LOT=3Dfalse (F1 to F6) in their strongest form I
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > could. David Harding r=
esponded with an additional argument for
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > LOT=3Dfalse (F7) here:
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > https://lists.linuxfou=
ndation.org/pipermail/bitcoin-dev/2021-February/018415.html
> >     <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-Febru=
ary/018415.html>
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://lists.linuxfoundation=
.org/pipermail/bitcoin-dev/2021-February/018415.html
> >     <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-Febru=
ary/018415.html>>
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > >
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > These meetings are ver=
y challenging given they are open to all, you
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > don=E2=80=99t know who=
 will attend and you don=E2=80=99t know most people=E2=80=99s views in
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > advance. I tried to gi=
ve time for both the LOT=3Dtrue arguments and the
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > LOT=3Dfalse arguments =
to be discussed as I knew there was support for
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > both. We only tried ev=
aluating which had more support and which had
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > more strong opposition=
 towards the end of the meeting.
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > >
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > The conversation log i=
s here:
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > http://gnusha.org/tapr=
oot-activation/2021-02-16.log
> >     <http://gnusha.org/taproot-activation/2021-02-16.log> <http://gnush=
a.org/taproot-activation/2021-02-16.log
> >     <http://gnusha.org/taproot-activation/2021-02-16.log>>
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > >
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > (If you are so incline=
d you can watch a video of the meeting here.
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > Thanks to the YouTube =
account =E2=80=9CBitcoin=E2=80=9D for setting up the livestream:
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > https://www.youtube.co=
m/watch?v=3Dvpl5q1ovMLM <https://www.youtube.com/watch?v=3Dvpl5q1ovMLM>
> >     <https://www.youtube.com/watch?v=3Dvpl5q1ovMLM <https://www.youtube=
.com/watch?v=3Dvpl5q1ovMLM>>)
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > >
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > A summary of the meeti=
ng was provided by Luke Dashjr on Mastodon here:
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > https://bitcoinhackers=
.org/@lukedashjr/105742918779234566
> >     <https://bitcoinhackers.org/@lukedashjr/105742918779234566>
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://bitcoinhackers.org/@l=
ukedashjr/105742918779234566
> >     <https://bitcoinhackers.org/@lukedashjr/105742918779234566>>
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > >
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > Today's #Bitcoin #Tapr=
oot meeting was IMO largely unproductive, but we
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > did manage to come to =
consensus on everything but LockinOnTimeout.
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > >
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > Activation height rang=
e: 693504-745920
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > >
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > MASF threshold: 1815/2=
016 blocks (90%)
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > >
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > Keep in mind only ~100=
 people showed for the meetings, hardly
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > representative of the =
entire community.
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > >
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > So, these details rema=
in JUST a proposal for now.
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > >
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > It seems inevitable th=
at there won't be consensus on LOT.
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > >
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > Everyone will have to =
choose for himself. :/
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > >
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > Personally I agree wit=
h most of this. I agree that there wasn=E2=80=99t
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > overwhelming consensus=
 for either LOT=3Dtrue or LOT=3Dfalse. However, from
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > my perspective there w=
as clearly more strong opposition (what would
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > usually be deemed a NA=
CK in Bitcoin Core review terminology) from
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > Bitcoin Core contribut=
ors, Lightning developers and other community
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > members against LOT=3D=
true than there was for LOT=3Dfalse. Andrew Chow
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > tried to summarize vie=
ws from the meeting in this analysis:
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > https://gist.github.co=
m/achow101/3e179501290abb7049de198d46894c7c
> >     <https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c>
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://gist.github.com/achow=
101/3e179501290abb7049de198d46894c7c
> >     <https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c>=
>
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > >
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > I am also aware of oth=
er current and previous Bitcoin Core
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > contributors and Light=
ning developers who didn=E2=80=99t attend the meeting in
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > person who are opposed=
 to LOT=3Dtrue. I don=E2=80=99t want to put them in the
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > spotlight for no reaso=
n but if you go through the conversation logs of
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > not only the meeting b=
ut the weeks of discussion prior to this meeting
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > you will see their vie=
ws evaluated on the ##taproot-activation
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > channel. In addition, =
on taprootactivation.com <http://taprootactivation.com>
> >     <http://taprootactivation.com <http://taprootactivation.com>> some =
mining pools
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > expressed a preference=
 for lot=3Dfalse though I don=E2=80=99t know how strong
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > that preference was.
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > >
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > I am only one voice bu=
t it is my current assessment that if we are to
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > attempt to finalize Ta=
proot activation parameters and propose them to
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > the community at this =
time our only option is to propose LOT=3Dfalse.
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > Any further delay appe=
ars to me counterproductive in our collective
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > aim to get the Taproot=
 soft fork activated as early as possible.
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > >
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > Obviously others are f=
ree to disagree with that assessment and
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > continue discussions b=
ut personally I will be attempting to avoid
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > those discussions unle=
ss prominent new information comes to light or
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > various specific indiv=
iduals change their minds.
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > >
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > Next week we are plann=
ing a code review of the Bitcoin Core PR #19573
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > which was initially de=
layed because of this LOT discussion. As I=E2=80=99ve
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > said previously that w=
ill be loosely following the format of the
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > Bitcoin Core PR review=
 club and will be lower level and more
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > technical. That is pla=
nned for Tuesday February 23rd at 19:00 UTC on
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > the IRC channel ##tapr=
oot-activation.
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > >
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > Thanks to the meeting =
participants (and those who joined the
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > discussion on the chan=
nel prior and post the meeting) for engaging
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > productively and in go=
od faith.
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> >
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > --
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > Michael Folkson
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > Email: michaelfolkson@gmai=
l.com <mailto:michaelfolkson@gmail.com> <mailto:michaelfolkson@gmail.com
> >     <mailto:michaelfolkson@gmail.com>>
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > Keybase: michaelfolkson
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > PGP: 43ED C999 9F85 1D40 E=
AF4 9835 92D6 0159 214C FEE3
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > __________________________=
_____________________
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > bitcoin-dev mailing list
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > bitcoin-dev@lists.linuxfou=
ndation.org <mailto:bitcoin-dev@lists.linuxfoundation.org>
> >     <mailto:bitcoin-dev@lists.linuxfoundation.org <mailto:bitcoin-dev@l=
ists.linuxfoundation.org>>
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > https://lists.linuxfoundat=
ion.org/mailman/listinfo/bitcoin-dev
> >     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
> >      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://lists.linuxfoundation=
.org/mailman/listinfo/bitcoin-dev
> >     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>>
> >      >>
> >      >>
> >      >>
> >      >>
> >      >>=C2=A0 =C2=A0 =C2=A0--
> >      >>=C2=A0 =C2=A0 =C2=A0Michael Folkson
> >      >>=C2=A0 =C2=A0 =C2=A0Email: michaelfolkson@gmail.com <mailto:mich=
aelfolkson@gmail.com> <mailto:michaelfolkson@gmail.com
> >     <mailto:michaelfolkson@gmail.com>>
> >      >>=C2=A0 =C2=A0 =C2=A0Keybase: michaelfolkson
> >      >>=C2=A0 =C2=A0 =C2=A0PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159=
 214C FEE3
> >      >>=C2=A0 =C2=A0 =C2=A0____________________________________________=
___
> >      >>=C2=A0 =C2=A0 =C2=A0bitcoin-dev mailing list
> >      >> bitcoin-dev@lists.linuxfoundation.org <mailto:bitcoin-dev@lists=
.linuxfoundation.org>
> >     <mailto:bitcoin-dev@lists.linuxfoundation.org <mailto:bitcoin-dev@l=
ists.linuxfoundation.org>>
> >      >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
> >      >>=C2=A0 =C2=A0 =C2=A0<https://lists.linuxfoundation.org/mailman/l=
istinfo/bitcoin-dev
> >     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>>
> >      >
> >      >
> >      >
> >      > --
> >      > Michael Folkson
> >      > Email: michaelfolkson@gmail.com <mailto:michaelfolkson@gmail.com=
> <mailto:michaelfolkson@gmail.com
> >     <mailto:michaelfolkson@gmail.com>>
> >      > Keybase: michaelfolkson
> >      > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
> >     _______________________________________________
> >     bitcoin-dev mailing list
> >     bitcoin-dev@lists.linuxfoundation.org <mailto:bitcoin-dev@lists.lin=
uxfoundation.org>
> >     https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
> >
>
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev