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
|
Return-Path: <washington.sanchez@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 5EB64F21
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 8 Sep 2015 07:45:17 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f174.google.com (mail-ig0-f174.google.com
[209.85.213.174])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A9480A4
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 8 Sep 2015 07:45:16 +0000 (UTC)
Received: by igbni9 with SMTP id ni9so71032548igb.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 08 Sep 2015 00:45:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:date:message-id:subject:from:to:content-type;
bh=MqfCPSOfakkU3eY/P4kwBXwWCUMGpZds9tCmcLYTfro=;
b=R0Yx6/7txxohn5AXYb+k7YBHd+0P5jig/YzZgClM5km4N6sYnK2JTMBz34bdY/yo99
NwL8F/wcewLsZIilF3xbzOb3yXnCQxjbcty4aJPzqwzEBMvKZPxsPhPxTzBb+o5GJiK0
9Ru9KYjzawsCesDkO/3I/KKwtmvvNUNjKibXQwEB0I/PM+V37Z9eG+Xarfmb7+kLG0Sl
uX3Rh9lUjynOr3w+QIPNx4aqwnOASg7sQLZmlNqbbGAKZdwsZeG2ERcYeenkvPgyS87V
oRLWoZLb9rIOTETJhEi0Ge3gVWZYG4SN+INrnd9HO9rIKOcbmGfzutoCEnZljTfkc7AA
jhRg==
MIME-Version: 1.0
X-Received: by 10.50.90.180 with SMTP id bx20mr39601527igb.53.1441698316038;
Tue, 08 Sep 2015 00:45:16 -0700 (PDT)
Received: by 10.107.178.12 with HTTP; Tue, 8 Sep 2015 00:45:16 -0700 (PDT)
Date: Tue, 8 Sep 2015 17:45:16 +1000
Message-ID: <CAG0bcYzzg4yeQvd27PZu5Fqv1ULS3cKeQHaRZ2zPcM3OASw1cg@mail.gmail.com>
From: Washington Sanchez <washington.sanchez@gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=047d7bea3d28003a43051f378cb4
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_05,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,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
Subject: [bitcoin-dev] Dynamic limit to the block size - BIP draft discussion
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: Tue, 08 Sep 2015 07:45:17 -0000
--047d7bea3d28003a43051f378cb4
Content-Type: text/plain; charset=UTF-8
Hi everyone,
I know many of us feel that the last thing the Bitcoin community needs is
another BIP related to the block size, but after a lot of reading and
commenting, I'd like to throw this idea out there.
I've already written it up as a BIP and would like some constructive
feedback/suggestions/alternatives related to some of the variables in my
specification:
Dynamic limit to the block size
=======================
The goal is to dynamically increase the maximum block size conservatively,
but allow meaningful relief to transaction volume pressure in response to
true market demand. The specification follows:
- Every 4032 blocks (~4 weeks), the maximum block size will be increased by
10% *IF* a minimum of 2000 blocks has a size >= 60% of the maximum block
size at that time
+ This calculates to theoretically 13 increases per year
- The maximum block size can only ever be increased, not decreased
For example, if this rule were to be instituted January 1st 2016, with a
present maximum block size 1 MB, the limit would be increased to 1.1 MB on
January 29th 2016. The theoretical maximum block size at the end of 2016
would be ~3.45 MB, assuming all 13 increases are triggered.
As the maximum block size rises, so the cost of artificially triggering an
increase in the maximum block size.
Regards,
Wash
-------------------------------------------
*Dr Washington Y. Sanchez <http://onename.com/drwasho>*
Co-founder, OB1 <http://ob1.io>
Core developer of OpenBazaar <https://openbazaar.org>
@drwasho <https://twitter.com/drwasho>
--047d7bea3d28003a43051f378cb4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi everyone,<div><br></div><div>I know many of us feel tha=
t the last thing the Bitcoin community needs is another BIP related to the =
block size, but after a lot of reading and commenting, I'd like to thro=
w this idea out there.=C2=A0</div><div><br></div><div>I've already writ=
ten it up as a BIP and would like some constructive feedback/suggestions/al=
ternatives related to some of the variables in my specification:</div><div>=
<br></div><div><br></div><div>Dynamic limit to the block size</div><div>=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</div><di=
v><br></div><div>The goal is to dynamically increase the maximum block size=
conservatively, but allow meaningful relief to transaction volume pressure=
in response to true market demand. The specification follows:</div><div><b=
r></div><div><div>- Every 4032 blocks (~4 weeks), the maximum block size wi=
ll be increased by 10% *IF* a minimum of 2000 blocks has a size >=3D 60%=
of the maximum block size at that time</div><div>=C2=A0 + This calculates =
to theoretically 13 increases per year=C2=A0</div><div>- The maximum block =
size can only ever be increased, not decreased</div><div>=C2=A0</div><div>F=
or example, if this rule were to be instituted January 1st 2016, with a pre=
sent maximum block size 1 MB, the limit would be increased to 1.1 MB on Jan=
uary 29th 2016. The theoretical maximum block size at the end of 2016 would=
be ~3.45 MB, assuming all 13 increases are triggered.</div><div><br></div>=
<div>As the maximum block size rises, so the cost of artificially triggerin=
g an increase in the maximum block size.</div><div><br></div><div><br></div=
><div>Regards,</div><div>Wash</div><div><br></div><br><div class=3D"gmail_s=
ignature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div><div>----------------=
---------------------------</div><div><b><a href=3D"http://onename.com/drwa=
sho" target=3D"_blank">Dr Washington Y. Sanchez</a></b></div><div>Co-founde=
r, <a href=3D"http://ob1.io" target=3D"_blank">OB1</a></div><div>Core devel=
oper of <a href=3D"https://openbazaar.org" target=3D"_blank">OpenBazaar</a>=
</div><div><a href=3D"https://twitter.com/drwasho" target=3D"_blank">@drwas=
ho</a></div></div><div><br></div></div></div></div></div>
</div></div>
--047d7bea3d28003a43051f378cb4--
|
