Published on: 2021-03-04T18:40:18+00:00
The Bitcoin community is currently engaged in discussions regarding the activation configurations for soft forks. The developers are seeking ways to improve the mechanisms for activating these forks. Four activation configurations have been proposed and analyzed, each with its own rationale.The first configuration involves setting MASF (Miner Activated Soft Fork) to true and LOT (Lock-in on Timeout) to false. This approach is considered a safe and conservative option. However, it also perpetuates the risk demonstrated by BIP 141/BIP9.The second configuration is the inverse of the first, with MASF set to true and LOT set to true. The third configuration suggests setting MASF to false and LOT to informational. This configuration utilizes the non-standardness part of schnorr to activate at a flag height without normative signaling in version bits. However, it introduces needless delays.The fourth configuration combines MASF set to true (similar to the first or second configuration) with LOT set to informational (as in the third configuration). This configuration provides signaling in an optional and informational sense that is not normative for consensus code. It informs the ecosystem about hashrate-verified opt-in assertion of readiness from pools.Using a declining activation threshold over time grants miners control over the timing of activation, rather than leaving it to chance. This approach is similar to LOT set to true, but with a higher likelihood of activation without requiring intervening releases or changes to the code.There were concerns raised about offending miners, but given that pools indicated approximately 90% support, this concern seems dubious to many. Additionally, if there were a market need to reject a soft-fork, that could also be done with a UASF (User Activated Soft Fork).Disagreements and the potential for partly incompatible clients with different activation configurations change the risk calculation for LOT set to false. Therefore, LOT set to false may not be safer in practice, and it does not absolve reference client developers from contributing to the combined risk.To avoid misinterpretation of developer control, if LOT set to true were a hidden flag in bitcoin reference code or released by another project, it would prevent any misunderstandings about control. Further discussions on the thread propose substituting informational signaling instead, which would allow users and the market to benefit from information about miner intent. This approach may be more reliable in signaling a willing readiness rather than a UASF under duress mandatory signal.The community is actively considering different combinations of MASF and LOT, taking into account reliability and informing the ecosystem about hashrate-verified opt-in assertions of readiness from pools. In the event that activation is unreasonably delayed, forced miner signaling could be argued to be less reliable, as the mechanism for signaling on pools lacks an automated link to fullnode software versions.Users and services are advised to ensure they are running schnorr validating full-nodes, and SPV (Simplified Payment Verification) users should verify that their wallets rely on schnorr upgraded full-nodes. These measures will help ensure the smooth implementation of the proposed activation configurations for soft forks in the Bitcoin network.
Updated on: 2023-08-02T03:21:06.811628+00:00