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
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
|
Return-Path: <emu@emuadmin.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 7A3BAC0001
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 1 Mar 2021 18:02:47 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 74FD76F649
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 1 Mar 2021 18:02:47 +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 smtp3.osuosl.org ([127.0.0.1])
by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id epfzle0KYVui
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 1 Mar 2021 18:02:46 +0000 (UTC)
X-Greylist: delayed 00:09:50 by SQLgrey-1.8.0
Received: from mail.emuadmin.com (mail.emuadmin.com [108.61.189.74])
by smtp3.osuosl.org (Postfix) with ESMTPS id 0561A606F1
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 1 Mar 2021 18:02:45 +0000 (UTC)
Received: by mail.emuadmin.com (Postfix, from userid 1001)
id 171A97590E; Mon, 1 Mar 2021 17:52:54 +0000 (UTC)
Date: Mon, 1 Mar 2021 17:52:54 +0000
From: Emil Pfeffer <emu@emuadmin.com>
To: Anthony Towns via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20210301175254.qjuz6vjppgkzcti7@www01.emuadmin.com>
References: <202102281933.30691.luke@dashjr.org>
<20210301150614.vz557ssn2epxknjn@erisian.com.au>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20210301150614.vz557ssn2epxknjn@erisian.com.au>
X-Mailman-Approved-At: Mon, 01 Mar 2021 22:06:15 +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 <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 18:02:47 -0000
On Tue, Mar 02, 2021 at 01:06:14AM +1000, Anthony Towns via bitcoin-dev wrote:
> 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.
You cannot prove a statement to be false by making another statement.
>
> > 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.
That is an analogy not FUD. A strong one nevertheless but still an analogy.
>
> > 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.
>
That is the correct description of how soft-forks should work in principle.
> > 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.
Also correct in principle.
> > 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
If lot=true has majority of hashpower it wins.
Having to overtake them repeatedly assumes a 50/50 split one chain taking
over the other repeatedly.
In which case OP's statement that the LOT=True chain is safer holds true.
>
> > For 2 weeks, users with LOT=False would not have a usable network.
>
> That's also ridiculous FUD.
In context thats not FUD and most certainly it's not ridiculous FUD.
Assuming a 50/50 hashpower split the Lot=False chain has no stability
till difficulty re-adjustment.
>
> 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.
In the split scenario non-upgraded nodes don't play, right? aka they're part of
both chains.
>
> 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.
Except that when incentives change so does miner behavior.
>
> > 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.
You are again making an "in principle" statement.
>
> Cheers,
> aj
If you meant this to be a rebuttal, it is not.
It is mostly blanket statements and attacking OP.
--
|
