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

[Emil Pfeffer <emu@emuadmin.com>]

On Tue, Mar 02, 2021 at 06:21:59PM +0000, Chris Belcher via bitcoin-dev wrote:
> It is wrong to say that using miner signalling alone for activation
> (LOT=false) is a bug.

That depends on the definition you choose to work with but since the community
had to produce a fix that implies something was broken so we can call it a
bug in a broad sense.

> 
> As we vividly saw in the events of the 2017 UASF, the purpose of miner
> signalling isn't to activate or enforce the new rules but to stop a
> chain split. A majority of miners can stop a chain split by essentially
> doing a 51% attack. Such attacks have been known about since day one,
> and even the whitepaper writes about them.
> 
> So they are not a bug but an inherent part of the way bitcoin works. If
> fixing this issue was a simple as setting a consensus rule parameter
> then bitcoin would have been invented decades earlier than it was.
> 
> And certainly miner signalling cannot be compared to an inflation bug.

Certainly and neither did the OP.

> The inflation rules are enforced by the economy using full nodes, but
> chain splits or lack of them is enforced by miners. They are two
> different parts of the bitcoin system. Back in 2010 there was an
> inflation bug CVE-2010-5139 (the "Value overflow incident") which proves
> my point. Even though miners created a block which printed 184 billion
> bitcoins, the economy quickly adopted a patch which fixed the bug and
> miners switched over to the correct chain which soon overtook the bugged
> chain (there was a reorg of 53 blocks).
> 
> 
> 
> 
> Also another point: in a hypothetical chain split it's true that the
> LOT=false chain would be vulnerable to reorgs, but it's also true that
> the LOT=true would suffer from slow blocks.

That is true but this would happen for both chains and cannot be used
to put either one of them in a better light.

> 
> So for example, imagine trading bitcoin for cash in person, but instead
> of waiting on average 10 minutes for a confirmation you have to wait 2
> hours. Imagine depositing coins to an exchange which requires 3
> confirmation, then instead of waiting ~30 minutes you have to actually
> wait 6 hours. This is a significant degradation in usability. 

> The situation is a mirror image of how the LOT=false chain is vulnerable to
> reorgs.

No, the LOT=false chain is also vulnerable to this and reorgs.

> Both chains suffer if a chain split happens which is why they
> are pretty important to avoid.

That's correct however that is worst case scenario and it can happen regardless
of which lot bitcoin ships with.

> That's why its inaccurate to portray LOT=true chain as safe 
> with no downsides at all.

It was not, it was portrayed as safer which holds true.

> 
> 
> On 28/02/2021 19:33, Luke Dashjr via bitcoin-dev wrote:
> > (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
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--