summaryrefslogtreecommitdiff
path: root/5b/17f6f4280a9111934c9a3422576609be830e54
blob: 226b84e4655ba5bbf36e359875d070f523078d85 (plain)
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
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <steven.pine@gmail.com>) id 1Yy0hd-0003sm-Uj
	for bitcoin-development@lists.sourceforge.net;
	Thu, 28 May 2015 16:30:41 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.216.47 as permitted sender)
	client-ip=209.85.216.47; envelope-from=steven.pine@gmail.com;
	helo=mail-vn0-f47.google.com; 
Received: from mail-vn0-f47.google.com ([209.85.216.47])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Yy0hc-0007gN-7u
	for bitcoin-development@lists.sourceforge.net;
	Thu, 28 May 2015 16:30:41 +0000
Received: by vnbg190 with SMTP id g190so5263100vnb.4
	for <bitcoin-development@lists.sourceforge.net>;
	Thu, 28 May 2015 09:30:34 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.52.227.8 with SMTP id rw8mr3101037vdc.4.1432830634658; Thu,
	28 May 2015 09:30:34 -0700 (PDT)
Received: by 10.52.26.80 with HTTP; Thu, 28 May 2015 09:30:34 -0700 (PDT)
Received: by 10.52.26.80 with HTTP; Thu, 28 May 2015 09:30:34 -0700 (PDT)
In-Reply-To: <CAAjy6kDdB8uODpPcmS8h4eap8fke7Y2y773NHJZja8tB5mPk4Q@mail.gmail.com>
References: <CAAjy6kDdB8uODpPcmS8h4eap8fke7Y2y773NHJZja8tB5mPk4Q@mail.gmail.com>
Date: Thu, 28 May 2015 12:30:34 -0400
Message-ID: <CAAjy6kAsNJNJHHU7H91LsAOJZUjiuy3V3r1n-wqntUhCHdgYKw@mail.gmail.com>
From: Steven Pine <steven.pine@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Content-Type: multipart/alternative; boundary=089e01176e9d00939c051726e171
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(steven.pine[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1Yy0hc-0007gN-7u
Subject: Re: [Bitcoin-development] Proposed alternatives to the 20MB step
	function
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 28 May 2015 16:30:42 -0000

--089e01176e9d00939c051726e171
Content-Type: text/plain; charset=UTF-8

I would support a dynamic block size increase as outlined. I have a few
questions though.

Is scaling by average block size the best and easiest method, why not scale
by transactions confirmed instead? Anyone can write and relay a
transaction, and those are what we want to scale for, why not measure it
directly?

I would prefer changes every 2016 blocks, it is a well known change and a
reasonable time period for planning on changes. Two weeks is plenty fast,
especially at a 50% rate increase, in a few months the block size could be
dramatically larger.

Daily change to size seems confusing especially considering that max block
size will be dipping up and down. Also if something breaks trying to fix it
in a day seems problematic. The hard fork database size difference error
comes to mind. Finally daily 50% increases could quickly crowd out smaller
nodes if changes happen too quickly to adapt for.





> Date: Thu, 28 May 2015 11:53:41 -0400
> From: Gavin Andresen <gavinandresen@gmail.com>
> Subject:
> To: Matt Whitlock <bip@mattwhitlock.name>
> Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
> Message-ID:
>         <
CABsx9T3-zxCAagAS0megd06xvG5n-3tUL9NUK9TT3vt7XNL9Tg@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Fri, May 8, 2015 at 3:20 AM, Matt Whitlock <bip@mattwhitlock.name>
wrote:
>
> > Between all the flames on this list, several ideas were raised that did
> > not get much attention. I hereby resubmit these ideas for consideration
and
> > discussion.
> >
> > - Perhaps the hard block size limit should be a function of the actual
> > block sizes over some trailing sampling period. For example, take the
> > median block size among the most recent 2016 blocks and multiply it by
1.5.
> > This allows Bitcoin to scale up gradually and organically, rather than
> > having human beings guessing at what is an appropriate limit.
> >
>
> A lot of people like this idea, or something like it. It is nice and
> simple, which is really important for consensus-critical code.
>
> With this rule in place, I believe there would be more "fee pressure"
> (miners would be creating smaller blocks) today. I created a couple of
> histograms of block sizes to infer what policy miners are ACTUALLY
> following today with respect to block size:
>
> Last 1,000 blocks:
>   http://bitcoincore.org/~gavin/sizes_last1000.html
>
> Notice a big spike at 750K -- the default size for Bitcoin Core.
> This graph might be misleading, because transaction volume or fees might
> not be high enough over the last few days to fill blocks to whatever limit
> miners are willing to mine.
>
> So I graphed a time when (according to statoshi.info) there WERE a lot of
> transactions waiting to be confirmed:
>    http://bitcoincore.org/~gavin/sizes_357511.html
>
> That might also be misleading, because it is possible there were a lot of
> transactions waiting to be confirmed because miners who choose to create
> small blocks got lucky and found more blocks than normal.  In fact, it
> looks like that is what happened: more smaller-than-normal blocks were
> found, and the memory pool backed up.
>
> So: what if we had a dynamic maximum size limit based on recent history?
>
> The average block size is about 400K, so a 1.5x rule would make the max
> block size 600K; miners would definitely be squeezing out transactions /
> putting pressure to increase transaction fees. Even a 2x rule (implying
> 800K max blocks) would, today, be squeezing out transactions / putting
> pressure to increase fees.
>
> Using a median size instead of an average means the size can increase or
> decrease more quickly. For example, imagine the rule is "median of last
> 2016 blocks" and 49% of miners are producing 0-size blocks and 51% are
> producing max-size blocks. The median is max-size, so the 51% have total
> control over making blocks bigger.  Swap the roles, and the median is
> min-size.
>
> Because of that, I think using an average is better-- it means the max
size
> will change (up or down) more slowly.
>
> I also think 2016 blocks is too long, because transaction volumes change
> quicker than that. An average over 144 blocks (last 24 hours) would be
> better able to handle increased transaction volume around major holidays,
> and would also be able to react more quickly if an economically irrational
> attacker attempted to flood the network with fee-paying transactions.
>
> So my straw-man proposal would be:  max size 2x average size over last 144
> blocks, calculated at every block.
>
> There are a couple of other changes I'd pair with that consensus change:
>
> + Make the default mining policy for Bitcoin Core neutral-- have its
target
> block size be the average size, so miners that don't care will "go along
> with the people who do care."
>
> + Use something like Greg's formula for size instead of bytes-on-the-wire,
> to discourage bloating the UTXO set.
>
>
> ---------
>
> When I've proposed (privately, to the other core committers) some dynamic
> algorithm the objection has been "but that gives miners complete control
> over the max block size."
>
> I think that worry is unjustified right now-- certainly, until we have
> size-independent new block propagation there is an incentive for miners to
> keep their blocks small, and we see miners creating small blocks even when
> there are fee-paying transactions waiting to be confirmed.
>
> I don't even think it will be a problem if/when we do have
size-independent
> new block propagation, because I think the combination of the random
timing
> of block-finding plus a dynamic limit as described above will create a
> healthy system.
>
> If I'm wrong, then it seems to me the miners will have a very strong
> incentive to, collectively, impose whatever rules are necessary (maybe a
> soft-fork to put a hard cap on block size) to make the system healthy
again.
>
>
> --
> --
> Gavin Andresen
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
>
------------------------------------------------------------------------------
>
>
> ------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> End of Bitcoin-development Digest, Vol 48, Issue 122
> ****************************************************

--089e01176e9d00939c051726e171
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">I would support a dynamic block size increase as outlined. I=
 have a few questions though.</p>
<p dir=3D"ltr">Is scaling by average block size the best and easiest method=
, why not scale by transactions confirmed instead? Anyone can write and rel=
ay a transaction, and those are what we want to scale for, why not measure =
it directly?</p>
<p dir=3D"ltr">I would prefer changes every 2016 blocks, it is a well known=
 change and a reasonable time period for planning on changes. Two weeks is =
plenty fast, especially at a 50% rate increase, in a few months the block s=
ize could be dramatically larger. </p>
<p dir=3D"ltr">Daily change to size seems confusing especially considering =
that max block size will be dipping up and down. Also if something breaks t=
rying to fix it in a day seems problematic. The hard fork database size dif=
ference error comes to mind. Finally daily 50% increases could quickly crow=
d out smaller nodes if changes happen too quickly to adapt for.<br><br><br>=
<br><br><br></p>
<p dir=3D"ltr">&gt; Date: Thu, 28 May 2015 11:53:41 -0400<br>
&gt; From: Gavin Andresen &lt;<a href=3D"mailto:gavinandresen@gmail.com">ga=
vinandresen@gmail.com</a>&gt;<br>
&gt; Subject: <br>
&gt; To: Matt Whitlock &lt;<a href=3D"mailto:bip@mattwhitlock.name">bip@mat=
twhitlock.name</a>&gt;<br>
&gt; Cc: Bitcoin Dev &lt;<a href=3D"mailto:bitcoin-development@lists.source=
forge.net">bitcoin-development@lists.sourceforge.net</a>&gt;<br>
&gt; Message-ID:<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 &lt;<a href=3D"mailto:CABsx9T3-zxCAagAS0me=
gd06xvG5n-3tUL9NUK9TT3vt7XNL9Tg@mail.gmail.com">CABsx9T3-zxCAagAS0megd06xvG=
5n-3tUL9NUK9TT3vt7XNL9Tg@mail.gmail.com</a>&gt;<br>
&gt; Content-Type: text/plain; charset=3D&quot;utf-8&quot;<br>
&gt;<br>
&gt; On Fri, May 8, 2015 at 3:20 AM, Matt Whitlock &lt;<a href=3D"mailto:bi=
p@mattwhitlock.name">bip@mattwhitlock.name</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt; Between all the flames on this list, several ideas were raised th=
at did<br>
&gt; &gt; not get much attention. I hereby resubmit these ideas for conside=
ration and<br>
&gt; &gt; discussion.<br>
&gt; &gt;<br>
&gt; &gt; - Perhaps the hard block size limit should be a function of the a=
ctual<br>
&gt; &gt; block sizes over some trailing sampling period. For example, take=
 the<br>
&gt; &gt; median block size among the most recent 2016 blocks and multiply =
it by 1.5.<br>
&gt; &gt; This allows Bitcoin to scale up gradually and organically, rather=
 than<br>
&gt; &gt; having human beings guessing at what is an appropriate limit.<br>
&gt; &gt;<br>
&gt;<br>
&gt; A lot of people like this idea, or something like it. It is nice and<b=
r>
&gt; simple, which is really important for consensus-critical code.<br>
&gt;<br>
&gt; With this rule in place, I believe there would be more &quot;fee press=
ure&quot;<br>
&gt; (miners would be creating smaller blocks) today. I created a couple of=
<br>
&gt; histograms of block sizes to infer what policy miners are ACTUALLY<br>
&gt; following today with respect to block size:<br>
&gt;<br>
&gt; Last 1,000 blocks:<br>
&gt; =C2=A0 <a href=3D"http://bitcoincore.org/~gavin/sizes_last1000.html">h=
ttp://bitcoincore.org/~gavin/sizes_last1000.html</a><br>
&gt;<br>
&gt; Notice a big spike at 750K -- the default size for Bitcoin Core.<br>
&gt; This graph might be misleading, because transaction volume or fees mig=
ht<br>
&gt; not be high enough over the last few days to fill blocks to whatever l=
imit<br>
&gt; miners are willing to mine.<br>
&gt;<br>
&gt; So I graphed a time when (according to <a href=3D"http://statoshi.info=
">statoshi.info</a>) there WERE a lot of<br>
&gt; transactions waiting to be confirmed:<br>
&gt; =C2=A0 =C2=A0<a href=3D"http://bitcoincore.org/~gavin/sizes_357511.htm=
l">http://bitcoincore.org/~gavin/sizes_357511.html</a><br>
&gt;<br>
&gt; That might also be misleading, because it is possible there were a lot=
 of<br>
&gt; transactions waiting to be confirmed because miners who choose to crea=
te<br>
&gt; small blocks got lucky and found more blocks than normal.=C2=A0 In fac=
t, it<br>
&gt; looks like that is what happened: more smaller-than-normal blocks were=
<br>
&gt; found, and the memory pool backed up.<br>
&gt;<br>
&gt; So: what if we had a dynamic maximum size limit based on recent histor=
y?<br>
&gt;<br>
&gt; The average block size is about 400K, so a 1.5x rule would make the ma=
x<br>
&gt; block size 600K; miners would definitely be squeezing out transactions=
 /<br>
&gt; putting pressure to increase transaction fees. Even a 2x rule (implyin=
g<br>
&gt; 800K max blocks) would, today, be squeezing out transactions / putting=
<br>
&gt; pressure to increase fees.<br>
&gt;<br>
&gt; Using a median size instead of an average means the size can increase =
or<br>
&gt; decrease more quickly. For example, imagine the rule is &quot;median o=
f last<br>
&gt; 2016 blocks&quot; and 49% of miners are producing 0-size blocks and 51=
% are<br>
&gt; producing max-size blocks. The median is max-size, so the 51% have tot=
al<br>
&gt; control over making blocks bigger.=C2=A0 Swap the roles, and the media=
n is<br>
&gt; min-size.<br>
&gt;<br>
&gt; Because of that, I think using an average is better-- it means the max=
 size<br>
&gt; will change (up or down) more slowly.<br>
&gt;<br>
&gt; I also think 2016 blocks is too long, because transaction volumes chan=
ge<br>
&gt; quicker than that. An average over 144 blocks (last 24 hours) would be=
<br>
&gt; better able to handle increased transaction volume around major holida=
ys,<br>
&gt; and would also be able to react more quickly if an economically irrati=
onal<br>
&gt; attacker attempted to flood the network with fee-paying transactions.<=
br>
&gt;<br>
&gt; So my straw-man proposal would be:=C2=A0 max size 2x average size over=
 last 144<br>
&gt; blocks, calculated at every block.<br>
&gt;<br>
&gt; There are a couple of other changes I&#39;d pair with that consensus c=
hange:<br>
&gt;<br>
&gt; + Make the default mining policy for Bitcoin Core neutral-- have its t=
arget<br>
&gt; block size be the average size, so miners that don&#39;t care will &qu=
ot;go along<br>
&gt; with the people who do care.&quot;<br>
&gt;<br>
&gt; + Use something like Greg&#39;s formula for size instead of bytes-on-t=
he-wire,<br>
&gt; to discourage bloating the UTXO set.<br>
&gt;<br>
&gt;<br>
&gt; ---------<br>
&gt;<br>
&gt; When I&#39;ve proposed (privately, to the other core committers) some =
dynamic<br>
&gt; algorithm the objection has been &quot;but that gives miners complete =
control<br>
&gt; over the max block size.&quot;<br>
&gt;<br>
&gt; I think that worry is unjustified right now-- certainly, until we have=
<br>
&gt; size-independent new block propagation there is an incentive for miner=
s to<br>
&gt; keep their blocks small, and we see miners creating small blocks even =
when<br>
&gt; there are fee-paying transactions waiting to be confirmed.<br>
&gt;<br>
&gt; I don&#39;t even think it will be a problem if/when we do have size-in=
dependent<br>
&gt; new block propagation, because I think the combination of the random t=
iming<br>
&gt; of block-finding plus a dynamic limit as described above will create a=
<br>
&gt; healthy system.<br>
&gt;<br>
&gt; If I&#39;m wrong, then it seems to me the miners will have a very stro=
ng<br>
&gt; incentive to, collectively, impose whatever rules are necessary (maybe=
 a<br>
&gt; soft-fork to put a hard cap on block size) to make the system healthy =
again.<br>
&gt;<br>
&gt;<br>
&gt; --<br>
&gt; --<br>
&gt; Gavin Andresen<br>
&gt; -------------- next part --------------<br>
&gt; An HTML attachment was scrubbed...<br>
&gt;<br>
&gt; ------------------------------<br>
&gt;<br>
&gt; ----------------------------------------------------------------------=
--------<br>
&gt;<br>
&gt;<br>
&gt; ------------------------------<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; Bitcoin-development mailing list<br>
&gt; <a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-d=
evelopment@lists.sourceforge.net</a><br>
&gt; <a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-develo=
pment">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a>=
<br>
&gt;<br>
&gt;<br>
&gt; End of Bitcoin-development Digest, Vol 48, Issue 122<br>
&gt; ****************************************************<br>
</p>

--089e01176e9d00939c051726e171--