Author: John Rand 2021-03-04 14:25:41
Published on: 2021-03-04T14:25:41+00:00
The Bitcoin community is discussing activation configurations for soft forks. There are concerns about the risk of perpetuating a normative mechanism as a political veto, which could be overridden by the market but increases drama and risk. The activation mechanisms have been discussed with rationales, including MASF=true + LOT=false, MASF=true + LOT=true, MASF=false + LOT=informational, and MASF=true + LOT=informational. The community is considering starting with a safe conservative approach to avoid misinterpretation about developer control and being incremental in their improvements. However, disagreement and potential for partly incompatible clients with different activation configuration changes the risk calculation for LOT=false. Therefore, LOT=false may not be safer in practice, and it does not wash reference client developers' hands of contributing to the combined risk.There were also concerns about offending miners, but pools indicated ~90% support and are less detail-oriented. 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. The community is discussing using the non-standardness part of schnorr to activate at a flag height without normative signaling in version bits. It seems probable that the delay itself would motivate users to switch to clients with MASF+UASF (LOT=true) in protest.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. In some way that could be more reliable in signaling a willing readiness rather than a UASF under duress mandatory signal. The community is discussing different combinations of MASF and LOT, considering reliability and informing the ecosystem about a hashrate verified opt-in assertion of readiness from pools. 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. Users and services would be well advised to ensure they are running schnorr validating full-nodes, and for SPV users to verify their wallet relies on schnorr upgraded full-nodes.
Updated on: 2023-05-21T01:39:57.129523+00:00