Author: Jeremy 2021-02-28 19:43:53
Published on: 2021-02-28T19:43:53+00:00
The author of the article agrees with Matt's logic that a flag day would be simpler and more universally understood than the current BIP8 proposal, which has the potential to cause network disruption and confusion. The upgrade for Taproot itself is provable and analyzable on its own, but activation parameters based on what % of economically relevant nodes are running an upgrade by a certain date are not. The article then discusses several points both for and against the BIP8 proposal, including the argument that mandatory signaling is no different than a flag day, releasing a flag day without releasing the LOT=true code leading up to that flag day means that clients would not be fully compatible with an early activation, and the argument for BIP-8=false that the rule could not activate if signaling does not occur. The author is personally skeptical that early activation is/was ever a good idea and thinks a fixed activation date may be largely superior for business purposes, software engineering schedules, etc. Additionally, if there is a deadly bug discovered, we might want to hard-fork to fix it even if it isn't yet signaled for, so it's a healthier mindset to release a with definite deadline and not rule out having to do a hard fork if there is a grave issue. The article also acknowledges that it has already taken so long for taproot, and the schedule around taproot was based on the idea it could early activate, 2022 is now too far away. However, the author suggests that LOT=true is the best option at this time as it allows our flag day to remain compatible with such an early activation. Finally, the author agrees that all the contention around LOT makes a flag day look not so bad and something closer to a flag day might not be so bad either for future forks as well.
Updated on: 2023-06-14T18:45:02.596804+00:00