1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
|
Return-Path: <luke@dashjr.org>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 53FDDC0001
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Feb 2021 19:33:52 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 36B6142FF2
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Feb 2021 19:33:52 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.201
X-Spam-Level:
X-Spam-Status: No, score=-0.201 tagged_above=-999 required=5
tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,
DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
dkim=pass (1024-bit key) header.d=dashjr.org
Received: from smtp2.osuosl.org ([127.0.0.1])
by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 0vuunwremEM6
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Feb 2021 19:33:51 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21])
by smtp2.osuosl.org (Postfix) with ESMTP id 5524142FEF
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Feb 2021 19:33:51 +0000 (UTC)
Received: from ishibashi.lan (unknown [12.190.236.214])
(Authenticated sender: luke-jr)
by zinan.dashjr.org (Postfix) with ESMTPSA id DC50038A00A5
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Feb 2021 19:33:48 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dashjr.org; s=zinan;
t=1614540829; bh=gzx0A/WoW1nSzDr+6R6AyoaAiN4Fjqq0xobF2wqW2lQ=;
h=From:To:Subject:Date;
b=BWMn8f32Ni56L8YZnitUIjUpBWGz3mjXKFcKHSFEfflOJ/2gLtANbI500k2ZjaAxT
G+T4Fof5rNEZtTROHhCwAK2GpuZpHpvV0nhI1GxKLHTGsjBxbNEpE6y9qHdzgsE87V
U2oN8Pybszzv2qfJa4US8qTBtZlmPxWCS3as42CU=
From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-dev@lists.linuxfoundation.org
Date: Sun, 28 Feb 2021 19:33:30 +0000
User-Agent: KMail/1.9.10
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <202102281933.30691.luke@dashjr.org>
Subject: [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: Sun, 28 Feb 2021 19:33:52 -0000
(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
|
