Author: Anthony Towns 2021-03-01 15:06:14
Published on: 2021-03-01T15:06:14+00:00
In a discussion on Bitcoin-dev, Luke Dashjr expressed concerns about the risks associated with relying solely on miner signaling to coordinate activation of protocol upgrades. However, another contributor pointed out that in 2017, miners were unable to successfully veto a BIP9 activation. The conversation then turned to the potential messiness of introducing the Lock In On Timeout (LOT) parameter in the context of a soft-fork like Taproot. Those running LOT=True would enforce Taproot rules, while those with LOT=False would not reject blocks if activation did not occur. If miners produced a chain split, users with LOT=False could face an unreliable chain, being replaced every time the LOT=True chain overtook it in work. However, this assumes that miners cannot avoid a reorg, which is easily achieved via running "invalidateblock" or examining block headers. While some argue that LOT=True should be the only deployed parameter to reduce risk, this ignores the fact that LOT=false is already the default behavior for all node software.
Updated on: 2023-05-21T01:33:15.280428+00:00