Re: [bitcoin-dev] MASF=true + LOT=informational

[Erik Aronesty <erik@q32.com>]

And of course:

1) MASF=true + LOT=eventually 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=true, 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/pipermail/bitcoin-dev/2021-March/018555.html and motivation to find consensus on incrementally improving Bitcoin soft-fork activation mechanisms.  (TL;DR Consensus is important for the activation mechanism as there are more soft-forks that Bitcoin will need.  We need to incrementally improve activation mechanisms.  It could become critical that Bitcoin prevails in achieving a future upgrade even against powerful interests.)
>
> These activation configurations have been discussed with rationales.
>
> 1) MASF=true + LOT=false
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
>
> Try LOT=false first, with a potential to change to LOT=true if pools and miners were to unreasonably delay MASF activation.  (By later deploying a revised activation mechanism with LOT=true or other.)
>
> Arguments against have included a major concern about perpetuating the risk demonstrated by the BIP 141 / BIP 9 with potential for misuse and misunderstanding 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 about developer control, and being considered and incremental in starting with a safe conservative approach https://old.reddit.com/r/Bitcoin/comments/lcjhl6/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 configuration, changes the risk calculation for LOT=false.  So that LOT=false may not be safer in practice, and does not wash reference client developers hands of contributing to the combined risk.
>
> 2) MASF=true + LOT=true
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018545.html
>
> Arguments in favor, inverse of above.  But if LOT=true is a hidden flag in bitcoin reference code, or released by another project, then misinterpretation 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=true gains traction?  With explicit communication of this intent and reason for initial non-inclusion.
>
> There were also concerns about offending miners.  This concern seems dubious to many, given pools indicated ~90% support https://taprootactivation.com/ 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 category 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 dramatic and the signaling direction against should be reserved for the low probability outcome.
>
> 3) MASF=false + LOT=informational
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018495.html
>
> No miner activation.  This is interesting in using the non-standardness part of schnorr to activate at a flag height without normative signaling in version bits.  But the combined removal in this proposal of (normative signaled) 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=true) in protest.  It is true that schnorr requires wallet work, but that overlooks the philosophical nature of the rejection of unneeded delay and empirical evidence shows rather conclusively that ecosystem players are predominantly selectively lazy and only work on Bitcoin infrastructure upgrades after the fact.
>
> Subsequent posts on the thread with this proposal discuss that informational 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 to argue against: more information is better.
>
> 4) MASF=true + LOT=informational
>
> From the above it would be interesting to see discussion of a combination of MASF=true (same mechanism as 1 or 2) with LOT=informational (mechanism from 3).  Where, again, informational means signaling is provided but in an optional and informational sense, that is not normative for consensus code, but to inform the ecosystem about a hashrate verified opt-in assertion of readiness from pools.  In some way that could be more reliable in signaling 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 event that activation were unreasonably delayed, forced miner signaling from 2) could be argued to be less reliable as the mechanism for signaling on pools has no automated link to fullnode software version.  In the MASF delay eventuality, where the flag height is relied upon, users and services would be 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