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
|
Return-Path: <jgarzik@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 97A07E1C
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 18 Dec 2015 20:15:56 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f180.google.com (mail-io0-f180.google.com
[209.85.223.180])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 825DA125
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 18 Dec 2015 20:15:55 +0000 (UTC)
Received: by mail-io0-f180.google.com with SMTP id o67so101165637iof.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 18 Dec 2015 12:15:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=vQw7tSIMDyPFGPKuMhL7+I7Nz2EJgGgaxUA5VhBHoDA=;
b=onYpCAAfdnD+em1Cfw7XiC4SaGicpCb9F2SrSLs/SVv5RQRrD4tBu8HufgIIo6KXLR
nSgBuk5VHXyPg5aRZCrSmJ9wG2LViTMijl2q6fNJD1/UE5NAdKtdRIBccmo9XTn1KrMX
RN1gqpsxdvdvLmkkKHbRL1jxM5nq20ksqhUdWjE+fFvIoubuefwg2QJ2D0fyMqbMuh3Y
vE7NF0qGp3lYolEoNPJ9EBjbqsWPe+S/Q4xU4XXM8//VmpH4PO2YKbTa81y3CvoLI7Ry
tkYpy6PTsD0e0cRP8qI1qYTgwIv2loFxgXN0Qnc4Te6YX/OsyoGPTSg8Jk2pFmbpBYsz
N0qw==
MIME-Version: 1.0
X-Received: by 10.107.46.137 with SMTP id u9mr6870487iou.136.1450469754997;
Fri, 18 Dec 2015 12:15:54 -0800 (PST)
Received: by 10.79.8.198 with HTTP; Fri, 18 Dec 2015 12:15:54 -0800 (PST)
In-Reply-To: <CABm2gDoyzLErwA0g624A2aPUqSi3gXTgcmC7TTTUNDKyecDpuA@mail.gmail.com>
References: <CAFzgq-xNZmWrdwCDv3twdsqSWk-FyMuLYJjZ_bA42_5Po0mgEg@mail.gmail.com>
<CABm2gDqJgPM1KRRSR3wSEhQ77Oq6P_VVvHwc3Yt4qnkAr7d2nA@mail.gmail.com>
<CADm_WcYFmvu+_OXjm53DHV_q2m8z7Q9zd7QaTrs-uqfiK62CAQ@mail.gmail.com>
<CABm2gDoyzLErwA0g624A2aPUqSi3gXTgcmC7TTTUNDKyecDpuA@mail.gmail.com>
Date: Fri, 18 Dec 2015 15:15:54 -0500
Message-ID: <CADm_Wcah3V7yxCpt97rK89_0GY8HZm6xbCg0yqjKRWak7crt5Q@mail.gmail.com>
From: Jeff Garzik <jgarzik@gmail.com>
To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Content-Type: multipart/alternative; boundary=001a113abfae814966052731ce89
X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_LOW, URIBL_BLACK 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 <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] The increase of max block size should be
determined by block height instead of block time
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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: Fri, 18 Dec 2015 20:15:56 -0000
--001a113abfae814966052731ce89
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
My preference is height activation + one step per block (i.e. also
height). Height seems KISS.
AFAICT most of the attacks would occur around the already-heavily-watched
flag day activation event, in a height based environment, a useful
attribute.
However I would like to hear from others about possible attacks with the
various approaches, before diverging from the default community approach of
switch-based-on-time.
On Fri, Dec 18, 2015 at 3:10 PM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrote:
> Well, if it's not going to be height, I think median time of the previous
> block is better than the time of the current one, and would also solve Ch=
un
> Wang's concerns.
> But as said I prefer to use heights that correspond to diff recalculation
> (because that's the window that bip9 will use for the later 95%
> confirmation anyway).
> On Dec 18, 2015 9:02 PM, "Jeff Garzik" <jgarzik@gmail.com> wrote:
>
>> From a code standpoint, based off height is easy.
>>
>> My first internal version triggered on block 406,800 (~May 5), and each
>> block increased by 20 bytes thereafter.
>>
>> It was changed to time, because time was the standard used in years past
>> for other changes; MTP flag day is more stable than block height.
>>
>> It is preferred to have a single flag trigger (height or time), rather
>> than the more complex trigger-on-time, increment-on-height, but any
>> combination of those will work.
>>
>> Easy to change code back to height-based...
>>
>>
>>
>> On Fri, Dec 18, 2015 at 2:52 PM, Jorge Tim=C3=B3n <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> I agree that nHeight is the simplest option and is my preference.
>>> Another option is to use the median time from the previous block (thus
>>> you know whether or not the next block should start the miner confirmat=
ion
>>> or not). In fact, if we're going to use bip9 for 95% miner upgrade
>>> confirmation, it would be nice to always pick a difficulty retarget blo=
ck
>>> (ie block.nHeight % DifficultyAdjustmentInterval =3D=3D 0).
>>> Actually I would always have an initial height in bip9, for softforks
>>> too.
>>> I would also use the sign bit as the "hardfork bit" that gets activated
>>> for the next diff interval after 95% is reached and a hardfork becomes
>>> active (that way even SPV nodes will notice when a softfork or hardfor=
k
>>> happens and also be able to tell which one is it).
>>> I should update bip99 with all this. And if the 2 mb bump is
>>> uncontroversial, maybe I can add that to the timewarp fix and th recove=
ry
>>> of the other 2 bits in block.nVersion (given that bip102 doesn't seem t=
o
>>> follow bip99's recommendations and doesn't want to give 6 full months a=
s
>>> the pre activation grace period).
>>> On Dec 18, 2015 8:17 PM, "Chun Wang via bitcoin-dev" <
>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
>>>> In many BIPs we have seen, include the latest BIP202, it is the block
>>>> time that determine the max block size. From from pool's point of
>>>> view, it cannot issue a job with a fixed ntime due to the existence of
>>>> ntime roll. It is hard to issue a job with the max block size unknown.
>>>> For developers, it is also easier to implement if max block size is a
>>>> function of block height instead of time. Block height is also much
>>>> more simple and elegant than time.
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev@lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>>
>>
--001a113abfae814966052731ce89
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">My preference is height activation + one step per block (i=
.e. also height).=C2=A0 Height seems KISS.<div><br></div><div>AFAICT most o=
f the attacks would occur around the already-heavily-watched flag day activ=
ation event, in a height based environment, a useful attribute.</div><div><=
br></div><div><div>However I would like to hear from others about possible =
attacks with the various approaches, before diverging from the default comm=
unity approach of switch-based-on-time.</div></div><div><br></div><div><br>=
</div><div><br></div><div><br></div><div><br></div></div><div class=3D"gmai=
l_extra"><br><div class=3D"gmail_quote">On Fri, Dec 18, 2015 at 3:10 PM, Jo=
rge Tim=C3=B3n <span dir=3D"ltr"><<a href=3D"mailto:jtimon@jtimon.cc" ta=
rget=3D"_blank">jtimon@jtimon.cc</a>></span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><p dir=3D"ltr">Well, if it's not going to be height, I th=
ink median time of the previous block is better than the time of the curren=
t one, and would also solve Chun Wang's concerns.<br>
But as said I prefer to use heights that correspond to diff recalculation (=
because that's the window that bip9 will use for the later 95% confirma=
tion anyway).</p><div class=3D"HOEnZb"><div class=3D"h5">
<div class=3D"gmail_quote">On Dec 18, 2015 9:02 PM, "Jeff Garzik"=
<<a href=3D"mailto:jgarzik@gmail.com" target=3D"_blank">jgarzik@gmail.c=
om</a>> wrote:<br type=3D"attribution"><blockquote class=3D"gmail_quote"=
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr">From a code standpoint, based off height is easy.<div><br></=
div><div>My first internal version triggered on block 406,800 (~May 5), and=
each block increased by 20 bytes thereafter.</div><div><br></div><div>It w=
as changed to time, because time was the standard used in years past for ot=
her changes; MTP flag day is more stable than block height.</div><div><br><=
/div><div>It is preferred to have a single flag trigger (height or time), r=
ather than the more complex trigger-on-time, increment-on-height, but any c=
ombination of those will work.</div><div><br></div><div>Easy to change code=
back to height-based...</div><div><br></div><div><br></div></div><div clas=
s=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, Dec 18, 2015 at 2:=
52 PM, Jorge Tim=C3=B3n <span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev=
@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfounda=
tion.org</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir=
=3D"ltr">I agree that nHeight is the simplest option and is my preference.<=
br>
Another option is to use the median time from the previous block (thus you =
know whether or not the next block should start the miner confirmation or n=
ot). In fact, if we're going to use bip9=C2=A0 for 95% miner upgrade co=
nfirmation, it would be nice to always pick a difficulty retarget block (ie=
block.nHeight % DifficultyAdjustmentInterval =3D=3D 0).<br>
Actually I would always have an initial height in bip9, for softforks too.<=
br>
I would also use the sign bit as the "hardfork bit" that gets act=
ivated for the next diff interval after 95% is reached and a hardfork becom=
es active (that way even SPV nodes will notice when a softfork=C2=A0 or har=
dfork happens and also be able to tell which one is it).<br>
I should update bip99 with all this. And if the 2 mb bump is uncontroversia=
l, maybe I can add that to the timewarp fix and th recovery of the other 2 =
bits in block.nVersion (given that bip102 doesn't seem to follow bip99&=
#39;s recommendations and doesn't want to give 6 full months as the pre=
activation grace period).</p><div><div>
<div class=3D"gmail_quote">On Dec 18, 2015 8:17 PM, "Chun Wang via bit=
coin-dev" <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org"=
target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br =
type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In many BIPs we have se=
en, include the latest BIP202, it is the block<br>
time that determine the max block size. From from pool's point of<br>
view, it cannot issue a job with a fixed ntime due to the existence of<br>
ntime roll. It is hard to issue a job with the max block size unknown.<br>
For developers, it is also easier to implement if max block size is a<br>
function of block height instead of time. Block height is also much<br>
more simple and elegant than time.<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
</div></div><br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div><br></div>
</blockquote></div>
</div></div></blockquote></div><br></div>
--001a113abfae814966052731ce89--
|
