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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
