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
|
Return-Path: <hampus.sjoberg@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id CB3A5ACD
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 5 Jul 2017 19:44:29 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f182.google.com (mail-qk0-f182.google.com
[209.85.220.182])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D40CE19B
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 5 Jul 2017 19:44:28 +0000 (UTC)
Received: by mail-qk0-f182.google.com with SMTP id 16so198846705qkg.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 05 Jul 2017 12:44:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=b5pRlPEk4WIa2TeVlexQORXMdqfx6a8VeZuDfnFujS8=;
b=L98TazfLYxIi3if7BYz0t/aCNB6woz8PoiLdIiMXA+f6VC6fHMz1rkQQUtB1l3VjkA
GUeK3ssUkxz2iicDlyLuX82Dd8ShKxVVh+7mrHisu9KJaahzkvMmXvxXnabZuQJcpBjU
csGREYOCKOTq5C+BY4JGa4GO4LdgMQrjcZJIRWdFtdD447BeMfyTkT3TWhHwtGAL1jCF
MrCxUm6WprkLWBzKzSvKy5uh3I3ffjL91S0hl2NK9AWuGZWlh/e6nFXrdMd9xT1C+g50
oimNAxxx+cTGBpzfvWkhnlM/oLhnEZqCVZX1km6uSxQAwWV8VyaACJ7JhTOQyhkz7McG
aylA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc;
bh=b5pRlPEk4WIa2TeVlexQORXMdqfx6a8VeZuDfnFujS8=;
b=WI+9qtxZQgUPMIW9U9aT3wG2o/sbU8ertfQCufoqlEejTsPqvp+D65IQdCu2RklB7x
RJlyDpGmvM1irx10ZemKbPW+yzCaEsOf/xMY5aGdSLmWxt2aDvpdnTaMePrW5bO2nFuW
F5L/spMFzp+tAHtkV37lThJ8SllXhdieztNXTa/X44fQhYrbkzmCTCTpiT1otkxtLWOG
XClR+UHWzkgC7Zcjbnjg/ggWaU6UF/ABWwH3dah5O/Ielati13fTfDxubmwMXYr2alJN
4PwUEZX5d1sDHT9vssSitBp/NCjm3rdbywwLRRS/SSUx6KuncnSBAqsTPy/obkOLsUIy
sWwg==
X-Gm-Message-State: AKS2vOzzuSpig31I+hsZlnaNnIbj9YMRG6uvwiZSZOs+lZB30Myf2FUs
J7Kdr3kncmChBhvY1VB24153eLzjvg==
X-Received: by 10.55.160.196 with SMTP id j187mr52449253qke.145.1499283868043;
Wed, 05 Jul 2017 12:44:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.12.186.175 with HTTP; Wed, 5 Jul 2017 12:44:27 -0700 (PDT)
In-Reply-To: <201707050410.45217.luke@dashjr.org>
References: <KXL-Ie0q1dKTlbQ2XCyTRCzoQLND-Q7M9CFvYTfhjgeiZ4K3knpetQSwwLviO6whuHXQnFPg-rg8q1xW8w5mNnYFxalvx5_9Vci63lC9ju4=@protonmail.ch>
<201707050350.53122.luke@dashjr.org>
<00qcLaDJFDoC9D6644P_aLf7_n5B1pqCPj_c02QlqySsrJLsB6TZipXMD8L7l3lJcw5NoLP6dphCMruKJCIMkJUIDYbIw0iDd322vsNFmNw=@protonmail.ch>
<201707050410.45217.luke@dashjr.org>
From: =?UTF-8?Q?Hampus_Sj=C3=B6berg?= <hampus.sjoberg@gmail.com>
Date: Wed, 5 Jul 2017 21:44:27 +0200
Message-ID: <CAFMkqK9ezq_AdOpeA08jpr9haHP_jEHaJaQ2KZC=yMy6UXaJyA@mail.gmail.com>
To: Luke Dashjr <luke@dashjr.org>
Content-Type: multipart/alternative; boundary="001a114fcfd65f51d60553973ac8"
X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE,
RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: "bitcoin-dev@lists.linuxfoundation.org"
<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Height based vs block time based thresholds
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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: Wed, 05 Jul 2017 19:44:29 -0000
--001a114fcfd65f51d60553973ac8
Content-Type: text/plain; charset="UTF-8"
From the PR change:
> Miners must continue setting the bit in LOCKED_IN phase so uptake is
visible and acknowledged. Blocks without the applicable bit set are invalid
during this period
Luke, it seems like the amendments to BIP8 make it drastically different to
how it first was designed to work.
It now looks more akin to BIP148, which was AFAICT not how BIP8 was
originally intended to work.
Perhaps this should be made into its own BIP instead, or make it so it's
possible to decide how the LOCKED_IN state should work when designing the
softfork.
Hampus
2017-07-05 6:10 GMT+02:00 Luke Dashjr via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org>:
> It's not pointless: it's a wake-up call for miners asleep "at the wheel",
> to
> ensure they upgrade in time. Not having a mandatory signal turned out to
> be a
> serious bug in BIP 9, and one which is fixed in BIP 148 (and remains a
> problem
> for BIP 149 as-is). Additionally, it makes the activation decisive and
> unambiguous: once the lock-in period is complete, there remains no
> question as
> to what the correct protocol rules are.
>
> It also enables deploying softforks as a MASF, and only upgrading them to
> UASF
> on an as-needed basis.
>
> Luke
>
>
> On Wednesday 05 July 2017 4:00:38 AM shaolinfry wrote:
> > Luke,
> > I previously explored an extra state to require signalling before
> > activation in an earlier draft of BIP8, but the overall impression I got
> > was that gratuitous orphaning was undesirable, so I dropped it. I
> > understand the motivation behind it (to ensure miners are upgraded), but
> > it's also rather pointless when miners can just fake signal. A properly
> > constructed soft fork is generally such that miners have to deliberately
> > do something invalid - they cannot be tricked into it... and miners can
> > always chose to do something invalid anyway.
> >
> > > -------- Original Message --------
> > > From: luke@dashjr.org
> > > To: bitcoin-dev@lists.linuxfoundation.org, shaolinfry
> > > <shaolinfry@protonmail.ch> I"ve already opened a PR almost 2 weeks ago
> > > to do this and fix the other issues BIP 9 has.
> > > https://github.com/bitcoin/bips/pull/550
> > > It just needs your ACK to merge.
> > >
> > > On Wednesday 05 July 2017 1:30:26 AM shaolinfry via bitcoin-dev wrote:
> > >> Some people have criticized BIP9"s blocktime based thresholds arguing
> > >> they are confusing (the first retarget after threshold). It is also
> > >> vulnerable to miners fiddling with timestamps in a way that could
> > >> prevent or delay activation - for example by only advancing the block
> > >> timestamp by 1 second you would never meet the threshold (although
> this
> > >> would come a the penalty of hiking the difficulty dramatically). On
> the
> > >> other hand, the exact date of a height based thresholds is hard to
> > >> predict a long time in advance due to difficulty fluctuations.
> However,
> > >> there is certainty at a given block height and it"s easy to monitor.
> If
> > >> there is sufficient interest, I would be happy to amend BIP8 to be
> > >> height based. I originally omitted height based thresholds in the
> > >> interests of simplicity of review - but now that the proposal has been
> > >> widely reviewed it would be a trivial amendment.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--001a114fcfd65f51d60553973ac8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div>From the PR change:<br><br>> Miners must=
continue setting the bit in LOCKED_IN phase so uptake is visible and ackno=
wledged.
Blocks without the applicable bit set are invalid during this period<br><br=
></div>Luke, it seems like the amendments to BIP8 make it drastically diffe=
rent to how it first was designed to work.<br>It now looks more akin to BIP=
148, which was AFAICT not how BIP8 was originally intended to work.<br></di=
v>Perhaps this should be made into its own BIP instead, or make it so it=
9;s possible to decide how the LOCKED_IN state should work when designing t=
he softfork.<br><br></div>Hampus<br></div><div class=3D"gmail_extra"><br><d=
iv class=3D"gmail_quote">2017-07-05 6:10 GMT+02:00 Luke Dashjr via bitcoin-=
dev <span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundati=
on.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></sp=
an>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex">It's not pointless: it's a w=
ake-up call for miners asleep "at the wheel", to<br>
ensure they upgrade in time. Not having a mandatory signal turned out to be=
a<br>
serious bug in BIP 9, and one which is fixed in BIP 148 (and remains a prob=
lem<br>
for BIP 149 as-is). Additionally, it makes the activation decisive and<br>
unambiguous: once the lock-in period is complete, there remains no question=
as<br>
to what the correct protocol rules are.<br>
<br>
It also enables deploying softforks as a MASF, and only upgrading them to U=
ASF<br>
on an as-needed basis.<br>
<br>
Luke<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
On Wednesday 05 July 2017 4:00:38 AM shaolinfry wrote:<br>
> Luke,<br>
> I previously explored an extra state to require signalling before<br>
> activation in an earlier draft of BIP8, but the overall impression I g=
ot<br>
> was that gratuitous orphaning was undesirable, so I dropped it. I<br>
> understand the motivation behind it (to ensure miners are upgraded), b=
ut<br>
> it's also rather pointless when miners can just fake signal. A pro=
perly<br>
> constructed soft fork is generally such that miners have to deliberate=
ly<br>
> do something invalid - they cannot be tricked into it... and miners ca=
n<br>
> always chose to do something invalid anyway.<br>
><br>
> > -------- Original Message --------<br>
> > From: <a href=3D"mailto:luke@dashjr.org">luke@dashjr.org</a><br>
> > To: <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitc=
oin-dev@lists.<wbr>linuxfoundation.org</a>, shaolinfry<br>
> > <<a href=3D"mailto:shaolinfry@protonmail.ch">shaolinfry@proton=
mail.ch</a>> I"ve already opened a PR almost 2 weeks ago<br>
> > to do this and fix the other issues BIP 9 has.<br>
> > <a href=3D"https://github.com/bitcoin/bips/pull/550" rel=3D"noref=
errer" target=3D"_blank">https://github.com/bitcoin/<wbr>bips/pull/550</a><=
br>
> > It just needs your ACK to merge.<br>
> ><br>
> > On Wednesday 05 July 2017 1:30:26 AM shaolinfry via bitcoin-dev w=
rote:<br>
> >> Some people have criticized BIP9"s blocktime based thres=
holds arguing<br>
> >> they are confusing (the first retarget after threshold). It i=
s also<br>
> >> vulnerable to miners fiddling with timestamps in a way that c=
ould<br>
> >> prevent or delay activation - for example by only advancing t=
he block<br>
> >> timestamp by 1 second you would never meet the threshold (alt=
hough this<br>
> >> would come a the penalty of hiking the difficulty dramaticall=
y). On the<br>
> >> other hand, the exact date of a height based thresholds is ha=
rd to<br>
> >> predict a long time in advance due to difficulty fluctuations=
. However,<br>
> >> there is certainty at a given block height and it"s easy=
to monitor. If<br>
> >> there is sufficient interest, I would be happy to amend BIP8 =
to be<br>
> >> height based. I originally omitted height based thresholds in=
the<br>
> >> interests of simplicity of review - but now that the proposal=
has been<br>
> >> widely reviewed it would be a trivial amendment.<br>
</div></div><div class=3D"HOEnZb"><div class=3D"h5">_______________________=
_______<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
</div></div></blockquote></div><br></div>
--001a114fcfd65f51d60553973ac8--
|
