Author: Luke Dashjr 2021-02-28 19:33:30
Published on: 2021-02-28T19:33:30+00:00
In the context of a general case against LOT=False, Luke argues that activating softforks through miner signal alone leaves open the door to a miner veto. He sees LOT=True as a fallback to avoid regression on bugs and believes it combines the certainty of a flag day with the speed improvement of a MASF. If miners decide to produce a chain split, users with LOT=True will still get all the safety thereof, but those with LOT=False will face an unreliable chain, being replaced by the LOT=True chain every time it overtakes the LOT=False chain in work. Luke argues that giving miners a veto creates an incentive to second-guess the decision to activate and/or hold the activation hostage, which is a direct result of the bug giving them power they weren't intended to have. In all possible scenarios, LOT=False puts users and the network at significant risk. On the other hand, LOT=True minimizes risk to everyone and has no risk to users running LOT=True.He believes that introducing LOT=False only increases the probability and severity of risk, so he regrets adding it as an option to BIP 8. He thinks it would be better to remove it entirely, with all deployments in the future behaving as LOT=True. However, Luke recognizes that there is not yet consensus on this issue, so he has not taken any action to remove LOT from BIP 8.
Updated on: 2023-06-14T18:49:33.615236+00:00