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
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
|
Return-Path: <corey3@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 0CF3EFD1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 7 Feb 2016 22:04:34 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f181.google.com (mail-io0-f181.google.com
[209.85.223.181])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0D464100
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 7 Feb 2016 22:04:33 +0000 (UTC)
Received: by mail-io0-f181.google.com with SMTP id f81so178065829iof.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 07 Feb 2016 14:04:32 -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=Vg3Qp/oAXOSl3YOiNej/9nNUiw5RTjqPrX4GuAA+M1E=;
b=N0xMgkqNlwP5SFjb/mNrV12g/5VDh5sxrnaSfX3HiENC53LxifPdKjOAQV0Lu/tmbm
PQ+Y8s5VtgvMkjTzQbjRD6HFTd1QhKctqqypraNT6yI6tmGUl89EIuTrBSG6FfyJRfNJ
SmhKmH2/Rnn2s5+rN0G2LIFtOkQIpEbZR07batybCIQOHL0+hmkD5ItNbtGtPHyR9ILA
dGSUTsDY0N103M4e3QnvBm+IElWjfpMtfysE5NzjRIUB8YoOzu01Dx3v6/8IIqhEkY/7
FtEU1+GP9blK+pUflDMFlqK+mo8hSTW5NaPlzu+fyeX5y1vnB5EhMAvlUBq3Kb6yw2uk
mD4Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type;
bh=Vg3Qp/oAXOSl3YOiNej/9nNUiw5RTjqPrX4GuAA+M1E=;
b=DkqttckhkroNDI+VudAPbHvk7QARjaH57YS4F7blY3VBzOs+vMIJjIkZykgdS/Lyfp
LEXM8geyK9ghYDVbsx2fdYOuEcEqPsdjB1AE++VGR0TUnfQPMv90YHjTqGEoIRJoZ+xr
VttZMuxBCeu0+Z37I8YZLugq6xXkRu1eTrgg/NSdOFu3gEntHY/icPmtdmwEQPbdmYKf
QdsoOOyW1lUaes/AF9q97pHj7WBhDUg1se4tTudc+ROPSQtmps/gWGFgk426/+BaqxBr
rYpuiJ42zy6sYsnGXxIdO9xbTWhNAe2drrgR4v6WIBR1EWPkBqGJVc2PSdHlfbCBRX91
W6Gw==
X-Gm-Message-State: AG10YOTYAvnHybVqk5d83w469CZoCBjPR4Qg12PtM/FnXuzdgl9qS6AuFf/WOawgy66zFEzS/Z1JcxiwP3g8LA==
MIME-Version: 1.0
X-Received: by 10.107.137.100 with SMTP id l97mr28800094iod.110.1454882672441;
Sun, 07 Feb 2016 14:04:32 -0800 (PST)
Received: by 10.64.239.233 with HTTP; Sun, 7 Feb 2016 14:04:32 -0800 (PST)
In-Reply-To: <CAAjy6kDd_1wY=Zrwnp4FZ_b0C0C06ThTLSPZq06Yjh178DuOkA@mail.gmail.com>
References: <CABsx9T1Bd0-aQg-9uRa4u3dGA5fKxaj8-mEkxVzX8mhdj4Gt2g@mail.gmail.com>
<201602062046.40193.luke@dashjr.org>
<CABsx9T0N_TBbmy3xr-mqNDdKVF_3_QHYA1W2ttsZBQnt4dWxgw@mail.gmail.com>
<201602072101.15142.luke@dashjr.org>
<CAAjy6kDd_1wY=Zrwnp4FZ_b0C0C06ThTLSPZq06Yjh178DuOkA@mail.gmail.com>
Date: Sun, 7 Feb 2016 14:04:32 -0800
Message-ID: <CAK_HAC-YDObNzgVYvrYYRPSEpa6CrLadqV+HSYggNZOtjAZGpA@mail.gmail.com>
From: Corey Haddad <corey3@gmail.com>
To: Steven Pine <steven.pine@gmail.com>
Content-Type: multipart/alternative; boundary=001a113ec644e17f9f052b354430
X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Mon, 08 Feb 2016 01:53:55 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2
megabytes
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: Sun, 07 Feb 2016 22:04:34 -0000
--001a113ec644e17f9f052b354430
Content-Type: text/plain; charset=UTF-8
We don't have any evidence of how fast nodes will upgrade when faced with
an impending hard fork, but it seems like a very safe assumption that the
upgrade pace will be significantly faster. The hard fork case it is:
"upgrade or be kicked off the network". In the previous cases it has been,
"here's the latest and greatest, give it a go!". Also, there will be
alerts sent out warning people of the situation, prompting them to take
action.
It is unclear if this will translate into more or less than 6x the adoption
speed of previous instances, but the idea that it would be faster is
solid. 28 days is aggressive, but again, it is only 28 days from when the
fork triggers. Compatible software is already available for anyone who
wants to prepare.
It is also of significance that this proposed fork, and this debate, has
been going on for many, many months. If someone proposed a forking concept
today, wrote the BIP tomorrow, deployed it next week, miners adopted it
instantly, and 28 days later it was the flag day, those 28 days would be in
a different context. There is no surprise here.
On Sun, Feb 7, 2016 at 1:33 PM, Steven Pine via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Is it me or did Gavin ignore Yifu's direct questions? In case you missed
> it Gavin --
>
> ~
> "We can look at the adoption of the last major Bitcoin core release to
> guess how long it might take people to upgrade. 0.11.0 was released on 12
> July, 2015. Twenty eight days later, about 38% of full nodes were running
> that release. Three months later, about 50% of the network was running
> that release, and six months later about 66% of the network was running
> some flavor of 0.11."
>
> On what grounds do you think it is reasonable to assume that this update
> will roll out 6x faster than previous data suggested, as oppose to your own
> observation of 66% adoption in 6 month. or do you believe 38% node
> upgrade-coverage (in 28 days ) on the network for a hard fork is good
> enough?
>
> There are no harm in choosing a longer grace period but picking one short
> as 28 days you risk on alienating the nodes who do not upgrade with the
> aggressive upgrade timeline you proposed.
> ~~
>
> When Gavin writes "Responding to "28 days is not long enough" :
>
> I keep seeing this claim made with no evidence to back it up. As I said,
> I surveyed several of the biggest infrastructure providers and the btcd
> lead developer and they all agree "28 days is plenty of time."
>
> For individuals... why would it take somebody longer than 28 days to
> either download and restart their bitcoind, or to patch and then re-run
> (the patch can be a one-line change MAX_BLOCK_SIZE from 1000000 to
> 2000000)?"
>
> ~~
>
> Isn't Yifu's comment, evidence, the very best sort of evidence, it isn't
> propositional a priori logic, but empirical evidence that. As for why
> people take longer, who knows, we simply know from passed experience that
> it in fact does take longer.
>
> It's extremely frustrating to read Gavin's comments, it's hard to believe
> he is engaging in earnest discussion.
>
> On Sun, Feb 7, 2016 at 4:01 PM, Luke Dashjr via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> On Sunday, February 07, 2016 2:16:02 PM Gavin Andresen wrote:
>> > On Sat, Feb 6, 2016 at 3:46 PM, Luke Dashjr via bitcoin-dev <
>> > bitcoin-dev@lists.linuxfoundation.org> wrote:
>> > > On Saturday, February 06, 2016 5:25:21 PM Tom Zander via bitcoin-dev
>> wrote:
>> > > > If you have a node that is "old" your node will stop getting new
>> > > > blocks. The node will essentially just say "x-hours behind" with "x"
>> > > > getting larger every hour. Funds don't get confirmed. etc.
>> > >
>> > > Until someone decides to attack you. Then you'll get 6, 10, maybe more
>> > > blocks confirming a large 10000 BTC payment. If you're just a normal
>> end
>> > > user (or perhaps an automated system), you'll figure that payment is
>> good
>> > > and irreversibly hand over the title to the house.
>> >
>> > There will be approximately zero percentage of hash power left on the
>> > weaker branch of the fork, based on past soft-fork adoption by miners
>> (they
>> > upgrade VERY quickly from 75% to over 95%).
>>
>> I'm assuming there are literally ZERO miners left on the weaker branch.
>> The attacker in this scenario simply rents hashing for a few days in
>> advance
>> to build his fake chain, then broadcasts the blocks to the unsuspecting
>> merchant at ~10 block intervals so it looks like everything is working
>> normal
>> again. There are lots of mining rental services out there, and miners
>> quite
>> often do not care to avoid selling hashrate to the highest bidder
>> regardless
>> of what they're mining. 10 blocks worth costs a little more than 250 BTC -
>> soon, that will be 125 BTC.
>>
>> Luke
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
>
> --
> Steven Pine
> (510) 517-7075
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--001a113ec644e17f9f052b354430
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>We don't have any evidence of how fast nodes will=
upgrade when faced with an impending hard fork, but it seems like a very s=
afe assumption that the upgrade pace will be significantly faster.=C2=A0 Th=
e hard fork case it is: "upgrade or be kicked off the network".=
=C2=A0 In the previous cases it has been, "here's the latest and g=
reatest, give it a go!".=C2=A0 Also, there will be alerts sent out war=
ning people of the situation, prompting them to take action.<br><br></div><=
div>It is unclear if this will translate into more or less than 6x the adop=
tion speed of previous instances, but the idea that it would be faster is s=
olid.=C2=A0 28 days is aggressive, but again, it is only 28 days from when =
the fork triggers.=C2=A0 Compatible software is already available for anyon=
e who wants to prepare.<br><br></div><div>It is also of significance that t=
his proposed fork, and this debate, has been going on for many, many months=
.=C2=A0 If someone proposed a forking concept today, wrote the BIP tomorrow=
, deployed it next week, miners adopted it instantly, and 28 days later it =
was the flag day, those 28 days would be in a different context.=C2=A0 Ther=
e is no surprise here. <br></div></div><div class=3D"gmail_extra"><br><div =
class=3D"gmail_quote">On Sun, Feb 7, 2016 at 1:33 PM, Steven Pine via bitco=
in-dev <span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfound=
ation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>><=
/span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Is it=
me or did Gavin ignore Yifu's direct questions? In case you missed it =
Gavin --</div><div><br></div><div>~</div><span class=3D""><span style=3D"fo=
nt-size:12.8px">"We can look at the adoption of the last major Bitcoin=
core release to guess how long it might take people to upgrade. 0.11.0 was=
released on 12 July, 2015. Twenty=C2=A0</span><span style=3D"font-size:12.=
8px"><span>eight days later</span></span><span style=3D"font-size:12.8px">,=
about 38% of full nodes were running that release.=C2=A0</span><span style=
=3D"font-size:12.8px"><span>Three months later</span></span><span style=3D"=
font-size:12.8px">, about 50% of the network was running that release, and=
=C2=A0</span><span style=3D"font-size:12.8px"><span>six months later</span>=
</span><span style=3D"font-size:12.8px">=C2=A0about 66% of the network was =
running some flavor of 0.11."</span><div style=3D"font-size:12.8px"><b=
r></div></span><div style=3D"font-size:12.8px">On what grounds do you think=
it is reasonable to assume that this update will roll out 6x faster than p=
revious data suggested, as oppose to your own observation of 66% adoption=
=C2=A0<span><span>in 6 month</span></span>. or do you believe 38% node upgr=
ade-coverage (<span><span>in 28 days</span></span>=C2=A0) on the network fo=
r a hard fork is good enough?</div><span class=3D""><div style=3D"font-size=
:12.8px"><br></div><div style=3D"font-size:12.8px">There are no harm in cho=
osing a longer grace period but picking one short as 28 days you risk on al=
ienating the nodes who do not upgrade with the aggressive upgrade timeline =
you proposed.</div></span><div>~~</div><div><br></div><div>When Gavin write=
s "<span style=3D"font-size:12.8px">Responding to "28 days is not=
long enough" :</span></div><span class=3D""><div style=3D"font-size:1=
2.8px"><br></div><div style=3D"font-size:12.8px">I keep seeing this claim m=
ade with no evidence to back it up.=C2=A0 As I said, I surveyed several of =
the biggest infrastructure providers and the btcd lead developer and they a=
ll agree "28 days is plenty of time."</div><div style=3D"font-siz=
e:12.8px"><br></div></span><span class=3D""><div style=3D"font-size:12.8px"=
>For individuals... why would it take somebody longer than 28 days to eithe=
r download and restart their bitcoind, or to patch and then re-run (the pat=
ch can be a one-line change MAX_BLOCK_SIZE from 1000000 to 2000000)?"<=
/div><div style=3D"font-size:12.8px"><br></div></span><div style=3D"font-si=
ze:12.8px">~~</div><div style=3D"font-size:12.8px"><br></div><div style=3D"=
font-size:12.8px">Isn't Yifu's comment, evidence, the very best sor=
t of evidence, it isn't propositional a priori logic, but empirical evi=
dence that. As for why people take longer, who knows, we simply know from p=
assed experience that it in fact does take longer.</div><div style=3D"font-=
size:12.8px"><br></div><div style=3D"font-size:12.8px">It's extremely f=
rustrating to read Gavin's comments, it's hard to believe he is eng=
aging in earnest discussion.</div></div><div class=3D"gmail_extra"><div><di=
v class=3D"h5"><br><div class=3D"gmail_quote">On Sun, Feb 7, 2016 at 4:01 P=
M, Luke Dashjr via bitcoin-dev <span dir=3D"ltr"><<a href=3D"mailto:bitc=
oin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linu=
xfoundation.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"><sp=
an>On Sunday, February 07, 2016 2:16:02 PM Gavin Andresen wrote:<br>
> On Sat, Feb 6, 2016 at 3:46 PM, Luke Dashjr via bitcoin-dev <<br>
> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br>
> > On Saturday, February 06, 2016 5:25:21 PM Tom Zander via bitcoin-=
dev<br>
wrote:<br>
</span><span>> > > If you have a node that is "old" your=
node will stop getting new<br>
> > > blocks. The node will essentially just say "x-hours beh=
ind" with "x"<br>
> > > getting larger every hour. Funds don't get confirmed. et=
c.<br>
> ><br>
> > Until someone decides to attack you. Then you'll get 6, 10, m=
aybe more<br>
> > blocks confirming a large 10000 BTC payment. If you're just a=
normal end<br>
> > user (or perhaps an automated system), you'll figure that pay=
ment is good<br>
> > and irreversibly hand over the title to the house.<br>
><br>
> There will be approximately zero percentage of hash power left on the<=
br>
> weaker branch of the fork, based on past soft-fork adoption by miners =
(they<br>
> upgrade VERY quickly from 75% to over 95%).<br>
<br>
</span>I'm assuming there are literally ZERO miners left on the weaker =
branch.<br>
The attacker in this scenario simply rents hashing for a few days in advanc=
e<br>
to build his fake chain, then broadcasts the blocks to the unsuspecting<br>
merchant at ~10 block intervals so it looks like everything is working norm=
al<br>
again. There are lots of mining rental services out there, and miners quite=
<br>
often do not care to avoid selling hashrate to the highest bidder regardles=
s<br>
of what they're mining. 10 blocks worth costs a little more than 250 BT=
C -<br>
soon, that will be 125 BTC.<br>
<div><div><br>
Luke<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>
</div></div></blockquote></div><br><br clear=3D"all"><div><br></div></div><=
/div><span class=3D"HOEnZb"><font color=3D"#888888">-- <br><div><div dir=3D=
"ltr"><div>Steven Pine<div><a href=3D"tel:%28510%29%20517-7075" value=3D"+1=
5105177075" target=3D"_blank">(510) 517-7075</a></div></div></div></div>
</font></span></div>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">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>
--001a113ec644e17f9f052b354430--
|