Author: Keagan McClelland 2021-02-23 19:33:11
Published on: 2021-02-23T19:33:11+00:00
The discussion revolves around finding a consensus on LOT (Locktime Optimization Technology) value, which is deemed more important than the actual value itself. Those who oppose LOT=true do so because they view it as unnecessarily coercive and fear it could lead to a chain split. However, if there is no opposition to Taproot, then by definition, there is consensus. Therefore, LOT=true or false in that regard has no meaningful precedent, as precedents are only meaningful when established during contentious scenarios. LOT=false does less to prevent a chain split, while LOT=true always exists as a possibility, with multiple high-profile individuals saying they will run it regardless of how things turn out. If a soft fork was a consensus action to blacklist some UTXOs or something else that weaponizes consensus against some subset of Bitcoin's user base, there may be good reasons to force that minority to fork themselves off the network.If social consensus drives technical consensus and not the other way around, there cannot exist a valid reason to oppose Taproot itself. Therefore, LOT=true seems to be the logical conclusion of all of this, even if Core ships LOT=false at the outset. Jeremy argues that LOT=true presents fewer issues for majority consensus than LOT=false, and the safer parameter to release seems to be LOT=true. However, devs are sensitive to control narratives, and hence LOT=false is preferred despite being a less safe option. The emotional dynamic among developers around LOT=true is that they wish it did not exist because it creates issues. Nonetheless, the risk of forking is low given the probability of activating before the timeout, and picking something and moving on, accepting that no precedent has been set by which all future forks should abide, is recommended.
Updated on: 2023-06-14T17:56:26.099934+00:00