path: root/fc/5dcedb28354faead90e976fdf886a73fe56413

Return-Path: <jtimon@jtimon.cc>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 15FF3C0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  8 Mar 2021 12:52:07 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id F2FC96074F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  8 Mar 2021 12:52:06 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.803
X-Spam-Level: 
X-Spam-Status: No, score=0.803 tagged_above=-999 required=5
 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=jtimon-cc.20150623.gappssmtp.com
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 j1WTGiDwio_y
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  8 Mar 2021 12:52:05 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-oo1-xc2d.google.com (mail-oo1-xc2d.google.com
 [IPv6:2607:f8b0:4864:20::c2d])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 2DAFE6064C
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  8 Mar 2021 12:52:05 +0000 (UTC)
Received: by mail-oo1-xc2d.google.com with SMTP id p6so2157234oot.2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 08 Mar 2021 04:52:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=jtimon-cc.20150623.gappssmtp.com; s=20150623;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=GTv9emXUYI42bMjXAI+PFK8yx8SrImGEU9WJyx7kRTk=;
 b=eveRapoQVCbkNPoppQlq2C/SThcLHWP3jLA6SEf2kK6eJ0+95hQhEfKJP6kU1ApyNV
 ZkwEF+yjjTRYdWK8b6hwr5vWQClRFWrVYsBZ1RhxNRCCfiRF8edY723/QbL+jcRLNfSm
 zYFlJeoz45qhPT8AovzG2sKEkLBXlsrTOWMc8WQFVUbOODkxzwwSXqex6k+qHkH/KW14
 RXlD64cwRX2h4SL6MTQLbqTUeMbVsgvpFF8fBaHyemmCJwLeDZF+t+xLdOW6DcF2xjzW
 JWBG1DQbBAR2qXRsMvTsxJCdlX6FlGNl2FWJDOQvxaC+IQHyyUrPhI8Bf4JfURLZtt6Y
 MjNQ==
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=GTv9emXUYI42bMjXAI+PFK8yx8SrImGEU9WJyx7kRTk=;
 b=tU0PY5h10YWu2NA5o4hdYNH1TRdhxLCQPWqJGUorDiKt0SIzdZYx6d7ObPXF7d0LLp
 SF1WjAZIk72HkZG6YC8+Inkgde0GjhlL6tGXLtwhxFAMeOpwk6Y2cQlrw5IfJwHT16YW
 78+TSc3TuTolv4poO8xcAHh9ENXvP/hQszbvyNw1B1vlBEbfnyMCNBf989L4J2A4CENr
 QQ96Udl0eMFK9bKHZLbnmIBHBlJ25oSPpntBoR9hDbx8i3wpKnAPHmz8JLRkUBxWCp2b
 WIvscm1avnGtglcDBRD7XO9NIcGUsmwnINOiTaT1gbyc2DmhInbLQ5azOEd54+aoW4gi
 xiLw==
X-Gm-Message-State: AOAM532SloUXZOajXXCHixEg+HGwaPYykmBHwJivCtGHulVOCHhmUHh6
 r4z51mIj8oZvZaM76s4b3oNHNxA6JENdBYdBAsh4zmQPkUU=
X-Google-Smtp-Source: ABdhPJy+KkSzttJoDLoAfoCspFUS0Ll5Ym48f27dCM9rNqtokf/yuqi/MZaFltU7IqV6DJG+8wwrLk3vryAZx/eCFC4=
X-Received: by 2002:a4a:420d:: with SMTP id h13mr18375515ooj.24.1615207924124; 
 Mon, 08 Mar 2021 04:52:04 -0800 (PST)
MIME-Version: 1.0
References: <c35e1761-43ca-e157-6a5c-72d27f2c6c6e@mattcorallo.com>
 <20210303145902.cl4mzg6l7avjboil@erisian.com.au>
 <281679eb-860b-c6cb-7e7a-5ae28b60f149@mattcorallo.com>
 <20210306113326.mrftlkmmloy2dsag@erisian.com.au>
In-Reply-To: <20210306113326.mrftlkmmloy2dsag@erisian.com.au>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Date: Mon, 8 Mar 2021 13:51:50 +0100
Message-ID: <CABm2gDpky7W-e_Vp5bFZ-k+y40-wFsNZ_-Cj-JNxi7PjTB2nxQ@mail.gmail.com>
To: Anthony Towns <aj@erisian.com.au>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000008e5f2d05bd05e611"
Subject: Re: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation
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: Mon, 08 Mar 2021 12:52:07 -0000

--0000000000008e5f2d05bd05e611
Content-Type: text/plain; charset="UTF-8"

Concept nack.
This has no advantage over bip8(true).
Bip9(false) is just bip9.
Thr only reasonable argument against bip8(true) is "some people may do
bip8(false) instead", which is a stypid argument applyable to any
activation method.

People against taproot should want code to forbid its activation rather
than limiting themselves to suport bip9/bip8(false) and hope it doesn't get
activated it.

Some other arguments seem to be based on the wrong assumption that miners
should decide the rules.

Thisproposal solves nothing, just adds to the noise and thus is really
disappointing.


On Sat, Mar 6, 2021, 12:33 Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Wed, Mar 03, 2021 at 11:49:57AM -0500, Matt Corallo wrote:
> > On 3/3/21 09:59, Anthony Towns wrote:
> > > A couple of days ago I would have disagreed with this; but with Luke
> > > now strongly pushing against implementing lot=false, I can at least see
> > > your point...
> > Right. It may be the case that the minority group threatening to fork off
> > onto a lot=true chain is not large enough to give a second thought to.
> > However, I'm not certain that its worth the risk, and, as Chris noted in
> his
> > post this morning, that approach is likely to include more drama.
>
> I think there's two different interpretations of what a "user-activated
> fork" means:
>
>  1) if people try to take bitcoin in a direction that risks destroying
>     it, it's possible to ignore both devs and hashpower entirely and force
>     a chain split to ensure it's possible to continue transacting with
>     "the real bitcoin".
>
>  2) removing miners' influence over consensus rules entirely -- so that
>     not only can users overcome miner objections by risking a chain split,
>     but so that miners don't have any greater ability to object than
>     anyone else in the ecosystem.
>
> In my opinion, bip8's optional lockinontimeout setting and must-signal
> approach is well-designed for case 1; if miners object for good reasons,
> then there is no need to override them (if there's a good reason not to do
> something, it shouldn't be done!), while still having the possibility to
> override them if they object for bad reasons. Because hashpower disagrees,
> there's always a risk of a chain split in that case, so the additional
> risk introduced by a signalling requirement is pretty minimal. That the
> lockinontimeout value is a setting means it can be switched only when
> we're sure there aren't good reasons for the objection.
>
> There is a lot of work to be done to make bitcoind have an acceptable
> chance of gracefully *surviving* a network split introduced by this sort
> of conflict; but provided no one started setting lockinontimeout=true
> until we were six or so months into an activation attempt (and hence
> had the opportunity to judge whether the reasons for not activating
> were bad), that would likely be enough time to start implementing some
> safety mechanisms.
>
> But there seems to be much more signficant support for the case 2 than I
> expected; as evidenced by the "let's do lockinontimeout=true immediately"
> advocacy, eg:
>
>   I am not willing to go to war for Taproot. I'll be honest the reason
>   I'm interested at all is that devs I respect spent a lot of energy and
>   time on it and I was reluctant to let their marginally beneficial work
>   go to waste.
>
>   I am, however, willing to go to war against LOT=False.
>
>    -- https://twitter.com/francispouliot_/status/1363876292169465856
>
> I don't think bip8 is well-designed for that approach: most importantly,
> with early adoption of lockinontimeout=true, bip8 *encourages* a consensus
> split in the event that good reasons for not activating are discovered
> afterwards, because lockinontimeout=false nodes remain able to abandon
> the activation attempt. Consensus splits are terrible; they should be
> a last resort used only in the event that bitcoin's fundamental nature
> is threatened, not a standard risk if bugs happened to be discovered
> late. But additionally, if we are worried miners might not be acting
> in the interests of all bitcoin users, there are other games they could
> play, such as "if you want X activated quickly, also give us Y; otherwise
> we'll delay it as long as possible".
>
> Losing the opportunity to abandon an activation attempt, by whatever
> mechanism, also puts a lot more pressure on being absolutely sure of the
> desirability of the change at the point when it's merged; because miners,
> third-party devs, businesses, and users don't even have the option of
> attempting to influence miners, all objections needs to be raised when
> the activation parameters are merged, which raises the stakes for that
> event substantially.
>
> I think my conclusions from that are:
>
>  * as it stands, people are expecting to run bip8/lot=true nodes on the
>    network immediately; so deploying bip8/lot=false with compatible
>    parameters risks causing consensus splits, and should not be done
>
>  * David Harding's "speedy trial" approach probably doesn't suffer from
>    the problems -- running a lot=true variant would require enforcing
>    signalling prior to the end of July, which is an unreasonable timeframe
>    to expect the majority of economic nodes to upgrade in; if bip9 is
>    used, then the risk of enforcement occuring with minority hashrate
>    (and thus having fewer retarget periods before the timeout is
>    reached) would also make a bip148/lot=true variant difficulty
>
>  * if people want a "taproot is guaranteed to activate no later than X"
>    PR merged, someone needs to do a *lot* more outreach to be sure that
>    that's the right outcome, and it's not just devs/maintainers making
>    the call
>
>  * IMO, Matt's proposed approach is both a better and simpler approach
>    to avoid giving miners undue influence on consensus; as such I've
>    drafted up a sample implementation:
>
>      https://github.com/bitcoin/bitcoin/pull/21378
>
>    (Backporting it to 0.21 just requires backporting #19438, which is
>    straightforward)
>
> So I think that means my preference is to do the "speedy trial" with
> signalling first, and if that fails, then either we've established there
> are real problems with taproot and will go back to the drawing board to
> fix them, or if we have not found problems by that time we should simply
> switch to a straight flag day activation as Matt proposes. Presumably
> we'll have established broard community consensus for activation if no
> objections are discovered during the speedy trial.
>
> Cheers,
> aj
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"auto">Concept nack.<div dir=3D"auto">This has no advantage over=
 bip8(true).</div><div dir=3D"auto">Bip9(false) is just bip9.</div><div dir=
=3D"auto">Thr only reasonable argument against bip8(true) is &quot;some peo=
ple may do bip8(false) instead&quot;, which is a stypid argument applyable =
to any activation method.</div><div dir=3D"auto"><br></div><div dir=3D"auto=
">People against taproot should want code to forbid its activation rather t=
han limiting themselves to suport bip9/bip8(false) and hope it doesn&#39;t =
get activated it.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Some o=
ther arguments seem to be based on the wrong assumption that miners should =
decide the rules.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Thispr=
oposal solves nothing, just adds to the noise and thus is really disappoint=
ing.</div><div dir=3D"auto"><br></div></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Sat, Mar 6, 2021, 12:33 Anthony To=
wns via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation=
.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex">On Wed, Mar 03, 2021 at 11:49:57AM -0500, Matt Cora=
llo wrote:<br>
&gt; On 3/3/21 09:59, Anthony Towns wrote:<br>
&gt; &gt; A couple of days ago I would have disagreed with this; but with L=
uke<br>
&gt; &gt; now strongly pushing against implementing lot=3Dfalse, I can at l=
east see<br>
&gt; &gt; your point...<br>
&gt; Right. It may be the case that the minority group threatening to fork =
off<br>
&gt; onto a lot=3Dtrue chain is not large enough to give a second thought t=
o.<br>
&gt; However, I&#39;m not certain that its worth the risk, and, as Chris no=
ted in his<br>
&gt; post this morning, that approach is likely to include more drama.<br>
<br>
I think there&#39;s two different interpretations of what a &quot;user-acti=
vated<br>
fork&quot; means:<br>
<br>
=C2=A01) if people try to take bitcoin in a direction that risks destroying=
<br>
=C2=A0 =C2=A0 it, it&#39;s possible to ignore both devs and hashpower entir=
ely and force<br>
=C2=A0 =C2=A0 a chain split to ensure it&#39;s possible to continue transac=
ting with<br>
=C2=A0 =C2=A0 &quot;the real bitcoin&quot;.<br>
<br>
=C2=A02) removing miners&#39; influence over consensus rules entirely -- so=
 that<br>
=C2=A0 =C2=A0 not only can users overcome miner objections by risking a cha=
in split,<br>
=C2=A0 =C2=A0 but so that miners don&#39;t have any greater ability to obje=
ct than<br>
=C2=A0 =C2=A0 anyone else in the ecosystem.<br>
<br>
In my opinion, bip8&#39;s optional lockinontimeout setting and must-signal<=
br>
approach is well-designed for case 1; if miners object for good reasons,<br=
>
then there is no need to override them (if there&#39;s a good reason not to=
 do<br>
something, it shouldn&#39;t be done!), while still having the possibility t=
o<br>
override them if they object for bad reasons. Because hashpower disagrees,<=
br>
there&#39;s always a risk of a chain split in that case, so the additional<=
br>
risk introduced by a signalling requirement is pretty minimal. That the<br>
lockinontimeout value is a setting means it can be switched only when<br>
we&#39;re sure there aren&#39;t good reasons for the objection.<br>
<br>
There is a lot of work to be done to make bitcoind have an acceptable<br>
chance of gracefully *surviving* a network split introduced by this sort<br=
>
of conflict; but provided no one started setting lockinontimeout=3Dtrue<br>
until we were six or so months into an activation attempt (and hence<br>
had the opportunity to judge whether the reasons for not activating<br>
were bad), that would likely be enough time to start implementing some<br>
safety mechanisms.<br>
<br>
But there seems to be much more signficant support for the case 2 than I<br=
>
expected; as evidenced by the &quot;let&#39;s do lockinontimeout=3Dtrue imm=
ediately&quot;<br>
advocacy, eg:<br>
<br>
=C2=A0 I am not willing to go to war for Taproot. I&#39;ll be honest the re=
ason<br>
=C2=A0 I&#39;m interested at all is that devs I respect spent a lot of ener=
gy and<br>
=C2=A0 time on it and I was reluctant to let their marginally beneficial wo=
rk<br>
=C2=A0 go to waste.<br>
<br>
=C2=A0 I am, however, willing to go to war against LOT=3DFalse.<br>
<br>
=C2=A0 =C2=A0-- <a href=3D"https://twitter.com/francispouliot_/status/13638=
76292169465856" rel=3D"noreferrer noreferrer" target=3D"_blank">https://twi=
tter.com/francispouliot_/status/1363876292169465856</a><br>
<br>
I don&#39;t think bip8 is well-designed for that approach: most importantly=
,<br>
with early adoption of lockinontimeout=3Dtrue, bip8 *encourages* a consensu=
s<br>
split in the event that good reasons for not activating are discovered<br>
afterwards, because lockinontimeout=3Dfalse nodes remain able to abandon<br=
>
the activation attempt. Consensus splits are terrible; they should be<br>
a last resort used only in the event that bitcoin&#39;s fundamental nature<=
br>
is threatened, not a standard risk if bugs happened to be discovered<br>
late. But additionally, if we are worried miners might not be acting<br>
in the interests of all bitcoin users, there are other games they could<br>
play, such as &quot;if you want X activated quickly, also give us Y; otherw=
ise<br>
we&#39;ll delay it as long as possible&quot;.<br>
<br>
Losing the opportunity to abandon an activation attempt, by whatever<br>
mechanism, also puts a lot more pressure on being absolutely sure of the<br=
>
desirability of the change at the point when it&#39;s merged; because miner=
s,<br>
third-party devs, businesses, and users don&#39;t even have the option of<b=
r>
attempting to influence miners, all objections needs to be raised when<br>
the activation parameters are merged, which raises the stakes for that<br>
event substantially.<br>
<br>
I think my conclusions from that are:<br>
<br>
=C2=A0* as it stands, people are expecting to run bip8/lot=3Dtrue nodes on =
the<br>
=C2=A0 =C2=A0network immediately; so deploying bip8/lot=3Dfalse with compat=
ible<br>
=C2=A0 =C2=A0parameters risks causing consensus splits, and should not be d=
one<br>
<br>
=C2=A0* David Harding&#39;s &quot;speedy trial&quot; approach probably does=
n&#39;t suffer from<br>
=C2=A0 =C2=A0the problems -- running a lot=3Dtrue variant would require enf=
orcing<br>
=C2=A0 =C2=A0signalling prior to the end of July, which is an unreasonable =
timeframe<br>
=C2=A0 =C2=A0to expect the majority of economic nodes to upgrade in; if bip=
9 is<br>
=C2=A0 =C2=A0used, then the risk of enforcement occuring with minority hash=
rate<br>
=C2=A0 =C2=A0(and thus having fewer retarget periods before the timeout is<=
br>
=C2=A0 =C2=A0reached) would also make a bip148/lot=3Dtrue variant difficult=
y<br>
<br>
=C2=A0* if people want a &quot;taproot is guaranteed to activate no later t=
han X&quot;<br>
=C2=A0 =C2=A0PR merged, someone needs to do a *lot* more outreach to be sur=
e that<br>
=C2=A0 =C2=A0that&#39;s the right outcome, and it&#39;s not just devs/maint=
ainers making<br>
=C2=A0 =C2=A0the call<br>
<br>
=C2=A0* IMO, Matt&#39;s proposed approach is both a better and simpler appr=
oach<br>
=C2=A0 =C2=A0to avoid giving miners undue influence on consensus; as such I=
&#39;ve<br>
=C2=A0 =C2=A0drafted up a sample implementation:<br>
<br>
=C2=A0 =C2=A0 =C2=A0<a href=3D"https://github.com/bitcoin/bitcoin/pull/2137=
8" rel=3D"noreferrer noreferrer" target=3D"_blank">https://github.com/bitco=
in/bitcoin/pull/21378</a><br>
<br>
=C2=A0 =C2=A0(Backporting it to 0.21 just requires backporting #19438, whic=
h is<br>
=C2=A0 =C2=A0straightforward)<br>
<br>
So I think that means my preference is to do the &quot;speedy trial&quot; w=
ith<br>
signalling first, and if that fails, then either we&#39;ve established ther=
e<br>
are real problems with taproot and will go back to the drawing board to<br>
fix them, or if we have not found problems by that time we should simply<br=
>
switch to a straight flag day activation as Matt proposes. Presumably<br>
we&#39;ll have established broard community consensus for activation if no<=
br>
objections are discovered during the speedy trial.<br>
<br>
Cheers,<br>
aj<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--0000000000008e5f2d05bd05e611--