(Note: I am writing this as a general case against LOT=False, but using Taproot simply as an example softfork. Note that this is addressing activation under the assumption that the softfork is ethical and has sufficient community support. If those criteria have not been met, no activation should be deployed at all, of any type.)
As we saw in 2017 with BIP 9, coordinating activation by miner signal alone, despite its potential benefits, also leaves open the door to a miner veto. This was never the intended behaviour, and a bug, which took a rushed deployment of BIP148 to address. LOT=False would reintroduce that same bug. It wouldn't be much different than adding back the inflation bug (CVE-2018-17144) and trusting miners not to exploit it.
Some have tried to spin LOT=True as some kind of punishment for miners or reactive "counter-attack". Rather, it is simply a fallback to avoid regression on this and other bugs. "Flag day" activation is not fundamentally flawed or dangerous, just slow since everyone needs time to upgrade. BIP 8(LOT=True) combines the certainty of such a flag day, with the speed improvement of a MASF, so that softforks can be activated both reasonably quick and safely.
In the normal path, and that which BIP8(True) best incentivises, miners will simply upgrade and signal, and activation can occur as soon as the economic majority is expected to have had time to upgrade. In the worst-case path, the behaviour of LOT=True is the least-harmful result: unambiguous activation and enforcement by the economy, with miners either deciding to make an anti-Taproot(eg) altcoin, or continue mining Bitcoin. Even if ALL the miners revolt against the softfork, the LOT=True nodes are simply faced with a choice to hardfork (replacing the miners with a PoW change) or concede - they do not risk vulnerability or loss.
With LOT=False in the picture, however, things can get messy: some users will enforce Taproot(eg) (those running LOT=True), while others will not (those with LOT=False). Users with LOT=True will still get all the safety thereof, but those with LOT=False will (in the event of miners deciding to produce a chain split) face an unreliable chain, being replaced by the LOT=True chain every time it overtakes the LOT=False chain in work. For 2 weeks, users with LOT=False would not have a usable network. The only way to resolve this would be to upgrade to LOT=True or to produce a softfork that makes an activated chain invalid (thereby taking the anti-Taproot path). Even if nobody ran LOT=True (very unlikely), LOT=False would still fail because users would be faced with either accepting the loss of Taproot(eg), or re-deploying from scratch with LOT=True. It accomplishes nothing compared to just deploying LOT=True from the beginning. Furthermore, this process creates a lot of confusion for users ("Yep, I upgraded for Taproot(eg). Wait, you mean I have to do it AGAIN?"), and in some scenarios additional code may be needed to handle the subsequent upgrade cleanly.
To make matters worse for LOT=False, giving miners a veto also creates an incentive to second-guess the decision to activate and/or hold the activation hostage. This is a direct result of the bug giving them a power they weren't intended to have. Even if we trust miners to act ethically, that does not justify sustaining the bug creating both a possibility and incentive to behave unethically.
So in all possible scenarios, LOT=False puts users and the network at significant risk. In all possible scenarios, LOT=True minimises risk to everyone and has no risk to users running LOT=True.
The overall risk is maximally reduced by LOT=True being the only deployed parameter, and any introduction of LOT=False only increases risk probability and severity.
For all these reasons, I regret adding LOT as an option to BIP 8, and think it would be best to remove it entirely, with all deployments in the future behaving as LOT=True. I do also recognise that there is not yet consensus on this, and for that reason I have not taken action (nor intend to) to remove LOT from BIP 8. However, the fact remains that LOT=False should not be used, and it is best if every softfork is deployed with LOT=True.
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018498.html
[link] [comments]
No comments:
Post a Comment