path: root/de/754b034fd70c4679a59a7c14084a967a2d4429

Return-Path: <eric@voskuil.org>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 941EAC0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 28 Feb 2021 20:44:14 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 6E4754300A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 28 Feb 2021 20:44:14 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level: 
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5
 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001,
 MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001,
 RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=voskuil-org.20150623.gappssmtp.com
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id xyrfG52hK8fq
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 28 Feb 2021 20:44:12 +0000 (UTC)
X-Greylist: delayed 00:16:08 by SQLgrey-1.8.0
Received: from mail-oi1-f180.google.com (mail-oi1-f180.google.com
 [209.85.167.180])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 760EA43006
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 28 Feb 2021 20:44:12 +0000 (UTC)
Received: by mail-oi1-f180.google.com with SMTP id f3so15973662oiw.13
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 28 Feb 2021 12:44:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=voskuil-org.20150623.gappssmtp.com; s=20150623;
 h=content-transfer-encoding:from:mime-version:subject:date:message-id
 :references:cc:in-reply-to:to;
 bh=tUzE2MjNEIPcbV/5LlGboThXKlcrhGIgXjHfmn+t+UU=;
 b=1dR+IeRfmR4FxGXZqpqpsKEYBYz4lWlOX95tNtFYezmtfaG6ij9E1IZAMwV9thu57a
 wm3fZTLo7D/A1hJjRBNGdosa2RX03Ucb1evuv4v0DPDouSV0yN7v6ibteb+do3kjpp4i
 O+7c8Q2ZmM7LIt3zxpK6qDiv4xF0WFMUd3+w0I+k/RuliUjPumqFbfyxOydVpbQg2Y4o
 wukX3fOuO2NPVJcwt1hpMtgk3X6q4rGPHw+98XU1WqH8zDUA/BmaIaMquCp6oBEs6VfE
 yuxCMotuurYhKGwVQmBBGS2CHMiGINyTsew37DmH6PBzwSxo6HLDvYSWN0hPUK3IorYS
 /6tg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:content-transfer-encoding:from:mime-version
 :subject:date:message-id:references:cc:in-reply-to:to;
 bh=tUzE2MjNEIPcbV/5LlGboThXKlcrhGIgXjHfmn+t+UU=;
 b=oe8LPeLffKnsuL9rxqmOzJObNhhRYkMDykxGyjSeahI5+kTy3rOcyuMREiySW4JWh8
 mVHgAQGLBPnn5+4lW/OoSBoEtY7j9Gh/1u1j1/bjMAOc2dTZ4kaQv7cwKlaWwjBK/T/e
 WrU+twOsz+FGNakKNXrdD1zccnGPz4J5HynqYZfudJZt/3RlyomoybufOv2DgvBGjyCG
 /2Hfv8CmB+FclfPblB/cxd6ALtjU+t2j2X0JgLsPdwFirjOmFjvNyY+TXDOy7abZTaKF
 1IPTlpbqN5c2C3Fz0gJ1ETxXHQkKAqilyM+OqhpcU9S6Dh0YZlcudmfyCW+rsjuCdGWC
 ypqw==
X-Gm-Message-State: AOAM530B03R98gPGfQ/JI/PlUJHITmTYU0Df37zJHut2OEk8I1ZamRSO
 THKgeXs8pf0Davc573rpE6jFAG6zH6QND6ya
X-Google-Smtp-Source: ABdhPJw6pIHVeKN53dLF+17CFTMUuH/v3BDqaOdWHz2wxtAK7Auw4INx6p4P5EuNUtI4G/xHmtKGDQ==
X-Received: by 2002:a17:90a:7061:: with SMTP id
 f88mr7881039pjk.56.1614543601057; 
 Sun, 28 Feb 2021 12:20:01 -0800 (PST)
Received: from ?IPv6:2601:600:9c00:1d0::250e? ([2601:600:9c00:1d0::250e])
 by smtp.gmail.com with ESMTPSA id g8sm16361189pfu.13.2021.02.28.12.20.00
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 28 Feb 2021 12:20:00 -0800 (PST)
Content-Type: multipart/alternative;
 boundary=Apple-Mail-87B2DF72-54E0-4890-B2C0-831DB3F95904
Content-Transfer-Encoding: 7bit
From: Eric Voskuil <eric@voskuil.org>
Mime-Version: 1.0 (1.0)
Date: Sun, 28 Feb 2021 12:19:59 -0800
Message-Id: <E083AFEC-DE1B-4ECC-BCDD-EA248E8E76DD@voskuil.org>
References: <CAD5xwhh89-5WRdnhA0X0CueWe6s2HneeEFiW5nZs4KFQw4iG6Q@mail.gmail.com>
In-Reply-To: <CAD5xwhh89-5WRdnhA0X0CueWe6s2HneeEFiW5nZs4KFQw4iG6Q@mail.gmail.com>
To: Jeremy <jlrubin@mit.edu>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
X-Mailer: iPhone Mail (18D52)
X-Mailman-Approved-At: Sun, 28 Feb 2021 21:15:45 +0000
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: Sun, 28 Feb 2021 20:44:14 -0000


--Apple-Mail-87B2DF72-54E0-4890-B2C0-831DB3F95904
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

In the attempt to change consensus rules there is a simple set of choices:

1) hard fork: creates a chain split
2) soft fork: creates a chain split
3) 51% attack: does not create a chain split

The presumption being that one can never assume 100% explicit adoption of an=
y rule change.

A 51% attack can of course fail. It is also possible that signaling can be u=
ntruthful. But miner signaling provides some level of assurance that it will=
 be successful. This level of assurance is increased by adoption of a higher=
 than majority threshold, as has been done in the past.

Most of the discussion I=E2=80=99ve seen has been focused on who is in charg=
e. Bitcoin requires no identity; anyone can mine and/or accept bitcoin - nob=
ody is in charge.

The majority of those who mine can choose to enforce censorship any time the=
y want. They don=E2=80=99t need anyone=E2=80=99s permission. No power is giv=
en to them by developers or anyone else. They have that power based on their=
 own capital invested.

Similarly, the economy (those who accept bitcoin) can enforce any rule chang=
e it wants to. And it can do so at any level of participation that wants to g=
o along. Anyone can do this, it requires nobody=E2=80=99s permission. Furthe=
rmore, it is possible for the economy to signal its level of agreement in ev=
ery transaction, as miners have done in blocks previously.

But if the objective is to produce a rule change while avoiding a chain spli=
t, 50% is a much lower bar than 100%. If there is some other objective, it=E2=
=80=99s not clear to me what it is.

e

> On Feb 28, 2021, at 12:02, Jeremy via bitcoin-dev <bitcoin-dev@lists.linux=
foundation.org> wrote:
>=20
> =EF=BB=BF
> Miners still can generate invalid blocks as a result of SPV mining, and it=
 could be profitable to do "bad block enhanced selfish mining" to take advan=
tage of it.
>=20
>=20
> Hard to analyze exactly what that looks like, but...
>=20
> E.g., suppose 20% is un-upgraded and 80% is upgraded. Taking 25% hashrate t=
o mine bad blocks would mean 1/4th of the time you could make 20% of the has=
hrate mine bad blocks, overall a > 5% (series expansion) benefit. One could a=
nalyze out that the lost hash rate for bad blocks only matters for the first=
 difficulty adjustment period you're doing this for too, as the hashrate dro=
p will be accounted for -- but then a miner can switch back to mining valid c=
hain, giving themselves a larger % of hashrate.
>=20
> So it is still possible that an un-upgraded miner will fail part 3, and at=
tempting to accommodate un-upgraded miners leads to some nasty oscillating h=
ashrate being optimal.
>=20
>=20
> --
> @JeremyRubin
>=20
>=20
>> On Sun, Feb 28, 2021 at 11:52 AM Matt Corallo <lf-lists@mattcorallo.com> w=
rote:
>> Note further that mandatory signaling isn't "just" a flag day - unlike a T=
aproot flag day (where miners running Bitcoin=20
>> Core unmodified today will not generate invalid blocks), a mandatory sign=
aling flag day blatantly ignores goal (3) from=20
>> my original post - it results in any miner who has not taken active actio=
n (and ensured every part of their often-large=20
>> infrastructure has been correctly reconfigured) generating invalid blocks=
.
>>=20
>> As for "Taproot" took too long, hey, at least if its locked in people can=
 just build things assuming it exists. Some=20
>> already are, but once its clearly locked in, there's no reason to not con=
tinue other work at the same time.
>>=20
>> Matt
>>=20
>> On 2/28/21 14:43, Jeremy via bitcoin-dev wrote:
>> > I agree with much of the logic presented by Matt here.
>> >=20
>> > BIP8 was intended to be simpler to agree on to maintain consensus, yet w=
e find ourselves in a situation where a "tiny"=20
>> > parameter has the potential to cause great network disruption and confu=
sion (rationality is not too useful a concept=20
>> > here given differing levels of sophistication and information). It is t=
herefore much simpler and more likely to be=20
>> > universally understood by all network participants to just have a flag d=
ay. It is easier to communicate what users=20
>> > should do and when.
>> >=20
>> > This is ultimately not coercive to users because the upgrade for Taproo=
t itself is provable and analyzable on its own,=20
>> > but activation parameters based on what % of economically relevant node=
s are running an upgrade by a certain date are=20
>> > not. Selecting these sorts of complicated consensus parameters may ulti=
mately present more opportunity for a cooptable=20
>> > consensus process than something more straightforward.
>> >=20
>> >=20
>> > That said, a few points strike me as worth delving into.
>> >=20
>> >=20
>> > 1) Con: Mandatory signalling is no different than a flag day. Mandatory=
 signaling is effectively 2 flag days -- one for=20
>> > the signaling rule, 1 for the taproot type. The reason for the 2 week g=
ap between flag day for signaling and flag day=20
>> > for taproot rules is, more or less, so that nodes who aren't taproot re=
ady at the 1st flag day do not end up SPV mining=20
>> > (using standardness rules in mempool prevents them from mining an inval=
id block on top of a valid tip, but does not=20
>> > ensure the tip is valid).
>> > 2) Con: Releasing a flag day without releasing the LOT=3Dtrue code lead=
ing up to that flag day means that clients would=20
>> > not be fully compatible with an early activation that could be proposed=
 before the flag day is reached. E.g., LOT=3Dtrue=20
>> > is a flag day that retains the possibility of being compatible with oth=
er BIP8 releases without changing software.
>> > 3) Pro: BIP-8 is partially in service of "early activation" and . I'm p=
ersonally skeptical that early activation is/was=20
>> > ever a good idea. A fixed activation date may be largely superior for b=
usiness purposes, software engineering schedules,=20
>> > etc. I think even with signaling BIP8, it would be possibly superior to=
 activate rules at a fixed date (or a quantized=20
>> > set of fixed dates, e.g. guaranteeing at least 3 months but maybe more)=
.
>> > 4) Pro: part of the argument for BIP-8=3Dfalse is that it is possible t=
hat the rule could not activate, if signaling does=20
>> > not occur, providing additional stopgap against dev collusion and bugs.=
 But BIP-8 can activate immediately (with start=20
>> > times being proposed 1 month after release?) so we don't have certainty=
 around how much time there is for that secondary=20
>> > review process (read -- I think it isn't that valuable) and if there *i=
s* a deadly bug discovered, we might want to=20
>> > hard-fork to fix it even if it isn't yet signaled for (e.g., if the rul=
e activates it enables more mining reward). So I=20
>> > think that it's a healthier mindset to release a with definite deadline=
 and not rule out having to do a hard fork if=20
>> > there is a grave issue (we shouldn't ever release a SF if we think this=
 is at all likely, mind you).
>> > 5) Con: It's already taken so long for taproot, the schedule around tap=
root was based on the idea it could early=20
>> > activate, 2022 is now too far away. I don't know how to defray this oth=
er than, if your preferred idea is 1 year flag=20
>> > day, to do that via LOT=3Dtrue so that taproot can still have early act=
ivation if desired.
>> >=20
>> > Overall I agree with the point that all the contention around LOT, make=
s a flag day look not so bad. And something=20
>> > closer to a flag day might not be so bad either for future forks as wel=
l.
>> >=20
>> > However, I think given the appetite for early activation, if a flag day=
 is desired I think LOT=3Dtrue is the best option=20
>> > at this time as it allows our flag day to remain compatible with such a=
n early activation.
>> >=20
>> > I think we can also clearly communicate that LOT=3Dtrue for Taproot is n=
ot a precedent setting occurence for any future=20
>> > forks (hold me accountable to not using this as precedent this should I=
 ever advocate for a SF with similar release=20
>> > parameters).
>> >=20
>> >=20
>> > _______________________________________________
>> > bitcoin-dev mailing list
>> > bitcoin-dev@lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--Apple-Mail-87B2DF72-54E0-4890-B2C0-831DB3F95904
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div dir=3D"ltr"><span style=3D"caret-color=
: rgb(0, 0, 0); color: rgb(0, 0, 0);">In the attempt to change consensus rul=
es there is a simple set of choices:</span><br style=3D"caret-color: rgb(0, 0=
, 0); color: rgb(0, 0, 0);"><span style=3D"caret-color: rgb(0, 0, 0); color:=
 rgb(0, 0, 0);"></span><br style=3D"caret-color: rgb(0, 0, 0); color: rgb(0,=
 0, 0);"><span style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">1) h=
ard fork: creates a chain split</span><br style=3D"caret-color: rgb(0, 0, 0)=
; color: rgb(0, 0, 0);"><span style=3D"caret-color: rgb(0, 0, 0); color: rgb=
(0, 0, 0);">2) soft fork: creates a chain split</span><br style=3D"caret-col=
or: rgb(0, 0, 0); color: rgb(0, 0, 0);"><span style=3D"caret-color: rgb(0, 0=
, 0); color: rgb(0, 0, 0);">3) 51% attack: does not create a chain split</sp=
an><br style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><span style=
=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"></span><br style=3D"car=
et-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><span style=3D"caret-color: rg=
b(0, 0, 0); color: rgb(0, 0, 0);">The presumption being that one can never a=
ssume 100% explicit adoption of any rule change.</span><br style=3D"caret-co=
lor: rgb(0, 0, 0); color: rgb(0, 0, 0);"><span style=3D"caret-color: rgb(0, 0=
, 0); color: rgb(0, 0, 0);"></span><br style=3D"caret-color: rgb(0, 0, 0); c=
olor: rgb(0, 0, 0);"><span style=3D"caret-color: rgb(0, 0, 0); color: rgb(0,=
 0, 0);">A 51% attack can of course fail. It is also possible that signaling=
 can be untruthful. But miner signaling provides some level of assurance tha=
t it will be successful. This level of assurance is increased by adoption of=
 a higher than majority threshold, as has been done in the past.</span><br s=
tyle=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><span style=3D"care=
t-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"></span><br style=3D"caret-color=
: rgb(0, 0, 0); color: rgb(0, 0, 0);"><span style=3D"caret-color: rgb(0, 0, 0=
); color: rgb(0, 0, 0);">Most of the discussion I=E2=80=99ve seen has been f=
ocused on who is in charge. Bitcoin requires no identity; anyone can mine an=
d/or accept bitcoin - nobody is in charge.</span><br style=3D"caret-color: r=
gb(0, 0, 0); color: rgb(0, 0, 0);"><span style=3D"caret-color: rgb(0, 0, 0);=
 color: rgb(0, 0, 0);"></span><br style=3D"caret-color: rgb(0, 0, 0); color:=
 rgb(0, 0, 0);"><span style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0=
);">The majority of those who mine can choose to enforce censorship any time=
 they want. They don=E2=80=99t need anyone=E2=80=99s permission. No power is=
 given to them by developers or anyone else. They have that power based on t=
heir own capital invested.</span><br style=3D"caret-color: rgb(0, 0, 0); col=
or: rgb(0, 0, 0);"><span style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0=
, 0);"></span><br style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">=
<span style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">Similarly, t=
he economy (those who accept bitcoin) can enforce any rule change it wants t=
o. And it can do so at any level of participation that wants to go along. An=
yone can do this, it requires nobody=E2=80=99s permission. Furthermore, it i=
s possible for the economy to signal its level of agreement in every transac=
tion, as miners have done in blocks previously.</span><br style=3D"caret-col=
or: rgb(0, 0, 0); color: rgb(0, 0, 0);"><span style=3D"caret-color: rgb(0, 0=
, 0); color: rgb(0, 0, 0);"></span><br style=3D"caret-color: rgb(0, 0, 0); c=
olor: rgb(0, 0, 0);"><span style=3D"caret-color: rgb(0, 0, 0); color: rgb(0,=
 0, 0);">But if the objective is to produce a rule change while avoiding a c=
hain split, 50% is a much lower bar than 100%. If there is some other object=
ive, it=E2=80=99s not clear to me what it is.</span></div><div dir=3D"ltr"><=
br style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><span style=3D"=
caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">e</span></div><div dir=3D"l=
tr"><br><blockquote type=3D"cite">On Feb 28, 2021, at 12:02, Jeremy via bitc=
oin-dev &lt;bitcoin-dev@lists.linuxfoundation.org&gt; wrote:<br><br></blockq=
uote></div><blockquote type=3D"cite"><div dir=3D"ltr">=EF=BB=BF<div dir=3D"l=
tr"><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-s=
erif;font-size:small;color:#000000">Miners still can generate invalid blocks=
 as a result of SPV mining, and it could be profitable to do "bad block enha=
nced selfish mining" to take advantage of it.</div><div class=3D"gmail_defau=
lt" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#0=
00000"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,hel=
vetica,sans-serif;font-size:small;color:#000000"><br></div><div class=3D"gma=
il_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;=
color:#000000">Hard to analyze exactly what that looks like, but...</div><di=
v class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;fo=
nt-size:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D=
"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">E.g.,=
 suppose 20% is un-upgraded and 80% is upgraded. Taking 25% hashrate to mine=
 bad blocks would mean 1/4th of the time you could make 20% of the hashrate m=
ine bad blocks, overall a &gt; 5% (series expansion) benefit. One could anal=
yze out that the lost hash rate for bad blocks only matters for the first di=
fficulty adjustment period you're doing this for too, as the hashrate drop w=
ill be accounted for -- but then a miner can switch back to mining valid cha=
in, giving themselves a larger % of hashrate.</div><div class=3D"gmail_defau=
lt" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#0=
00000"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,hel=
vetica,sans-serif;font-size:small;color:#000000">So it is still possible tha=
t an un-upgraded miner will fail part 3, and attempting to accommodate un-up=
graded miners leads to some nasty oscillating hashrate being optimal.<br></d=
iv><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-se=
rif;font-size:small;color:#000000"><br></div><div class=3D"gmail_default" st=
yle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"=
><br clear=3D"all"></div><div><div dir=3D"ltr" class=3D"gmail_signature" dat=
a-smartmail=3D"gmail_signature"><div dir=3D"ltr">--<br><a href=3D"https://tw=
itter.com/JeremyRubin" target=3D"_blank">@JeremyRubin</a><a href=3D"https://=
twitter.com/JeremyRubin" target=3D"_blank"></a></div></div></div><br></div><=
br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, =
Feb 28, 2021 at 11:52 AM Matt Corallo &lt;<a href=3D"mailto:lf-lists@mattcor=
allo.com">lf-lists@mattcorallo.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">Note further that mandatory signaling isn't "=
just" a flag day - unlike a Taproot flag day (where miners running Bitcoin <=
br>
Core unmodified today will not generate invalid blocks), a mandatory signali=
ng flag day blatantly ignores goal (3) from <br>
my original post - it results in any miner who has not taken active action (=
and ensured every part of their often-large <br>
infrastructure has been correctly reconfigured) generating invalid blocks.<b=
r>
<br>
As for "Taproot" took too long, hey, at least if its locked in people can ju=
st build things assuming it exists. Some <br>
already are, but once its clearly locked in, there's no reason to not contin=
ue other work at the same time.<br>
<br>
Matt<br>
<br>
On 2/28/21 14:43, Jeremy via bitcoin-dev wrote:<br>
&gt; I agree with much of the logic presented by Matt here.<br>
&gt; <br>
&gt; BIP8 was intended to be simpler to agree on to maintain consensus, yet w=
e find ourselves in a situation where a "tiny" <br>
&gt; parameter has the potential to cause great network disruption and confu=
sion (rationality is not too useful a concept <br>
&gt; here given differing levels of sophistication and information). It is t=
herefore much simpler and more likely to be <br>
&gt; universally understood by all network participants to just have a flag d=
ay. It is easier to communicate what users <br>
&gt; should do and when.<br>
&gt; <br>
&gt; This is ultimately not coercive to users because the upgrade for Taproo=
t itself is provable and analyzable on its own, <br>
&gt; but activation parameters based on what % of economically relevant node=
s are running an upgrade by a certain date are <br>
&gt; not. Selecting these sorts of complicated consensus parameters may ulti=
mately present more opportunity for a cooptable <br>
&gt; consensus process than something more straightforward.<br>
&gt; <br>
&gt; <br>
&gt; That said, a few points strike me as worth delving into.<br>
&gt; <br>
&gt; <br>
&gt; 1) Con: Mandatory signalling is no different than a flag day. Mandatory=
 signaling is effectively 2 flag days -- one for <br>
&gt; the signaling rule, 1 for the taproot type. The reason for the 2 week g=
ap between flag day for signaling and flag day <br>
&gt; for taproot rules is, more or less, so that nodes who aren't taproot re=
ady at the 1st flag day do not end up SPV mining <br>
&gt; (using standardness rules in mempool prevents them from mining an inval=
id block on top of a valid tip, but does not <br>
&gt; ensure the tip is valid).<br>
&gt; 2) Con: Releasing a flag day without releasing the LOT=3Dtrue code lead=
ing up to that flag day means that clients would <br>
&gt; not be fully compatible with an early activation that could be proposed=
 before the flag day is reached. E.g., LOT=3Dtrue <br>
&gt; is a flag day that retains the possibility of being compatible with oth=
er BIP8 releases without changing software.<br>
&gt; 3) Pro: BIP-8 is partially in service of "early activation" and . I'm p=
ersonally skeptical that early activation is/was <br>
&gt; ever a good idea. A fixed activation date may be largely superior for b=
usiness purposes, software engineering schedules, <br>
&gt; etc. I think even with signaling BIP8, it would be possibly superior to=
 activate rules at a fixed date (or a quantized <br>
&gt; set of fixed dates, e.g. guaranteeing at least 3 months but maybe more)=
.<br>
&gt; 4) Pro: part of the argument for BIP-8=3Dfalse is that it is possible t=
hat the rule could not activate, if signaling does <br>
&gt; not occur, providing additional stopgap against dev collusion and bugs.=
 But BIP-8 can activate immediately (with start <br>
&gt; times being proposed 1 month after release?) so we don't have certainty=
 around how much time there is for that secondary <br>
&gt; review process (read -- I think it isn't that valuable) and if there *i=
s* a deadly bug discovered, we might want to <br>
&gt; hard-fork to fix it even if it isn't yet signaled for (e.g., if the rul=
e activates it enables more mining reward). So I <br>
&gt; think that it's a healthier mindset to release a with definite deadline=
 and not rule out having to do a hard fork if <br>
&gt; there is a grave issue (we shouldn't ever release a SF if we think this=
 is at all likely, mind you).<br>
&gt; 5) Con: It's already taken so long for taproot, the schedule around tap=
root was based on the idea it could early <br>
&gt; activate, 2022 is now too far away. I don't know how to defray this oth=
er than, if your preferred idea is 1 year flag <br>
&gt; day, to do that via LOT=3Dtrue so that taproot can still have early act=
ivation if desired.<br>
&gt; <br>
&gt; Overall I agree with the point that all the contention around LOT, make=
s a flag day look not so bad. And something <br>
&gt; closer to a flag day might not be so bad either for future forks as wel=
l.<br>
&gt; <br>
&gt; However, I think given the appetite for early activation, if a flag day=
 is desired I think LOT=3Dtrue is the best option <br>
&gt; at this time as it allows our flag day to remain compatible with such a=
n early activation.<br>
&gt; <br>
&gt; I think we can also clearly communicate that LOT=3Dtrue for Taproot is n=
ot a precedent setting occurence for any future <br>
&gt; forks (hold me accountable to not using this as precedent this should I=
 ever advocate for a SF with similar release <br>
&gt; parameters).<br>
&gt; <br>
&gt; <br>
&gt; _______________________________________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla=
nk">bitcoin-dev@lists.linuxfoundation.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-d=
ev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/m=
ailman/listinfo/bitcoin-dev</a><br>
&gt; <br>
</blockquote></div>
<span>_______________________________________________</span><br><span>bitcoi=
n-dev mailing list</span><br><span>bitcoin-dev@lists.linuxfoundation.org</sp=
an><br><span>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<=
/span><br></div></blockquote></body></html>=

--Apple-Mail-87B2DF72-54E0-4890-B2C0-831DB3F95904--