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
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
|
Return-Path: <eric@voskuil.org>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id D4682C0001
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Feb 2021 20:45:49 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id C31684300A
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Feb 2021 20:45:49 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.002
X-Spam-Level:
X-Spam-Status: No, score=0.002 tagged_above=-999 required=5
tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001,
RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=voskuil-org.20150623.gappssmtp.com
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 eI8Ww57pdF_s
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Feb 2021 20:45:48 +0000 (UTC)
X-Greylist: delayed 00:07:34 by SQLgrey-1.8.0
Received: from mail-pf1-f179.google.com (mail-pf1-f179.google.com
[209.85.210.179])
by smtp2.osuosl.org (Postfix) with ESMTPS id 98AE143006
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Feb 2021 20:45:48 +0000 (UTC)
Received: by mail-pf1-f179.google.com with SMTP id d12so7579093pfo.7
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Feb 2021 12:45:48 -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:cc:in-reply-to:to;
bh=2ipnH/H8biZlde67aT6GUyuvWu7nVFnRtGqhZWR5rYQ=;
b=YUYX02l5Gh1Mj4gTAUgtDNYB3HWaRmE2vFushAHARfU6fOtxEn7iZT15ViYAl0x9PU
1zkXt5AnlKg9v177tDsv7xPakZcbtf1fWq6U8M4J3Sd/7BuQnBivoz0Lsph2WGSOAM67
uDWK8Fbz+R6s+ifNnDL4VpwEFl22cLDD2fewix8/2Zi3G+68eiuf3t68B7f5234g4qfj
DQcsx8jyugF0sRVy1v0dBGRlamAtSu1Osi9HHgUQEkNriTLxkw7+x6dF/+OelJj1L15P
rx566G2izQ09JQ00LCmxkLZPlzBJj40QsHMxdHKhtzl6McFv3mfzQa5PM/fYsvV+PnF/
pxeg==
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:cc:in-reply-to:to;
bh=2ipnH/H8biZlde67aT6GUyuvWu7nVFnRtGqhZWR5rYQ=;
b=p+VwjV3+/j9U1yOlU6BqOZRsjyq/9zFbvbcW0Jj3FP/lMbxHvdbara5enCkxgqIDhf
PcnIqX6At/ijrnUDnnGr1yI80EdMzSBPZ51X2Ai/Dc9ikmwBcmDcCvsov1lu5cGiSQC2
ai1+9UKL65psdhQbgeTKiXTtjFYf+M1Fjm1xHmM2es4AHRZE96b5RiLRMAkblBZlm8wQ
r1LgZ8KIM5DoIWO3ciT+VcmBCeLcbHhnYwN1RtMxNWvRJzkXR2bLL3p4+4/pk/eiKLMP
yj3mvfdrMVwH74p0tR2tzwQkpMaFuoKU/Y+lAWoF4VboC+lsn07tV8P91TtdgMZGyrEN
15uw==
X-Gm-Message-State: AOAM533A95ZOcGqDNkG7+h8nfIVTOBJdOqwnn5r8iJmf1qnMsbmhD8+P
Tfh1JpkrQFHG7T57GwMS/B2xs6LZCaRzzWkD
X-Google-Smtp-Source: ABdhPJylDBsiUyH1hlAUDy0UpZHOsNGomw0KZG4BkuC7OplYE7hLU7sz8tSuxRxKJqVwGnWVuaH41A==
X-Received: by 2002:a63:fa4d:: with SMTP id g13mr10947981pgk.201.1614544693939;
Sun, 28 Feb 2021 12:38:13 -0800 (PST)
Received: from ?IPv6:2601:600:9c00:1d0::250e? ([2601:600:9c00:1d0::250e])
by smtp.gmail.com with ESMTPSA id m18sm16142248pfd.206.2021.02.28.12.38.13
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Sun, 28 Feb 2021 12:38:13 -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: Sun, 28 Feb 2021 12:38:13 -0800
Message-Id: <DB47E953-AAEF-4550-B60E-8530F3477A39@voskuil.org>
References: <0adb87b0-0e05-2ccc-77e1-1de689b45739@mattcorallo.com>
In-Reply-To: <0adb87b0-0e05-2ccc-77e1-1de689b45739@mattcorallo.com>
To: Matt Corallo <lf-lists@mattcorallo.com>
X-Mailer: iPhone Mail (18D52)
X-Mailman-Approved-At: Sun, 28 Feb 2021 21:15:45 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation
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 20:45:49 -0000
I think it has been shown that an understanding of reasonableness is not uni=
versal, making any assertion about it as a collective goal kind of self-defe=
ating. The question is what is achievable, not what is reasonable. I=E2=80=99=
m not making any value judgements here. Simply pointing out that anything ot=
her than a successful 51% attack will create a split.
e
> On Feb 28, 2021, at 12:25, Matt Corallo <lf-lists@mattcorallo.com> wrote:
>=20
> =EF=BB=BFGlad you asked! Yes, your goal here is #4 on the list of goals I l=
aid out at [1], which I referenced and specifically addressed each of in the=
OP of this thread.
>=20
> [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/0=
17547.html
>=20
>> On 2/28/21 15:19, Eric Voskuil wrote:
>> In the attempt to change consensus rules there is a simple set of choices=
:
>> 1) hard fork: creates a chain split
>> 2) soft fork: creates a chain split
>> 3) 51% attack: does not create a chain split
>> The presumption being that one can never assume 100% explicit adoption of=
any rule change.
>> A 51% attack can of course fail. It is also possible that signaling can b=
e untruthful. But miner signaling provides some level of assurance that it w=
ill be successful. This level of assurance is increased by adoption of a hig=
her than majority threshold, as has been done in the past.
>> Most of the discussion I=E2=80=99ve seen has been focused on who is in ch=
arge. Bitcoin requires no identity; anyone can mine and/or accept bitcoin - n=
obody is in charge.
>> The majority of those who mine can choose to enforce censorship any time t=
hey want. They don=E2=80=99t need anyone=E2=80=99s permission. No power is g=
iven to them by developers or anyone else. They have that power based on the=
ir own capital invested.
>> Similarly, the economy (those who accept bitcoin) can enforce any rule ch=
ange it wants to. And it can do so at any level of participation that wants t=
o go along. Anyone can do this, it requires nobody=E2=80=99s permission. Fur=
thermore, it is possible for the economy to signal its level of agreement in=
every transaction, as miners have done in blocks previously.
>> But if the objective is to produce a rule change while avoiding a chain s=
plit, 50% is a much lower bar than 100%. If there is some other objective, i=
t=E2=80=99s not clear to me what it is.
>> e
>>>> On Feb 28, 2021, at 12:02, Jeremy via bitcoin-dev <bitcoin-dev@lists.li=
nuxfoundation.org> wrote:
>>>=20
>>> =EF=BB=BF
>>> Miners still can generate invalid blocks as a result of SPV mining, and i=
t could be profitable to do "bad block enhanced selfish mining" to take adva=
ntage of it.
>>>=20
>>>=20
>>> Hard to analyze exactly what that looks like, but...
>>>=20
>>> E.g., suppose 20% is un-upgraded and 80% is upgraded. Taking 25% hashrat=
e to mine bad blocks would mean 1/4th of the time you could make 20% of the h=
ashrate mine bad blocks, overall a > 5% (series expansion) benefit. One coul=
d analyze out that the lost hash rate for bad blocks only matters for the fi=
rst difficulty adjustment period you're doing this for too, as the hashrate d=
rop will be accounted for -- but then a miner can switch back to mining vali=
d chain, giving themselves a larger % of hashrate.
>>>=20
>>> So it is still possible that an un-upgraded miner will fail part 3, and a=
ttempting to accommodate un-upgraded miners leads to some nasty oscillating h=
ashrate being optimal.
>>>=20
>>>=20
>>> --
>>> @JeremyRubin <https://twitter.com/JeremyRubin><https://twitter.com/Jerem=
yRubin>
>>>=20
>>>=20
>>>> On Sun, Feb 28, 2021 at 11:52 AM Matt Corallo <lf-lists@mattcorallo.com=
<mailto:lf-lists@mattcorallo.com>> wrote:
>>>=20
>>> Note further that mandatory signaling isn't "just" a flag day - unlik=
e a Taproot flag day (where miners running
>>> Bitcoin
>>> Core unmodified today will not generate invalid blocks), a mandatory s=
ignaling flag day blatantly ignores goal (3)
>>> from
>>> my original post - it results in any miner who has not taken active a=
ction (and ensured every part of their
>>> often-large
>>> infrastructure has been correctly reconfigured) generating invalid bl=
ocks.
>>>=20
>>> As for "Taproot" took too long, hey, at least if its locked in people=
can just build things assuming it exists. Some
>>> already are, but once its clearly locked in, there's no reason to not=
continue other work at the same time.
>>>=20
>>> Matt
>>>=20
>>>> On 2/28/21 14:43, Jeremy via bitcoin-dev wrote:
>>> > I agree with much of the logic presented by Matt here.
>>> >
>>> > BIP8 was intended to be simpler to agree on to maintain consensus, y=
et we find ourselves in a situation where a
>>> "tiny"
>>> > parameter has the potential to cause great network disruption and c=
onfusion (rationality is not too useful a
>>> concept
>>> > here given differing levels of sophistication and information). It i=
s therefore much simpler and more likely to be
>>> > universally understood by all network participants to just have a f=
lag day. It is easier to communicate what users
>>> > should do and when.
>>> >
>>> > This is ultimately not coercive to users because the upgrade for Ta=
proot itself is provable and analyzable on
>>> its own,
>>> > but activation parameters based on what % of economically relevant n=
odes are running an upgrade by a certain
>>> date are
>>> > not. Selecting these sorts of complicated consensus parameters may u=
ltimately present more opportunity for a
>>> cooptable
>>> > consensus process than something more straightforward.
>>> >
>>> >
>>> > That said, a few points strike me as worth delving into.
>>> >
>>> >
>>> > 1) Con: Mandatory signalling is no different than a flag day. Manda=
tory signaling is effectively 2 flag days --
>>> one for
>>> > the signaling rule, 1 for the taproot type. The reason for the 2 we=
ek gap between flag day for signaling and
>>> flag day
>>> > for taproot rules is, more or less, so that nodes who aren't taproo=
t ready at the 1st flag day do not end up SPV
>>> mining
>>> > (using standardness rules in mempool prevents them from mining an i=
nvalid block on top of a valid tip, but does not
>>> > ensure the tip is valid).
>>> > 2) Con: Releasing a flag day without releasing the LOT=3Dtrue code l=
eading up to that flag day means that clients
>>> would
>>> > not be fully compatible with an early activation that could be prop=
osed before the flag day is reached. E.g.,
>>> LOT=3Dtrue
>>> > is a flag day that retains the possibility of being compatible with=
other BIP8 releases without changing software.
>>> > 3) Pro: BIP-8 is partially in service of "early activation" and . I=
'm personally skeptical that early activation
>>> is/was
>>> > ever a good idea. A fixed activation date may be largely superior f=
or business purposes, software engineering
>>> schedules,
>>> > etc. I think even with signaling BIP8, it would be possibly superio=
r to activate rules at a fixed date (or a
>>> quantized
>>> > set of fixed dates, e.g. guaranteeing at least 3 months but maybe m=
ore).
>>> > 4) Pro: part of the argument for BIP-8=3Dfalse is that it is possib=
le that the rule could not activate, if
>>> signaling does
>>> > not occur, providing additional stopgap against dev collusion and b=
ugs. But BIP-8 can activate immediately (with
>>> start
>>> > times being proposed 1 month after release?) so we don't have certa=
inty around how much time there is for that
>>> secondary
>>> > review process (read -- I think it isn't that valuable) and if ther=
e *is* a deadly bug discovered, we might want to
>>> > hard-fork to fix it even if it isn't yet signaled for (e.g., if the=
rule activates it enables more mining
>>> reward). So I
>>> > think that it's a healthier mindset to release a with definite dead=
line and not rule out having to do a hard
>>> fork if
>>> > there is a grave issue (we shouldn't ever release a SF if we think t=
his is at all likely, mind you).
>>> > 5) Con: It's already taken so long for taproot, the schedule around=
taproot was based on the idea it could early
>>> > activate, 2022 is now too far away. I don't know how to defray this=
other than, if your preferred idea is 1 year
>>> flag
>>> > day, to do that via LOT=3Dtrue so that taproot can still have early=
activation if desired.
>>> >
>>> > Overall I agree with the point that all the contention around LOT, m=
akes a flag day look not so bad. And something
>>> > closer to a flag day might not be so bad either for future forks as=
well.
>>> >
>>> > However, I think given the appetite for early activation, if a flag=
day is desired I think LOT=3Dtrue is the best
>>> option
>>> > at this time as it allows our flag day to remain compatible with su=
ch an early activation.
>>> >
>>> > I think we can also clearly communicate that LOT=3Dtrue for Taproot=
is not a precedent setting occurence for any
>>> future
>>> > forks (hold me accountable to not using this as precedent this shou=
ld I ever advocate for a SF with similar release
>>> > parameters).
>>> >
>>> >
>>> > _______________________________________________
>>> > bitcoin-dev mailing list
>>> > bitcoin-dev@lists.linuxfoundation.org <mailto:bitcoin-dev@lists.lin=
uxfoundation.org>
>>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>> <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
|
