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
|
Return-Path: <teekhan42@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 86A5A5AC
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 5 Dec 2016 15:27:34 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ua0-f182.google.com (mail-ua0-f182.google.com
[209.85.217.182])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id F24C4165
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 5 Dec 2016 15:27:33 +0000 (UTC)
Received: by mail-ua0-f182.google.com with SMTP id b35so350947189uaa.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 05 Dec 2016 07:27:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:from:date:message-id:subject:to;
bh=CyQM76TjyNwEORJT/ppGyc+VHXP0WcbeH931UI3+Olk=;
b=dgXeWMTMFHe4WRKVrsz/gLYXXV7FA6cyBF74M8YGIk2St0iMYei25kMC5FSvfpOkv5
60gksDKyiTN7TaHqJerE0to7tWaYBU9yDq7fSmb4nOnSqaItwvCMUVDJMB6ldNH+U0+z
TLOkfx9X5EqvAhzn55a995ArFrks7dBfEjd7igDi0be2EKU00THo0QoMB3/VCmoIc8k2
1nebb1ycTQ53+Ef5BWvS7Ev7OlQWnpAsmXXecmiYV9P0oJKSiVYFX2ENlolyocDU4iaU
mrgMB6jchf6KoZ1YmUxkrLpZXpNj9rtVroadPrfccs3fy2X17DfhgasZJoBDwioKZPfc
TZ6A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
bh=CyQM76TjyNwEORJT/ppGyc+VHXP0WcbeH931UI3+Olk=;
b=OU/9zAzB5y6w+CcpV5y8l4A8gCJ3KNurmQmbwdMQn1mQ1HKN3ZVd4o5R0J5SNPcfk5
zaTzW9MOTNNwvkK+qw2hF2TR0xoByAW9N0S6lDYNem+YdO086MeQXpqHvqyvGp+bG3cg
Qp/7NZbA5pPzA0LkG8sNON1XBLW4jTpqhfFYslrGiOPxoIHTcKomSfr7dHN3XY7Z19WU
vlRDIcdVeMD4w9JB2MhsZuCDQ4QzDm8uSy+anu3nhVE0J0eqT2EhdTHlBUW4SO8U0tQM
beoeikYh8UL000NpfCcxIa6VU829nhE5z/93T4fWMMwWN8EcPGXtkgyG8RFE5ZfY4Sib
mRIQ==
X-Gm-Message-State: AKaTC03dk1s+mYMmqarfgJjqeUTw022WfnijBGs+YD3peTveyKbJgoY5Rbss78PVl/9HJAYHMpAREuY2iBJhBA==
X-Received: by 10.176.86.23 with SMTP id y23mr34612032uaa.88.1480951653003;
Mon, 05 Dec 2016 07:27:33 -0800 (PST)
MIME-Version: 1.0
Received: by 10.103.49.144 with HTTP; Mon, 5 Dec 2016 07:27:32 -0800 (PST)
From: "t. khan" <teekhan42@gmail.com>
Date: Mon, 5 Dec 2016 10:27:32 -0500
Message-ID: <CAGCNRJqdu7DMC+AMR4mYKRAYStRMKVGqbnjtEfmzcoeMij5u=A@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=f403045daa6634f4ac0542eaed44
X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,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
X-Mailman-Approved-At: Sat, 10 Dec 2016 10:21:47 +0000
Subject: [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: Mon, 05 Dec 2016 15:27:34 -0000
--f403045daa6634f4ac0542eaed44
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
BIP Proposal - Managing Bitcoin=E2=80=99s block size the same way we do dif=
ficulty
(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 involved i=
n the
determination of max block size, just as they=E2=80=99re not involved in de=
ciding
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 block size =
should
be and start thinking about how full we want the average block to be
regardless of size. Over the last year, we=E2=80=99ve had averages of 75% o=
r
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 size. This is
93.5% of the 1,000,000 byte limit, so 18.5% would be added to 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 block 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 response 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.
--f403045daa6634f4ac0542eaed44
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">BIP Proposal - Managing Bitcoin=E2=80=99s block size the s=
ame way we do difficulty (aka Block75)<br><br><div>The every two-week adjus=
tment of difficulty has proven to be a reasonably effective and predictable=
way of managing how quickly blocks are mined. Bitcoin needs a reasonably e=
ffective and predictable way of managing the maximum block size.<br><br><di=
v>It=E2=80=99s clear at this point that human beings should not be involved=
in the determination of max block size, just as they=E2=80=99re not involv=
ed in deciding the difficulty.</div><div><br></div><div>Instead of setting =
an arbitrary max block size (1MB, 2MB, 8MB, etc.) or passing the decision t=
o miners/pool operators, the max block size should be adjusted every two we=
eks (2016 blocks) using a system similar to how difficulty is calculated.<b=
r><br><div>Put another way: let=E2=80=99s stop thinking about what the max =
block size should be and start thinking about how full we want the average =
block to be regardless of size. Over the last year, we=E2=80=99ve had avera=
ges of 75% or higher, so aiming for 75% full seems reasonable, hence naming=
this concept =E2=80=98Block75=E2=80=99.<br><br><div>The target capacity ov=
er 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:</div><div><br>MAX_BL=
OCK_BASE_SIZE =3D 1000000<div>TARGET_CAPACITY =3D 750000</div><div>AVERAGE_=
OVER_CAP =3D average block size of last 2016 blocks minus TARGET_CAPACITY</=
div><div><br>To check if a block is valid, =E2=89=A4 (MAX_BLOCK_BASE_SIZE +=
AVERAGE_OVER_CAP)<br><br><div>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 re=
set and recalculate. The 1,000,000 byte limit that exists currently would r=
emain, but would effectively be the minimum max block size.=C2=A0<br><br><d=
iv>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 size. This=
is 93.5% of the 1,000,000 byte limit, so 18.5% would be added to that to m=
ake the new max block size of 1,185 KB.<br><br><div>Another two weeks passe=
s. This time, the average block is 1,050 KB. The new max block size is calc=
ulated to 1,300 KB (as blocks were 105% full, minus the 75% capacity target=
, so 30% added to max block size).</div><div><br>Repeat every 2016 blocks, =
forever.<br><br><div>If Block75 had been applied at the difficulty adjustme=
nt on November 18th, the max block size would have been 1,080KB, as the ave=
rage block during that period was 83% full, so 8% is added to the 1,000KB l=
imit. The current size, after the December 2nd adjustment would be 1,150K.<=
br><br><div>Block75 would allow the max block size to grow (or shrink) in r=
esponse to transaction volume, and does so predictably, reasonably quickly,=
and in a method that prevents wild swings in block size or transaction fee=
s. It attempts to keep blocks at 75% total capacity over each two week peri=
od, the same way difficulty tries to keep blocks mined every ten minutes. I=
t also keeps blocks as small as possible.<br><br><div>Thoughts?<br><br></di=
v><div>-t.k.</div></div></div></div></div></div></div></div></div></div></d=
iv></div>
--f403045daa6634f4ac0542eaed44--
|
