Answering the F1-F7 arguments for LOT=False... > F1) The probability of Taproot not being activated by miners is small. This > is not 2017, this is not SegWit, there is no need to worry.
While we believe miners have no reason to sabotage Taproot activation, this was also the belief leading up to Segwit’s activation in 2017, and regardless it is not desirable to create such a risk forcing the community to place extra trust in miners. Miners might very well not exploit an inflation bug, but that is no reason to purposefully add an inflation bug. > F2) The worst case scenario is we have to wait over a year for Taproot to > be activated. Even the worst case scenario is not a disaster. While it is true that a second activation can be deployed in the event of the first one failing, doing so would not necessarily change the situation unless LOT were changed to true anyway - in which case, it might as well be true for the initial deployment as well. Furthermore, a re-deployment could create a situation where users believe they have already upgraded for Taproot, but do not enforce it due to not understanding the need to upgrade yet again. > F3) If in the unlikely scenario miners did not activate Taproot for a year > for no apparent reason we would never set LOT to false again for any > potential future soft fork. If miners fail to activate Taproot despite > pledging support and there being overwhelming community consensus for it, > it would set a precedent that miners cannot be relied upon *at all* to > activate soft forks. Setting LOT=false with a threat to change it to true later is antagonistic against miners. With LOT=true, expectations are simply made clear and miners can simply cooperate by making valid blocks as they do day-to-day already. > F4) If in the highly unlikely scenario that a bug or some problem with the > Taproot implementation was found during the signaling period miners could > choose not to activate it which is cleaner than needing an emergency Core > release. The risk that a bug in Taproot is discovered this late yet before activation, to warrant aborting the deployment, is extremely low (much lower than the risks created by LOT=false). Even if such a scenario occurred, and even with LOT=false, users would still need to upgrade to back out the deployment. In the best-case scenario, users would need to upgrade to deploy the fixed Taproot. So in the end, nothing is to be gained from relying on a miner abort for such scenarios. > F5) LOT = false is more similar to what was done previously (unless you go > way back to the earliest soft forks which were more similar to LOT = true) The behaviour of LOT=false has proven problematic and caused failure of Segwit activation in 2017. LOT=true behaviour has a long history of success, and was used to resolve and activate Segwit in 2017 after LOT=false’s failure. > F6) It is more important that no rules that harm users are deployed than it > is that new useful rules are deployed quickly. If there is a choice between > “faster” and “more clear that this isn’t a mechanism to force bad things on > users” we should prefer the latter. Plenty of people just don’t like > LOT=true very much absent evidence that miners are blocking deployment. To > some it just feels needlessly antagonistic and distrusting towards part of > our community. Any deployment, or even status quo, can be falsely portrayed/spun in a way to harm Bitcoin. As such, only objective criteria should be considered. BIP 8 makes it explicitly easy for people to reject the softfork if they don't like it, so any claim of being "forced" is a non-starter to an honest person. > F7) defaulting to LOT=false makes non-activation possible even if people > run the code that developers provide, meaning a successful > activation proves that at least some people (e.g. miners or UASFers) > voluntarily took actions that were well outside the scope of > developer control. > > This makes it clear that developers don't control changes to the > system. There are other arguments that demonstrate that developers > aren't in control[1], but they aren't as clear as simply pointing > out that a rule change won't go into effect until at least several > non-developers independently act of their own accord. > > Having such a clear argument that developers aren't in control > bolsters the decentralized ethos of Bitcoin and reduces the chance > that bad actors will pressure Bitcoin developers to attempt future > unwanted changes. Even if developers release software, it must still be accepted by the community in the form of actively choosing to run the software which includes the activation. So long as the activation is clearly and prominently documented, users have taken the action to accept the protocol change. Furthermore, the community has already demonstrated a clear and undisputed support for the activation of Taproot. If there was/is any question of whether that is true or not, it is premature to be planning activation of ANY type. Luke _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev