summaryrefslogtreecommitdiff
path: root/0e/7290e4665736c424d0b8e51afd6db328eea7bd
blob: bfa627d1c3a82c0d970a252795b1910a83935b64 (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
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
Return-Path: <bram@bittorrent.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 1BCB96C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 11 Dec 2016 01:07:09 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f171.google.com (mail-io0-f171.google.com
	[209.85.223.171])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BF3ECFD
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 11 Dec 2016 01:07:07 +0000 (UTC)
Received: by mail-io0-f171.google.com with SMTP id d9so117394054ioe.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 10 Dec 2016 17:07:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=bittorrent-com.20150623.gappssmtp.com; s=20150623;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to; 
	bh=D31BgW1hep6XSk3x3B2d+aW9nPYfzyxZYwTQYXFCnqE=;
	b=QoRe0BPNCiG/uCwXAete7KwIzhYUcAc5Nr5j5fqAiKNbYLE3VMsXLJZGA8m3Af9blg
	xXpLNudhYwZqg1kRdVv33VqOWtIrcpn2QBbfH4yGUvMrdEUWVYz7/pUQoJ/fvYfjW8XM
	/HBnBBcNcZj3f32+tptmneOfNjUlZmnx0gqq6+PtXUZOHAaNkWZxauaurub9SLC7h41y
	hhNdRMAYHYhtkMETkVk88CVlRdGQq2emuACkDL7QYtRtWusfMcJsX4LpBfHuK5sBNaeJ
	HYj/L/qURk5B1Z9HBEr+8T5QZsV7DCXAmTYW5b+SRNkrfpZiBa85txtQOzVrhlMrVERt
	XjLQ==
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:from:date
	:message-id:subject:to;
	bh=D31BgW1hep6XSk3x3B2d+aW9nPYfzyxZYwTQYXFCnqE=;
	b=D7HDq+x+yHb2THSjBbViX3jjUJOK79J0gyz0PGWKHdFhYC2NeZGQ5zY49p6Vrbf13y
	sU3qHDi/OVBDe3R3QI5ZX65ZUBIVyH3gUmUlrUykJil3dNGpdJLurHOwqI/5Hu96/dbM
	oPo6aay1bLqF6aSy/pHkKc9l9YljyGkzJ/2v+0ZBzPmZZvata3B2NhQhuI5tqBza26oS
	ISHT1PicESodQoCqIom9JN8nc4Kni9ZJ+Y9dO1kNWMs3GrOXE3MeJqAaWcUmpqaMymbS
	sJCp4YvA5vaIkyvsAPapR5RT56+st+P/aBIabcTV2W242OocCPp1Z4rOmCH2IgjRcVbj
	NgeQ==
X-Gm-Message-State: AKaTC02XlXkyQsX1OSMt0NmxKs6XabyMYqhrz78H/061PaQg9xsxviFBIK3/a3RHnE4ZBGZEIH20Idh877Qns3tu
X-Received: by 10.107.35.147 with SMTP id j141mr23841553ioj.41.1481418427126; 
	Sat, 10 Dec 2016 17:07:07 -0800 (PST)
MIME-Version: 1.0
Received: by 10.36.224.199 with HTTP; Sat, 10 Dec 2016 17:07:06 -0800 (PST)
In-Reply-To: <CADvTj4rLfwgzeDdYdAjUBkbCD9JcmxNPam_nuBtkM9KqGYNp=w@mail.gmail.com>
References: <CAGCNRJqdu7DMC+AMR4mYKRAYStRMKVGqbnjtEfmzcoeMij5u=A@mail.gmail.com>
	<c318f76d-0904-2e1b-453b-60179f8209bb@sky-ip.org>
	<CAGCNRJrLM2ZR9qCvuNfyr2mUk50szzHnG-crmpv_3cH=xGxYOg@mail.gmail.com>
	<CADvTj4rLfwgzeDdYdAjUBkbCD9JcmxNPam_nuBtkM9KqGYNp=w@mail.gmail.com>
From: Bram Cohen <bram@bittorrent.com>
Date: Sat, 10 Dec 2016 17:07:06 -0800
Message-ID: <CA+KqGkpws1Q9=ui8QeHpddsCSjjtbGtZK-sgAUMON6Oz+OTY0A@mail.gmail.com>
To: James Hilliard <james.hilliard1@gmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a114041f41cedae0543579bc6
X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, 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
Subject: Re: [bitcoin-dev] Managing block size the same way we do difficulty
 (aka Block75)
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: Sun, 11 Dec 2016 01:07:09 -0000

--001a114041f41cedae0543579bc6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Miners individually have an incentive to include every transaction they can
when they mine a block, but they also sometimes have an incentive to
collectively cooperate to reduce throughput to make more money as a group.
Under schemes where limits can be adjusted both possibilities must be taken
into account.

On Sat, Dec 10, 2016 at 4:40 PM, James Hilliard via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Miners in general are naturally incentivized to always mine max size
> blocks to maximize transaction fees simply because there is very
> little marginal cost to including extra transactions(there will always
> be a transaction backlog of some sort available to mine since demand
> for block space is effectively unbounded as fees approach 0 and they
> can even mine their own transactions without any fees). This proposal
> would almost certainly cause runaway block size growth and encourage
> much more miner centralization.
>
> On Sat, Dec 10, 2016 at 6:26 PM, t. khan via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > Miners 'gaming' the Block75 system -
> > There is no financial incentive for miners to attempt to game the Block=
75
> > system. Even if it were attempted and assuming the goal was to create
> bigger
> > blocks, the maximum possible increase would be 25% over the previous
> block
> > size. And, that size would only last for two weeks before readjusting
> down.
> > It would cost them more in transaction fees to stuff the network than
> they
> > could ever make up. To game the system, they'd have to game it forever
> with
> > no possibility of profit.
> >
> > Blocks would get too big -
> > Eventually, blocks would get too big, but only if bandwidth stopped
> > increasing and the cost of disk space stopped decreasing. Otherwise, th=
e
> > incremental adjustments made by Block75 (especially in combination with
> > SegWit) wouldn't break anyone's connection or result in significantly
> more
> > orphaned blocks.
> >
> > The frequent and small adjustments made by Block75 have the added
> benefit of
> > being more easily adapted to, both psychologically and technologically,
> with
> > regards to miners/node operators.
> >
> > -t.k
> >
> > On Sat, Dec 10, 2016 at 5:44 AM, s7r via bitcoin-dev
> > <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >>
> >> t. khan via bitcoin-dev wrote:
> >> > BIP Proposal - Managing Bitcoin=E2=80=99s block size the same way we=
 do
> >> > difficulty (aka Block75)
> >> >
> >> > The every two-week adjustment of difficulty has proven to be a
> >> > reasonably effective and predictable way of managing how quickly
> blocks
> >> > are mined. Bitcoin needs a reasonably effective and predictable way =
of
> >> > managing the maximum block size.
> >> >
> >> > It=E2=80=99s clear at this point that human beings should not be inv=
olved in
> the
> >> > determination of max block size, just as they=E2=80=99re not involve=
d in
> >> > deciding the difficulty.
> >> >
> >> > Instead of setting an arbitrary max block size (1MB, 2MB, 8MB, etc.)
> or
> >> > passing the decision to miners/pool operators, the max block size
> should
> >> > be adjusted every two weeks (2016 blocks) using a system similar to
> how
> >> > difficulty is calculated.
> >> >
> >> > Put another way: let=E2=80=99s stop thinking about what the max bloc=
k size
> >> > should be and start thinking about how full we want the average bloc=
k
> to
> >> > be regardless of size. Over the last year, we=E2=80=99ve had average=
s of 75%
> or
> >> > higher, so aiming for 75% full seems reasonable, hence naming this
> >> > concept =E2=80=98Block75=E2=80=99.
> >> >
> >> > The target capacity over 2016 blocks would be 75%. If the last 2016
> >> > blocks are more than 75% full, add the difference to the max block
> size.
> >> > Like this:
> >> >
> >> > MAX_BLOCK_BASE_SIZE =3D 1000000
> >> > TARGET_CAPACITY =3D 750000
> >> > AVERAGE_OVER_CAP =3D average block size of last 2016 blocks minus
> >> > TARGET_CAPACITY
> >> >
> >> > To check if a block is valid, =E2=89=A4 (MAX_BLOCK_BASE_SIZE +
> AVERAGE_OVER_CAP)
> >> >
> >> > For example, if the last 2016 blocks are 85% full (average block is
> 850
> >> > KB), add 10% to the max block size. The new max block size would be
> >> > 1,100 KB until the next 2016 blocks are mined, then reset and
> >> > recalculate. The 1,000,000 byte limit that exists currently would
> >> > remain, but would effectively be the minimum max block size.
> >> >
> >> > Another two weeks goes by, the last 2016 blocks are again 85% full,
> but
> >> > now that means they average 935 KB out of the 1,100 KB max block siz=
e.
> >> > This is 93.5% of the 1,000,000 byte limit, so 18.5% would be added t=
o
> >> > that to make the new max block size of 1,185 KB.
> >> >
> >> > Another two weeks passes. This time, the average block is 1,050 KB.
> The
> >> > new max block size is calculated to 1,300 KB (as blocks were 105%
> full,
> >> > minus the 75% capacity target, so 30% added to max block size).
> >> >
> >> > Repeat every 2016 blocks, forever.
> >> >
> >> > If Block75 had been applied at the difficulty adjustment on November
> >> > 18th, the max block size would have been 1,080KB, as the average blo=
ck
> >> > during that period was 83% full, so 8% is added to the 1,000KB limit=
.
> >> > The current size, after the December 2nd adjustment would be 1,150K.
> >> >
> >> > Block75 would allow the max block size to grow (or shrink) in respon=
se
> >> > to transaction volume, and does so predictably, reasonably quickly,
> and
> >> > in a method that prevents wild swings in block size or transaction
> fees.
> >> > It attempts to keep blocks at 75% total capacity over each two week
> >> > period, the same way difficulty tries to keep blocks mined every ten
> >> > minutes. It also keeps blocks as small as possible.
> >> >
> >> > Thoughts?
> >> >
> >> > -t.k.
> >> >
> >>
> >> I like the idea. It is good wrt growing the max. block size
> >> automatically without human action, but the main problem (or question)
> >> is not how to grow this number, it is what number can the network
> >> handle, considering both miners and users. While disk space requiremen=
ts
> >> might not be a big problem, block propagation time is. The time requir=
ed
> >> for a block to propagate in the network (or at least to all the miners=
)
> >> is directly dependent of its size.  If blocks take too much time to
> >> propagate in the network, the orphan rate will increase in unpredictab=
le
> >> ways. For example if the internet speed in China is worse than in
> >> Europe, and miners in China have more than 50% of the hashing power,
> >> blocks mined by European miners might get orphaned.
> >>
> >> The system as described can also be gamed, by filling the network with
> >> transactions. Miners have the monetary interest to include as many
> >> transactions as possible in a block in order to collect the fees.
> >> Regardless how you think about it, there has to be a maximum block siz=
e
> >> that the network will allow as a consensus rule. Increasing it
> >> dynamically based on transaction volume will reach a point where the
> >> number got big enough that it broke things. Bitcoin, because its
> >> fundamental design, can scale by using offchain solutions.
> >>
> >>
> >> _______________________________________________
> >> 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
> >
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr">Miners individually have an incentive to include every tra=
nsaction they can when they mine a block, but they also sometimes have an i=
ncentive to collectively cooperate to reduce throughput to make more money =
as a group. Under schemes where limits can be adjusted both possibilities m=
ust be taken into account.</div><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">On Sat, Dec 10, 2016 at 4:40 PM, James Hilliard via bitcoi=
n-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfounda=
tion.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</=
span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex">Miners in general are natura=
lly incentivized to always mine max size<br>
blocks to maximize transaction fees simply because there is very<br>
little marginal cost to including extra transactions(there will always<br>
be a transaction backlog of some sort available to mine since demand<br>
for block space is effectively unbounded as fees approach 0 and they<br>
can even mine their own transactions without any fees). This proposal<br>
would almost certainly cause runaway block size growth and encourage<br>
much more miner centralization.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
On Sat, Dec 10, 2016 at 6:26 PM, t. khan via bitcoin-dev<br>
&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@li=
sts.<wbr>linuxfoundation.org</a>&gt; wrote:<br>
&gt; Miners &#39;gaming&#39; the Block75 system -<br>
&gt; There is no financial incentive for miners to attempt to game the Bloc=
k75<br>
&gt; system. Even if it were attempted and assuming the goal was to create =
bigger<br>
&gt; blocks, the maximum possible increase would be 25% over the previous b=
lock<br>
&gt; size. And, that size would only last for two weeks before readjusting =
down.<br>
&gt; It would cost them more in transaction fees to stuff the network than =
they<br>
&gt; could ever make up. To game the system, they&#39;d have to game it for=
ever with<br>
&gt; no possibility of profit.<br>
&gt;<br>
&gt; Blocks would get too big -<br>
&gt; Eventually, blocks would get too big, but only if bandwidth stopped<br=
>
&gt; increasing and the cost of disk space stopped decreasing. Otherwise, t=
he<br>
&gt; incremental adjustments made by Block75 (especially in combination wit=
h<br>
&gt; SegWit) wouldn&#39;t break anyone&#39;s connection or result in signif=
icantly more<br>
&gt; orphaned blocks.<br>
&gt;<br>
&gt; The frequent and small adjustments made by Block75 have the added bene=
fit of<br>
&gt; being more easily adapted to, both psychologically and technologically=
, with<br>
&gt; regards to miners/node operators.<br>
&gt;<br>
&gt; -t.k<br>
&gt;<br>
&gt; On Sat, Dec 10, 2016 at 5:44 AM, s7r via bitcoin-dev<br>
&gt; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-d=
ev@lists.<wbr>linuxfoundation.org</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; t. khan via bitcoin-dev wrote:<br>
&gt;&gt; &gt; BIP Proposal - Managing Bitcoin=E2=80=99s block size the same=
 way we do<br>
&gt;&gt; &gt; difficulty (aka Block75)<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; The every two-week adjustment of difficulty has proven to be =
a<br>
&gt;&gt; &gt; reasonably effective and predictable way of managing how quic=
kly blocks<br>
&gt;&gt; &gt; are mined. Bitcoin needs a reasonably effective and predictab=
le way of<br>
&gt;&gt; &gt; managing the maximum block size.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; It=E2=80=99s clear at this point that human beings should not=
 be involved in the<br>
&gt;&gt; &gt; determination of max block size, just as they=E2=80=99re not =
involved in<br>
&gt;&gt; &gt; deciding the difficulty.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Instead of setting an arbitrary max block size (1MB, 2MB, 8MB=
, etc.) or<br>
&gt;&gt; &gt; passing the decision to miners/pool operators, the max block =
size should<br>
&gt;&gt; &gt; be adjusted every two weeks (2016 blocks) using a system simi=
lar to how<br>
&gt;&gt; &gt; difficulty is calculated.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Put another way: let=E2=80=99s stop thinking about what the m=
ax block size<br>
&gt;&gt; &gt; should be and start thinking about how full we want the avera=
ge block to<br>
&gt;&gt; &gt; be regardless of size. Over the last year, we=E2=80=99ve had =
averages of 75% or<br>
&gt;&gt; &gt; higher, so aiming for 75% full seems reasonable, hence naming=
 this<br>
&gt;&gt; &gt; concept =E2=80=98Block75=E2=80=99.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; The target capacity over 2016 blocks would be 75%. If the las=
t 2016<br>
&gt;&gt; &gt; blocks are more than 75% full, add the difference to the max =
block size.<br>
&gt;&gt; &gt; Like this:<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; MAX_BLOCK_BASE_SIZE =3D 1000000<br>
&gt;&gt; &gt; TARGET_CAPACITY =3D 750000<br>
&gt;&gt; &gt; AVERAGE_OVER_CAP =3D average block size of last 2016 blocks m=
inus<br>
&gt;&gt; &gt; TARGET_CAPACITY<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; To check if a block is valid, =E2=89=A4 (MAX_BLOCK_BASE_SIZE =
+ AVERAGE_OVER_CAP)<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; For example, if the last 2016 blocks are 85% full (average bl=
ock is 850<br>
&gt;&gt; &gt; KB), add 10% to the max block size. The new max block size wo=
uld be<br>
&gt;&gt; &gt; 1,100 KB until the next 2016 blocks are mined, then reset and=
<br>
&gt;&gt; &gt; recalculate. The 1,000,000 byte limit that exists currently w=
ould<br>
&gt;&gt; &gt; remain, but would effectively be the minimum max block size.<=
br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Another two weeks goes by, the last 2016 blocks are again 85%=
 full, but<br>
&gt;&gt; &gt; now that means they average 935 KB out of the 1,100 KB max bl=
ock size.<br>
&gt;&gt; &gt; This is 93.5% of the 1,000,000 byte limit, so 18.5% would be =
added to<br>
&gt;&gt; &gt; that to make the new max block size of 1,185 KB.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Another two weeks passes. This time, the average block is 1,0=
50 KB. The<br>
&gt;&gt; &gt; new max block size is calculated to 1,300 KB (as blocks were =
105% full,<br>
&gt;&gt; &gt; minus the 75% capacity target, so 30% added to max block size=
).<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Repeat every 2016 blocks, forever.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; If Block75 had been applied at the difficulty adjustment on N=
ovember<br>
&gt;&gt; &gt; 18th, the max block size would have been 1,080KB, as the aver=
age block<br>
&gt;&gt; &gt; during that period was 83% full, so 8% is added to the 1,000K=
B limit.<br>
&gt;&gt; &gt; The current size, after the December 2nd adjustment would be =
1,150K.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Block75 would allow the max block size to grow (or shrink) in=
 response<br>
&gt;&gt; &gt; to transaction volume, and does so predictably, reasonably qu=
ickly, and<br>
&gt;&gt; &gt; in a method that prevents wild swings in block size or transa=
ction fees.<br>
&gt;&gt; &gt; It attempts to keep blocks at 75% total capacity over each tw=
o week<br>
&gt;&gt; &gt; period, the same way difficulty tries to keep blocks mined ev=
ery ten<br>
&gt;&gt; &gt; minutes. It also keeps blocks as small as possible.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Thoughts?<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; -t.k.<br>
&gt;&gt; &gt;<br>
&gt;&gt;<br>
&gt;&gt; I like the idea. It is good wrt growing the max. block size<br>
&gt;&gt; automatically without human action, but the main problem (or quest=
ion)<br>
&gt;&gt; is not how to grow this number, it is what number can the network<=
br>
&gt;&gt; handle, considering both miners and users. While disk space requir=
ements<br>
&gt;&gt; might not be a big problem, block propagation time is. The time re=
quired<br>
&gt;&gt; for a block to propagate in the network (or at least to all the mi=
ners)<br>
&gt;&gt; is directly dependent of its size.=C2=A0 If blocks take too much t=
ime to<br>
&gt;&gt; propagate in the network, the orphan rate will increase in unpredi=
ctable<br>
&gt;&gt; ways. For example if the internet speed in China is worse than in<=
br>
&gt;&gt; Europe, and miners in China have more than 50% of the hashing powe=
r,<br>
&gt;&gt; blocks mined by European miners might get orphaned.<br>
&gt;&gt;<br>
&gt;&gt; The system as described can also be gamed, by filling the network =
with<br>
&gt;&gt; transactions. Miners have the monetary interest to include as many=
<br>
&gt;&gt; transactions as possible in a block in order to collect the fees.<=
br>
&gt;&gt; Regardless how you think about it, there has to be a maximum block=
 size<br>
&gt;&gt; that the network will allow as a consensus rule. Increasing it<br>
&gt;&gt; dynamically based on transaction volume will reach a point where t=
he<br>
&gt;&gt; number got big enough that it broke things. Bitcoin, because its<b=
r>
&gt;&gt; fundamental design, can scale by using offchain solutions.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; ______________________________<wbr>_________________<br>
&gt;&gt; bitcoin-dev mailing list<br>
&gt;&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-d=
ev@lists.<wbr>linuxfoundation.org</a><br>
&gt;&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitc=
oin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation=
.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
&gt;&gt;<br>
&gt;<br>
&gt;<br>
&gt; ______________________________<wbr>_________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l=
ists.<wbr>linuxfoundation.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wb=
r>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
&gt;<br>
______________________________<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>

--001a114041f41cedae0543579bc6--