Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id E859AC0001 for ; Wed, 3 Mar 2021 16:27:28 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id CFF43843D9 for ; Wed, 3 Mar 2021 16:27:28 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: 0.811 X-Spam-Level: X-Spam-Status: No, score=0.811 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bii5NBy4ZFCr for ; Wed, 3 Mar 2021 16:27:27 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from mail.emuadmin.com (mail.emuadmin.com [108.61.189.74]) by smtp1.osuosl.org (Postfix) with ESMTPS id 4960A843D3 for ; Wed, 3 Mar 2021 16:27:27 +0000 (UTC) Received: by mail.emuadmin.com (Postfix, from userid 1001) id CF78175923; Wed, 3 Mar 2021 16:27:24 +0000 (UTC) Date: Wed, 3 Mar 2021 16:27:24 +0000 From: Emil Pfeffer To: Chris Belcher via bitcoin-dev Message-ID: <20210303162724.vt5kienze5gbqyzp@www01.emuadmin.com> References: <202102281933.30691.luke@dashjr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Mailman-Approved-At: Wed, 03 Mar 2021 17:50:41 +0000 Subject: Re: [bitcoin-dev] LOT=False is dangerous and shouldn't be used X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2021 16:27:29 -0000 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 --