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
|
Return-Path: <aj@erisian.com.au>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id E04B2C0001
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 1 Mar 2021 15:06:24 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id C7D5183D37
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 1 Mar 2021 15:06:24 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.804
X-Spam-Level:
X-Spam-Status: No, score=0.804 tagged_above=-999 required=5
tests=[BAYES_50=0.8, KHOP_HELO_FCRDNS=0.001, SPF_HELO_NONE=0.001,
SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001]
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 HyuKWWnewPA0
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 1 Mar 2021 15:06:24 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226])
by smtp1.osuosl.org (Postfix) with ESMTPS id CBF7E83365
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 1 Mar 2021 15:06:23 +0000 (UTC)
Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au)
by azure.erisian.com.au with esmtpsa (Exim 4.92 #3 (Debian))
id 1lGk7l-00010j-SZ
for <bitcoin-dev@lists.linuxfoundation.org>; Tue, 02 Mar 2021 01:06:21 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
Tue, 02 Mar 2021 01:06:14 +1000
Date: Tue, 2 Mar 2021 01:06:14 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20210301150614.vz557ssn2epxknjn@erisian.com.au>
References: <202102281933.30691.luke@dashjr.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <202102281933.30691.luke@dashjr.org>
User-Agent: NeoMutt/20170113 (1.7.2)
X-Spam-Score-int: -18
X-Spam-Bar: -
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: Mon, 01 Mar 2021 15:06:25 -0000
On Sun, Feb 28, 2021 at 07:33:30PM +0000, Luke Dashjr via bitcoin-dev wrote:
> 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.
To the contrary, we saw in 2017 that miners could *not* successfully
veto a BIP 9 activation. It was certainly more effort and risk than was
desirable to override the attempted veto, but the attempt at vetoing
nevertheless failed.
> It wouldn't be much different than adding back the inflation bug
> (CVE-2018-17144) and trusting miners not to exploit it.
That is ridiculous FUD.
> With LOT=False in the picture, however, things can get messy:
LOT=false is always in the picture if we are talking about a soft-fork:
the defining feature of a soft-fork is that old node software continues
to work, and old node software will be entirely indifferent to whether
activation is signalled or not.
> some users will
> enforce Taproot(eg) (those running LOT=True), while others will not (those
> with LOT=False)
If you are following bip8 with lockinontimeout=false, you will enforce
taproot rules if activation occurs, you will simply not reject blocks if
activation does not occur.
> 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.
This assumes anyone mining the chain where taproot does not activate is
not able to avoid a reorg, despite having majority hashpower (as implied
by the lot=true chain having to overtake them repeatedly). That's absurd;
avoiding a reorg is trivially achieved via running "invalidateblock", or
via pool software examining block headers, or via a patch along the lines
of MUST_SIGNAL enforcement, but doing the opposite. For concreteness,
here's a sketch of such a patch:
https://github.com/ajtowns/bitcoin/commit/f195688bd1eff3780f200e7a049e23b30ca4fe2f
> For 2 weeks, users with LOT=False would not have a usable network.
That's also ridiculous FUD.
If it were true, it would mean the activation mechanism was not
acceptable, as non-upgraded nodes would also not have a usable network
for the same reason.
Fortunately, it's not true.
More generally, if miners are willing to lose significant amounts of
money mining orphan blocks, they can do that at any time. If they're
not inclined to do so, it's incredibly straightforward for them to avoid
doing so, whatever a minority of other miners might do.
> 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.
LOT=false is the default behaviour of everything single piece of node
software out there. That behaviour doesn't need to be introduced, it's
already universal.
Cheers,
aj
|
