path: root/af/8b9536ec89b507b9ef7e015386e00c4b6c8149

Return-Path: <michaelfolkson@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id CFF09C0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  4 Mar 2021 11:02:37 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id AED7E83148
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  4 Mar 2021 11:02:37 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.602
X-Spam-Level: 
X-Spam-Status: No, score=0.602 tagged_above=-999 required=5
 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id sbxhC65bg5FY
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  4 Mar 2021 11:02:36 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-oi1-x22f.google.com (mail-oi1-x22f.google.com
 [IPv6:2607:f8b0:4864:20::22f])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 652418434B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  4 Mar 2021 11:02:36 +0000 (UTC)
Received: by mail-oi1-x22f.google.com with SMTP id w65so6071170oie.7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 04 Mar 2021 03:02:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=vFyqlq6rgHBkPiII9UTC7+36sfDPV8/cxC7MzrUdqz0=;
 b=h4+28kx8uIP+d+webIL//ncZNlIDt4x0FRBWtFlxnFh2ErUEYEr47FuD1SMkntixgZ
 nYWrWQxWHuyJik9H4Yzr0bM5iUmQbpmtGDZaq9jLuTcVOpVAIqUm8UOn1Sp55vT91rqY
 sFc/aPxg/6t5oRIBGB2rYWiu+1UqKCLOWHFnk5mZ5kCNuRXCyLDysDTbQhk1lxSFHlr8
 dQ5GQwRRL/uTkM7yqhcz22fMz9yxzhb3S3f2yHj8GRD1MfMNUClIhLHSjoDKi0Xtk+MJ
 mQpeXvZ+EsWoVuS/u8hL/JfApqIx+5pZGHyCrBb6yszLcwVZbQnyIkODf+rfFHfPA/3R
 ffGA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=vFyqlq6rgHBkPiII9UTC7+36sfDPV8/cxC7MzrUdqz0=;
 b=TCtOO0LJVJp5xxztGH8TyFzLgQosxUu/EXQLKIQSnkQ27nVBD+Au8jG85Rfxd++MxB
 ZpVRpo4ssYbIrE0+J5mdCOF2iVc/XOz8YYzvsrloudmqVAuHcAZyAaOhLPCRE8CwQL4j
 j1aDiWLxsldFgA7uNrr6KxT3A3k+moCDKNCdPreIgPkaQrzgd/rJS0tg7CLOqpy+1kJH
 wEk3RabSvAaACqGjCp0qtlaCfWKpTqbmJU4FOxWu88l6Qq4npTb2IU4s3W87i0GuNEe/
 D+nsoj8cuqeP196HpwNOmSpgliqsY0KF8dwLAbiil+a3GaiyqevkN8ALY8YIvWRghDJP
 F1Zw==
X-Gm-Message-State: AOAM532S1WzzrCN1h4WTLiuYEie23mhOUvhJx/04z8W93b6jHf3RzV9l
 9G7bSm5YF0Sih++PYk3B16vyh9X/ezksGI+qyGjYiZNoTKJ3rg==
X-Google-Smtp-Source: ABdhPJxuM+mW6uBJvLME+I0nBcfLz6BLlUiOiDcl8qX3G1Oma2ohpcMqRHR0siiydeZJWzkx0c1QagQX8HbK8Et1UIc=
X-Received: by 2002:aca:aa96:: with SMTP id t144mr2596867oie.131.1614855270060; 
 Thu, 04 Mar 2021 02:54:30 -0800 (PST)
MIME-Version: 1.0
References: <CAFvNmHS8_5riG1FvzQvbWS_twxxTq82GFnT2gLGXirz23Q=pcw@mail.gmail.com>
 <CAOv1TnhbQZ2mfT3Hi75bCuPQ2TOM54iC+rHAV6HDbw7pPYvdzQ@mail.gmail.com>
In-Reply-To: <CAOv1TnhbQZ2mfT3Hi75bCuPQ2TOM54iC+rHAV6HDbw7pPYvdzQ@mail.gmail.com>
From: Michael Folkson <michaelfolkson@gmail.com>
Date: Thu, 4 Mar 2021 10:54:19 +0000
Message-ID: <CAFvNmHTu6PbJMF5TTLEVS1RzK2uTzNvOWn6Grksm_Rt9RTYWPQ@mail.gmail.com>
To: Ariel Luaces <arielluaces@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000bc559205bcb3ca43"
X-Mailman-Approved-At: Thu, 04 Mar 2021 11:23:13 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev]
	=?utf-8?b?WWVzdGVyZGF54oCZcyBVQVNGIChMT1Q9dHJ1ZSkg?=
	=?utf-8?q?kick_off_meeting?=
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: Thu, 04 Mar 2021 11:02:38 -0000

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

Hi Ariel

> I think Bitcoin is fine staying as is until that minority forks off with
their own alt-node....  A quick UASF fork allows for an early LOT=3Dfalse
activation.

I think you misunderstand BIP 8 (LOT=3Dtrue). Although no timetable has bee=
n
finalized as of yet (and hence we are in the realm of speculation rather
than facts), the earliest the MUST_SIGNAL period would kick in is around
July 2022. That doesn't sound very quick to me if you seek a LOT=3Dfalse
release after a LOT=3Dtrue release has failed to activate.

> The current risk to taproot and all future activations is a loud minority
of users who are threatening to co-opt a LOT=3Dfalse activation by switchin=
g
the parameter

As I've said in previous emails to this list, some people are determined to
ignore the discussion and (open to all) meetings of recent weeks and block
progress until they find their philosopher's stone. They seek to ignore all
the work people have done laying out the options, communicating those
options to the community and narrowing them down. Instead they bring up
alternative proposals which were discussed and rejected weeks or months
ago. With this mindset we'll still be arguing about Taproot activation in
2030.

I get that there isn't overwhelming consensus on the LOT parameter, this is
a fact. But there won't be overwhelming consensus on any activation
mechanism, that has become clear. I am of the view that consensus on one
parameter of an activation mechanism does not need to be as high as it is
on the actual soft fork that is being activated (which does have
overwhelming consensus). And of course if and when a LOT=3Dtrue (UASF)
version is released you are absolutely free not to run it. I hope (and
suspect) you would reconsider if July 2022 (or later) was approaching and
it was the only way to activate Taproot.

Thanks
Michael





On Thu, Mar 4, 2021 at 2:18 AM Ariel Luaces <arielluaces@gmail.com> wrote:

> On Wed, Mar 3, 2021 at 12:25 PM Michael Folkson via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> > At this point in time it also appears the greatest risk to Taproot
> > dying a slow death is a small group of developers who think talking in
> > conservative tones and talking about endless philosophy makes Bitcoin
> > a conservative system. (It doesn=E2=80=99t, it just makes it a dying, d=
ecaying
> > one).
>
> The current risk to taproot and all future activations is a loud
> minority of users who are threatening to co-opt a LOT=3Dfalse activation
> by switching the parameter and organizing a marketing blitz that could
> end in a fork if things don't go well.
> As long as that threat persists consensus won't be reached. Then an
> activation client probably won't be released because I don't expect
> many devs will have an appetite for writing code that either doesn't
> have consensus or code that will be manipulated into creating
> consensus conflicts.
> I think Bitcoin is fine staying as is until that minority forks off
> with their own alt-node. If the UASF minority is dead set on creating
> the alt-node then I only hope it's released quickly so the deadlock
> can break. A quick UASF fork allows for an early LOT=3Dfalse activation.
>
> Cheers
> Ariel Lorenzo-Luaces
>
> > --
> > Michael Folkson
> > Email: 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
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>


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

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

<div dir=3D"ltr">Hi Ariel<br><br>&gt; I think Bitcoin is fine staying as is=
 until that minority forks off with their own alt-node....=C2=A0 A quick UA=
SF fork allows for an early LOT=3Dfalse activation.<br><br>I think you misu=
nderstand BIP 8 (LOT=3Dtrue). Although no timetable has been finalized as o=
f yet (and hence we are in the realm of speculation rather than facts), the=
 earliest the MUST_SIGNAL period would kick in is around July 2022. That do=
esn&#39;t sound very quick to me if you seek a LOT=3Dfalse release after a =
LOT=3Dtrue release has failed to activate.<br><br>&gt; The current risk to =
taproot and all future activations is a loud minority of users who are thre=
atening to co-opt a LOT=3Dfalse activation by switching the parameter<div><=
br></div><div>As I&#39;ve said in previous emails to this list, some people=
 are determined to ignore the discussion and (open to all) meetings of rece=
nt weeks and block progress until they find their philosopher&#39;s stone. =
They seek to ignore all the work people have done laying out the options, c=
ommunicating those options to the community and narrowing them down. Instea=
d they bring=C2=A0up alternative proposals which were discussed and rejecte=
d weeks or months ago. With this mindset we&#39;ll still be arguing about T=
aproot activation in 2030.=C2=A0</div><div><br></div><div>I get that there =
isn&#39;t overwhelming consensus on the LOT parameter, this is a fact. But =
there won&#39;t be overwhelming consensus on any activation mechanism, that=
 has become clear. I am of the view that consensus on one parameter of an a=
ctivation mechanism does not need to be as high as it is on the actual soft=
 fork that is being activated (which does have overwhelming consensus). And=
 of course if and when a LOT=3Dtrue (UASF) version is released you are abso=
lutely free not to run it. I hope (and suspect) you would reconsider if Jul=
y 2022 (or later) was approaching and it was the only way to activate Tapro=
ot.</div><div><br></div><div>Thanks</div><div>Michael</div><div><br></div><=
div><br><br></div></div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr"=
 class=3D"gmail_attr">On Thu, Mar 4, 2021 at 2:18 AM Ariel Luaces &lt;<a hr=
ef=3D"mailto:arielluaces@gmail.com">arielluaces@gmail.com</a>&gt; wrote:<br=
></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Mar 3, 202=
1 at 12:25 PM Michael Folkson via bitcoin-dev<br>
&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla=
nk">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt;<br>
&gt; At this point in time it also appears the greatest risk to Taproot<br>
&gt; dying a slow death is a small group of developers who think talking in=
<br>
&gt; conservative tones and talking about endless philosophy makes Bitcoin<=
br>
&gt; a conservative system. (It doesn=E2=80=99t, it just makes it a dying, =
decaying<br>
&gt; one).<br>
<br>
The current risk to taproot and all future activations is a loud<br>
minority of users who are threatening to co-opt a LOT=3Dfalse activation<br=
>
by switching the parameter and organizing a marketing blitz that could<br>
end in a fork if things don&#39;t go well.<br>
As long as that threat persists consensus won&#39;t be reached. Then an<br>
activation client probably won&#39;t be released because I don&#39;t expect=
<br>
many devs will have an appetite for writing code that either doesn&#39;t<br=
>
have consensus or code that will be manipulated into creating<br>
consensus conflicts.<br>
I think Bitcoin is fine staying as is until that minority forks off<br>
with their own alt-node. If the UASF minority is dead set on creating<br>
the alt-node then I only hope it&#39;s released quickly so the deadlock<br>
can break. A quick UASF fork allows for an early LOT=3Dfalse activation.<br=
>
<br>
Cheers<br>
Ariel Lorenzo-Luaces<br>
<br>
&gt; --<br>
&gt; Michael Folkson<br>
&gt; Email: <a href=3D"mailto:michaelfolkson@gmail.com" target=3D"_blank">m=
ichaelfolkson@gmail.com</a><br>
&gt; Keybase: michaelfolkson<br>
&gt; PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3<br>
&gt; _______________________________________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundation.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org=
/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"=
 class=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 dir=3D=
"ltr"><font face=3D"arial, helvetica, sans-serif" color=3D"#000000">Michael=
 Folkson</font><div><font face=3D"arial, helvetica, sans-serif" color=3D"#0=
00000">Email:=C2=A0<a href=3D"mailto:michaelfolkson@gmail.com" target=3D"_b=
lank">michaelfolkson@gmail.com</a></font></div><div><font face=3D"arial, he=
lvetica, sans-serif" color=3D"#000000">Keybase: michaelfolkson</font></div>=
<div><font face=3D"arial, helvetica, sans-serif" color=3D"#000000">PGP: 43E=
D C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3</font></div></div></div></di=
v></div></div></div></div></div></div></div>

--000000000000bc559205bcb3ca43--