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

From: Chris Belcher <belcher@riseup•net>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] LOT=False is dangerous and shouldn't be used
Date: Tue, 2 Mar 2021 18:21:59 +0000	[thread overview]
Message-ID: <c7784af1-7f69-2607-ba3a-c34f2b2fe995@riseup.net> (raw)
In-Reply-To: <202102281933.30691.luke@dashjr.org>

It is wrong to say that using miner signalling alone for activation
(LOT=false) is a bug.

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

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. Both chains suffer if a chain split happens which is why they
are pretty important to avoid. That's why its inaccurate to portray
LOT=true chain as safe with no downsides at all.

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
> 