[bitcoin-dev] LOT=False is dangerous and shouldn't be used

From: Luke Dashjr <luke@dashjr•org>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: [bitcoin-dev] LOT=False is dangerous and shouldn't be used
Date: Sun, 28 Feb 2021 19:33:30 +0000	[thread overview]
Message-ID: <202102281933.30691.luke@dashjr.org> (raw)

(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.

Luke