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
163
164
165
166
167
168
169
170
171
172
173
174
175
|
Return-Path: <yanmaani@cock.li>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id B8D51C0001
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 1 Mar 2021 17:00:48 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 9F3786F5F3
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 1 Mar 2021 17:00:48 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 4.028
X-Spam-Level: ****
X-Spam-Status: No, score=4.028 tagged_above=-999 required=5
tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_BL_SPAMCOP_NET=1.347,
RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01,
RCVD_IN_RP_RNBL=1.31, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001,
SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=cock.li
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 6aDL0Dia4p5Q
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 1 Mar 2021 17:00:45 +0000 (UTC)
X-Greylist: delayed 00:06:32 by SQLgrey-1.8.0
Received: from mail.cock.li (unknown [37.120.193.123])
by smtp3.osuosl.org (Postfix) with ESMTPS id AC37060655
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 1 Mar 2021 17:00:44 +0000 (UTC)
MIME-Version: 1.0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cock.li; s=mail;
t=1614617648; bh=lkqK2nDLr12PEasotKmtagCTaThHVHdt3jEsaayZStk=;
h=Date:From:To:Subject:In-Reply-To:References:From;
b=kmahM0gkjmqa08z5XrVYcgr5zQRlAnZRSewcyWtKmmqwEtyb6DoEOWWmTBLGfvEcE
U1zSeH3CotBlKhQSc04CwUynx7GDI8le8IgbJKUu5MidAtDD/8yrYpA9h2SeL6vuXi
it0Jy+8vJaFkEGhbkKD4xOi+jCeYOLaLlk6Wn3Rm01vmugsLCal8QPiPnrEqxtw3bu
aFjl3rq/kdkoaaLUPhAq802b2IrHlnJz8ovoH9hKd242+6FIVwyqEKbfvGHsUPOUun
D6SwEkxkr0OZDuZksYWUp0Uemime52Eth9PKtAscKOFRIM0+P5A2M32AWHTEp0TVSm
MGNU0cRZx9wSw==
Content-Type: text/plain; charset=US-ASCII;
format=flowed
Content-Transfer-Encoding: 7bit
Date: Mon, 01 Mar 2021 16:54:07 +0000
From: yanmaani@cock.li
To: Anthony Towns <aj@erisian.com.au>, Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <20210301150614.vz557ssn2epxknjn@erisian.com.au>
References: <202102281933.30691.luke@dashjr.org>
<20210301150614.vz557ssn2epxknjn@erisian.com.au>
Message-ID: <86f87c6e5e4fd05c2295de2209694771@cock.li>
X-Sender: yanmaani@cock.li
User-Agent: Roundcube Webmail/1.3.15
X-Mailman-Approved-At: Mon, 01 Mar 2021 17:05:11 +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 17:00:48 -0000
How about a compromise?
With LOT=false, taproot will be activated if at least 95% of the miners
vote yes.
With LOT=true, taproot will be activated if at least 0% of the miners
vote yes.
...with LOT=maybe, taproot will be activated if at least ~some% of the
miners vote yes?
If you want the 'emergency cancel' feature without binding yourself to
it, couldn't you have some middle-of-the-road solution? "Taproot will be
enabled if miner support ever goes above 95%, or on flag day if miner
support is >20% then". That would prevent obstreperous miners from doing
too much damage, while still hopefully making it possible to bail out of
a disaster.
On 2021-03-01 15:06, 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.
>
>> 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
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
