MIME-Version: 1.0
References: <CAJXtxWmwtmGSA5zG0bWmNi0=ZRMZ=kZKr3SpzBr_dQcDrRhsqA@mail.gmail.com>
In-Reply-To: <CAJXtxWmwtmGSA5zG0bWmNi0=ZRMZ=kZKr3SpzBr_dQcDrRhsqA@mail.gmail.com>
From: Erik Aronesty <erik@q32.com>
Date: Thu, 4 Mar 2021 13:40:18 -0500
Message-ID: <CAJowKg+Bs7HyrOH8ANs3nXxQ5mtmRnfHrHoRNL=hfOm+JTSuQA@mail.gmail.com>
To: John Rand <johnqrand@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] MASF=true + LOT=informational
Precedence: list

And of course:

1) MASF=3Dtrue + LOT=3Deventually true

Using a declining activation threshold over time gives miners control
only over the timing of activation, not the eventuality.   This is
essentially the same as LOT=3Dtrue, however, it has a greater chance of
activation without requiring intervening releases or changes to the
code.

On Thu, Mar 4, 2021 at 1:15 PM John Rand via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> With reference to considerations https://lists.linuxfoundation.org/piperm=
ail/bitcoin-dev/2021-March/018555.html and motivation to find consensus on =
incrementally improving Bitcoin soft-fork activation mechanisms.  (TL;DR Co=
nsensus is important for the activation mechanism as there are more soft-fo=
rks that Bitcoin will need.  We need to incrementally improve activation me=
chanisms.  It could become critical that Bitcoin prevails in achieving a fu=
ture upgrade even against powerful interests.)
>
> These activation configurations have been discussed with rationales.
>
> 1) MASF=3Dtrue + LOT=3Dfalse
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018=
380.html
>
> Try LOT=3Dfalse first, with a potential to change to LOT=3Dtrue if pools =
and miners were to unreasonably delay MASF activation.  (By later deploying=
 a revised activation mechanism with LOT=3Dtrue or other.)
>
> Arguments against have included a major concern about perpetuating the ri=
sk demonstrated by the BIP 141 / BIP 9 with potential for misuse and misund=
erstanding of a normative mechanism as a political veto.  Such veto can be =
overridden by the market, but the forced need to do so increases drama and =
risk.
>
> Arguments in favor include being defensive to avoid misinterpretation abo=
ut developer control, and being considered and incremental in starting with=
 a safe conservative approach https://old.reddit.com/r/Bitcoin/comments/lcj=
hl6/taproot_activation_pools_will_be_able_to_veto/gm2l02w/
>
> Though it should be acknowledged and taken into account that disagreement=
 and potential for partly incompatible clients with different activation co=
nfiguration, changes the risk calculation for LOT=3Dfalse.  So that LOT=3Df=
alse may not be safer in practice, and does not wash reference client devel=
opers hands of contributing to the combined risk.
>
> 2) MASF=3Dtrue + LOT=3Dtrue
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018545=
.html
>
> Arguments in favor, inverse of above.  But if LOT=3Dtrue is a hidden flag=
 in bitcoin reference code, or released by another project, then misinterpr=
etation of developer control is avoided.
>
> Would there be consensus for the reference implementation doing nothing, =
and signal intent to follow the market if a non-contentious LOT=3Dtrue gain=
s traction?  With explicit communication of this intent and reason for init=
ial non-inclusion.
>
> There were also concerns about offending miners.  This concern seems dubi=
ous to many, given pools indicated ~90% support https://taprootactivation.c=
om/ and are less detail oriented.  But also BIP 148/ BIP 91 sequence events=
 was enormously dangerous and worth minor social cohesion to avoid as a cat=
egory of risk.
>
> Against the realism of developer control, if there were a market need to =
reject a soft-fork, that can also be done with a UASF.  But UASF is dramati=
c and the signaling direction against should be reserved for the low probab=
ility outcome.
>
> 3) MASF=3Dfalse + LOT=3Dinformational
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018=
495.html
>
> No miner activation.  This is interesting in using the non-standardness p=
art of schnorr to activate at a flag height without normative signaling in =
version bits.  But the combined removal in this proposal of (normative sign=
aled) MASF is problematic for the needless delay it creates.
>
> It seems probable that the delay itself would motivate users to switch to=
 clients with MASF+UASF (LOT=3Dtrue) in protest.  It is true that schnorr r=
equires wallet work, but that overlooks the philosophical nature of the rej=
ection of unneeded delay and empirical evidence shows rather conclusively t=
hat ecosystem players are predominantly selectively lazy and only work on B=
itcoin infrastructure upgrades after the fact.
>
> Subsequent posts on the thread with this proposal discuss that informatio=
nal signaling be substituted so that users and the market can benefit from =
the information about miner intent.  As it is non-normative it seems hard t=
o argue against: more information is better.
>
> 4) MASF=3Dtrue + LOT=3Dinformational
>
> From the above it would be interesting to see discussion of a combination=
 of MASF=3Dtrue (same mechanism as 1 or 2) with LOT=3Dinformational (mechan=
ism from 3).  Where, again, informational means signaling is provided but i=
n an optional and informational sense, that is not normative for consensus =
code, but to inform the ecosystem about a hashrate verified opt-in assertio=
n of readiness from pools.  In some way that could be more reliable in sign=
aling a willing readiness rather than a UASF under duress mandatory signal.
>
> Consider also with 2 or 4) alike (or 1 after switching to 2), in the even=
t that activation were unreasonably delayed, forced miner signaling from 2)=
 could be argued to be less reliable as the mechanism for signaling on pool=
s has no automated link to fullnode software version.  In the MASF delay ev=
entuality, where the flag height is relied upon, users and services would b=
e well advised to ensure they are running schnorr validating fullnodes, and=
 for SPV users to verify their wallet relies on schnorr upgraded fullnodes.
>
> John R
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev