path: root/cf/4be9e62865ab333b9bd3e4c9041e7ec8501371

Return-Path: <eric@voskuil.org>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 6CA34C0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  2 Mar 2021 20:13:51 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 4E98F60754
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  2 Mar 2021 20:13:51 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level: 
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001,
 RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001,
 SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=voskuil-org.20150623.gappssmtp.com
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 3LgU_G4LIdLD
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  2 Mar 2021 20:13:49 +0000 (UTC)
X-Greylist: delayed 00:06:31 by SQLgrey-1.8.0
Received: from mail-pg1-f182.google.com (mail-pg1-f182.google.com
 [209.85.215.182])
 by smtp3.osuosl.org (Postfix) with ESMTPS id AC20060733
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  2 Mar 2021 20:13:49 +0000 (UTC)
Received: by mail-pg1-f182.google.com with SMTP id a4so14601622pgc.11
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 02 Mar 2021 12:13:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=voskuil-org.20150623.gappssmtp.com; s=20150623;
 h=content-transfer-encoding:from:mime-version:subject:date:message-id
 :references:in-reply-to:to;
 bh=d7HiDHNgPTgwxrSIncdQK9WKfI0ix0xsS4IcK2n82u0=;
 b=zG+FQBPu5aIQKGGGg4Bz+PRybaw2nGQFaDR3Tnu6XvK6dq1+5UM5/pVOuGz+Dqqcnv
 7nF58U8xUBawULvUM5T7Fq4wwiLW1xZykOjiGaX7va8djkkcrH8uDlp2NmvUaAsUAj3O
 LpiOWvnJhyQZ6Ua1UovEBdLtuojc5jYyUIGWjGq9kNtx3GIqbtQgS2GJsAUX67GsmJ4N
 pA1kmsw2YZ2Q1TNaQPoo1vPX1EiHA40sYpNTtPZaExye8I3GEturiRrA1fG+gb+4gAdQ
 QzTdRS7/rmDYiVaxFXDu5/ywYhm9AzlGhrEsWjgwcVmO56Juytr6NUIxdA81p1gRW/Br
 V7aQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:content-transfer-encoding:from:mime-version
 :subject:date:message-id:references:in-reply-to:to;
 bh=d7HiDHNgPTgwxrSIncdQK9WKfI0ix0xsS4IcK2n82u0=;
 b=gmMhd3ELC1gzH19DzuujBwJDLTccJBBbnml01oBC8Ou0pW97039Z6neT/k9AWogmnW
 bx2ePcwh59p9HBkcS19CnZD+hMct+oq/ChboQVrUerNqPwyspcJgbeeWz9vVf3BxSwJC
 ahRVTF9ckonn9HENG6z4Ajf/dCCrYU2kbEviEAu/onjAk24TZGf2i1FPzdjynFEhqFVb
 4WidRJlPAnJopr8FNVsD9D3hmtqxHeiAZZNtwD3gu/Ywyr2BqGKDzf3Dc+EGFc3/tIve
 GnKZpL99l+Z9u6oCv8pxRMHLLEh6BVoJD0GP7mfrAQHi30Ja6UapxESuILSpnlLL+TcR
 RM0w==
X-Gm-Message-State: AOAM533Z98rvhJPzF/QSEVExm79dwQqzMe+F2A/Z21Jj3ic15Fv8/SUi
 13t8zuJSsE9BZtidKE8B0vqOEKod4LySmumS
X-Google-Smtp-Source: ABdhPJxZ/XRqTJGb5ob/YMraoxX5Gkt/XPV4lMqmA8dbQD2KhG/T3aS1zaJq2oA+IKX0xYI/uVdXTA==
X-Received: by 2002:a63:461d:: with SMTP id t29mr19382922pga.192.1614715637832; 
 Tue, 02 Mar 2021 12:07:17 -0800 (PST)
Received: from ?IPv6:2601:600:9c00:1d0::250e? ([2601:600:9c00:1d0::250e])
 by smtp.gmail.com with ESMTPSA id 16sm9002973pfx.45.2021.03.02.12.07.17
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 02 Mar 2021 12:07:17 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Eric Voskuil <eric@voskuil.org>
Mime-Version: 1.0 (1.0)
Date: Tue, 2 Mar 2021 12:07:16 -0800
Message-Id: <2944FA84-5BE6-4690-9C10-0E43A4954403@voskuil.org>
References: <c7784af1-7f69-2607-ba3a-c34f2b2fe995@riseup.net>
In-Reply-To: <c7784af1-7f69-2607-ba3a-c34f2b2fe995@riseup.net>
To: Chris Belcher <belcher@riseup.net>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
X-Mailer: iPhone Mail (18D52)
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Mar 2021 20:13:51 -0000

To clarify, it is the soft fork enforcement by majority hash power that is t=
he 51% attack, not the stopping of it. Majority hash power censors non-confo=
rming transactions. To counter it requires only a non-censoring majority to c=
ontinue mining.

It is correct that the purpose of supermajority signaling is to reduce the c=
hance of a chain split. It is misleading to call it a bug and to imply that u=
ser activation isn=E2=80=99t actually intended to create, or at least threat=
en, a chain split. It=E2=80=99s a game of chicken.

e

> On Mar 2, 2021, at 10:22, Chris Belcher via bitcoin-dev <bitcoin-dev@lists=
.linuxfoundation.org> wrote:
>=20
> =EF=BB=BFIt is wrong to say that using miner signalling alone for activati=
on
> (LOT=3Dfalse) is a bug.
>=20
> 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.
>=20
> 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.
>=20
> 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).
>=20
>=20
>=20
>=20
> Also another point: in a hypothetical chain split it's true that the
> LOT=3Dfalse chain would be vulnerable to reorgs, but it's also true that
> the LOT=3Dtrue would suffer from slow blocks.
>=20
> 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=3Dfalse 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=3Dtrue chain as safe with no downsides at all.
>=20
>=20
>=20
>=20
>> On 28/02/2021 19:33, Luke Dashjr via bitcoin-dev wrote:
>> (Note: I am writing this as a general case against LOT=3DFalse, but using=
=20
>> Taproot simply as an example softfork. Note that this is addressing=20
>> activation under the assumption that the softfork is ethical and has=20
>> sufficient community support. If those criteria have not been met, no=20
>> activation should be deployed at all, of any type.)
>>=20
>> As we saw in 2017 with BIP 9, coordinating activation by miner signal alo=
ne,=20
>> despite its potential benefits, also leaves open the door to a miner veto=
.=20
>> This was never the intended behaviour, and a bug, which took a rushed=20
>> deployment of BIP148 to address. LOT=3DFalse would reintroduce that same b=
ug.
>> It wouldn't be much different than adding back the inflation bug=20
>> (CVE-2018-17144) and trusting miners not to exploit it.
>>=20
>> Some have tried to spin LOT=3DTrue as some kind of punishment for miners o=
r=20
>> reactive "counter-attack". Rather, it is simply a fallback to avoid=20
>> regression on this and other bugs. "Flag day" activation is not fundament=
ally=20
>> flawed or dangerous, just slow since everyone needs time to upgrade.
>> BIP 8(LOT=3DTrue) combines the certainty of such a flag day, with the spe=
ed=20
>> improvement of a MASF, so that softforks can be activated both reasonably=
=20
>> quick and safely.
>>=20
>> In the normal path, and that which BIP8(True) best incentivises, miners w=
ill=20
>> simply upgrade and signal, and activation can occur as soon as the econom=
ic=20
>> majority is expected to have had time to upgrade. In the worst-case path,=
 the=20
>> behaviour of LOT=3DTrue is the least-harmful result: unambiguous activati=
on and=20
>> enforcement by the economy, with miners either deciding to make an=20
>> anti-Taproot(eg) altcoin, or continue mining Bitcoin. Even if ALL the min=
ers=20
>> revolt against the softfork, the LOT=3DTrue nodes are simply faced with a=
=20
>> choice to hardfork (replacing the miners with a PoW change) or concede - t=
hey=20
>> do not risk vulnerability or loss.
>>=20
>> With LOT=3DFalse in the picture, however, things can get messy: some user=
s will=20
>> enforce Taproot(eg) (those running LOT=3DTrue), while others will not (th=
ose=20
>> with LOT=3DFalse). Users with LOT=3DTrue will still get all the safety th=
ereof,=20
>> but those with LOT=3DFalse will (in the event of miners deciding to produ=
ce a=20
>> chain split) face an unreliable chain, being replaced by the LOT=3DTrue c=
hain=20
>> every time it overtakes the LOT=3DFalse chain in work. For 2 weeks, users=
 with=20
>> LOT=3DFalse would not have a usable network. The only way to resolve this=
 would=20
>> be to upgrade to LOT=3DTrue or to produce a softfork that makes an activa=
ted=20
>> chain invalid (thereby taking the anti-Taproot path). Even if nobody ran=20=

>> LOT=3DTrue (very unlikely), LOT=3DFalse would still fail because users wo=
uld be=20
>> faced with either accepting the loss of Taproot(eg), or re-deploying from=
=20
>> scratch with LOT=3DTrue. It accomplishes nothing compared to just deployi=
ng=20
>> LOT=3DTrue from the beginning. Furthermore, this process creates a lot of=
=20
>> confusion for users ("Yep, I upgraded for Taproot(eg). Wait, you mean I h=
ave=20
>> to do it AGAIN?"), and in some scenarios additional code may be needed to=
=20
>> handle the subsequent upgrade cleanly.
>>=20
>> To make matters worse for LOT=3DFalse, giving miners a veto also creates a=
n=20
>> incentive to second-guess the decision to activate and/or hold the activa=
tion=20
>> hostage. This is a direct result of the bug giving them a power they were=
n't=20
>> intended to have. Even if we trust miners to act ethically, that does not=
=20
>> justify sustaining the bug creating both a possibility and incentive to=20=

>> behave unethically.
>>=20
>> So in all possible scenarios, LOT=3DFalse puts users and the network at=20=

>> significant risk. In all possible scenarios, LOT=3DTrue minimises risk to=
=20
>> everyone and has no risk to users running LOT=3DTrue.
>>=20
>> The overall risk is maximally reduced by LOT=3DTrue being the only deploy=
ed=20
>> parameter, and any introduction of LOT=3DFalse only increases risk probab=
ility=20
>> and severity.
>>=20
>> For all these reasons, I regret adding LOT as an option to BIP 8, and thi=
nk it=20
>> would be best to remove it entirely, with all deployments in the future=20=

>> behaving as LOT=3DTrue. I do also recognise that there is not yet consens=
us on=20
>> this, and for that reason I have not taken action (nor intend to) to remo=
ve=20
>> LOT from BIP 8. However, the fact remains that LOT=3DFalse should not be u=
sed,=20
>> and it is best if every softfork is deployed with LOT=3DTrue.
>>=20
>> Luke
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev