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
|
Return-Path: <luke@dashjr.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id ADFFE9BA
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 15 Dec 2016 01:48:40 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id B9CE5156
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 15 Dec 2016 01:48:39 +0000 (UTC)
Received: from ishibashi.localnet (unknown
[IPv6:2001:470:5:265:a45d:823b:2d27:961c])
(Authenticated sender: luke-jr)
by zinan.dashjr.org (Postfix) with ESMTPSA id F41D538AB89E;
Thu, 15 Dec 2016 01:48:27 +0000 (UTC)
X-Hashcash: 1:25:161215:teekhan42@gmail.com::AzoToCsKXxbplY+d:w9h/
X-Hashcash: 1:25:161215:bitcoin-dev@lists.linuxfoundation.org::50waoeBpdi2mhPsA:awXvu
From: Luke Dashjr <luke@dashjr.org>
To: "t. khan" <teekhan42@gmail.com>
Date: Thu, 15 Dec 2016 01:48:23 +0000
User-Agent: KMail/1.13.7 (Linux/4.4.36-gentoo-r1; KDE/4.14.24; x86_64; ; )
References: <CAGCNRJrkGHnnq_s3rsUJH7TX+JB8Ue28SjoyxBnW+LGpH6iJnQ@mail.gmail.com>
In-Reply-To: <CAGCNRJrkGHnnq_s3rsUJH7TX+JB8Ue28SjoyxBnW+LGpH6iJnQ@mail.gmail.com>
X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F
X-PGP-Key-ID: BD02942421F4889F
X-PGP-Keyserver: hkp://pgp.mit.edu
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <201612150148.23862.luke@dashjr.org>
X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD
autolearn=ham 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] BIP - Block75 - Managing max block size as we do
difficulty
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: Thu, 15 Dec 2016 01:48:40 -0000
Please use ASCII quotes in the Title. It is also too long (max size 44=20
characters).
Add missing headers:
Layer: Consensus (hard fork)
Comments-Summary: No comments yet.
Comments-URI: TBD
Status: Draft
Type: Standards Track
License: PD
It must be made at least technically sound. The BIP talks about adjusting t=
he=20
maximum block size, but the specification only affects MAX_BLOCK_BASE_SIZE,=
=20
which does not actually affect the max block size at all. Either the=20
specification needs to implement the described goal (adjusting max block si=
ze)=20
or the motivation needs to be adjusted to explain why MAX_BLOCK_BASE_SIZE i=
s=20
being adjusted.
It is missing a section on Backward Compatibility. This should address at=20
least the fact that this is *NOT* backward compatible, and ideally propose =
a=20
mechanism for establishing agreement from the entire community for its=20
deployment. Similarly, there is talk of 75%, but the algorithm presented do=
es=20
not in fact implement 75%.
=46inally, I am about to set BIP 2 to Active, so it would be preferable to=
=20
choose a copyright license from the choices in BIP 2.
When you're ready, feel free to open a pull request on=20
https://github.com/bitcoin/bips/ with the BIP in mediawiki format, named:
bip-tkhan-block75.mediawiki
Thanks,
Luke
On Wednesday, December 14, 2016 7:55:20 PM t. khan wrote:
> Hi Luke,
>=20
> Following is a BIP for submission. Please let me know if any
> modifications/additions are required.
>=20
> Thank you,
>=20
> -t.k.
>=20
> --------
>=20
> BIP: ??
> Title: =E2=80=98Block75=E2=80=99 - Managing max block size the same way w=
e do difficulty
> Author: t.khan <teekhan42@gmail.com>
> Created: 2016-12-13
>=20
>=20
> Abstract
> Automatic adjustment of max block size with the target of keeping blocks
> 75% full, based on the average block size of the previous 2016 blocks. Th=
is
> would be done on the same schedule as difficulty.
>=20
>=20
> Motivation
> The every two-week and automatic adjustment of difficulty has proven to be
> a reasonably effective and predictable way of managing how quickly blocks
> are mined. It works well because humans aren=E2=80=99t involved, except =
for
> setting the original target of a 10 minute per block average, and therefo=
re
> it isn=E2=80=99t political or contentious. It=E2=80=99s simply a response=
to changing
> network resources.
>=20
> Bitcoin needs a reasonably effective and predictable way of managing the
> maximum block size, which both allows moderate growth and keeps max block
> size as small as possible, thereby preventing wild swings in max block si=
ze
> or transaction fees.
>=20
> 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 involved in =
deciding
> the difficulty. Any solution to block size scaling which sets an arbitrary
> max block size (1MB, 2MB, 8MB, etc.) is by its very design a temporary
> solution and should be avoided. Any solution which passes the decision on
> to miners/pool operators for a vote will, by its very design, be political
> and contentious and should be avoided.
>=20
> A permanent solution that is simply a response to changing transaction
> volumes is the goal of Block75.
>=20
>=20
> Specification
> The max block size would be recalculated every 2016 blocks, along with
> difficulty, using this simple formula:
>=20
> new max block size =3D 1,000KB + (average size of last 2016 blocks - 750K=
B)
>=20
> Further details:
>=20
> MAX_BLOCK_BASE_SIZE =3D 1000000 //this line stays the same
> TARGET_CAPACITY =3D 750000 //new line representing 75%
>=20
> AVERAGE_OVER_CAP =3D average block size of last 2016 blocks minus
> TARGET_CAPACITY
>=20
> To check if a block is valid, =E2=89=A4 (MAX_BLOCK_BASE_SIZE + AVERAGE_OV=
ER_CAP)
>=20
>=20
> Rationale
> The 75% full block target was selected as it represents the middle ground
> between blocks being too small (average 100% full) and blocks being
> unnecessarily large (average 50% full). It can absorb short-term spikes in
> transaction volume of up to 33% and also limits the growth of max block
> size to 250KB over the previous period.
>=20
> The 2016 blocks (two week) period was selected as it has been shown to be
> reasonably adaptive to changing network resources. The frequent and gradu=
al
> adjustments that result from this will be relatively easy for miners and
> node operators to predict and adapt to, as any unforeseen consequences wi=
ll
> be visible well in advance. It also minimizes any effect a malicious party
> could have in an attempt to manipulate block size.
>=20
> Copyright
> This work is placed in the public domain.
|
