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
|
Return-Path: <wardell.c@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 3926640C
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 17 Jul 2015 19:06:35 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yk0-f172.google.com (mail-yk0-f172.google.com
[209.85.160.172])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 71F4714F
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 17 Jul 2015 19:06:34 +0000 (UTC)
Received: by ykay190 with SMTP id y190so96979134yka.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 17 Jul 2015 12:06:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:content-type; bh=zMq1lxlHLzYb9RcHqFrZpjaLEtAuEyWFElReZXAytqA=;
b=KEx/72Ku6bgapesbWTCwao/XhTMes0LAIgLeZfGmGJw4m/H2wyAA7j7n+Aa8o6DG51
Iizrkh5VkHo5OH8k5srN+cW4J3k132YksZ3rBd9HPZMtxWmP21pms4fYUyVJ+b6n83Jn
kOGMVQGlTxxsVIOs99FEv9NFZaQ2N3+s2WKJX8/52re6G8//1lla6DnztdEBZHIoYmqx
hS319HN3cWWA/e1uUnYSuIHrRhDKvRkV9sQGgMYSLEdsL+3MBcKzQMDLm2Vk0KnpRqXM
UuGQATBjX6lXz0/ebKrOdjAqmkL/6u9Cw3ZzNYdQ8impB6DjTbEBk0em8enQ9+ZDMmFn
WWSw==
MIME-Version: 1.0
X-Received: by 10.170.143.213 with SMTP id k204mr16629363ykc.91.1437159993717;
Fri, 17 Jul 2015 12:06:33 -0700 (PDT)
Received: by 10.37.76.135 with HTTP; Fri, 17 Jul 2015 12:06:33 -0700 (PDT)
In-Reply-To: <55A9421B.6040605@jrn.me.uk>
References: <CADm_WcZKoMAhYvXbFMbE+5K9HOD75YkQu8_qTW4S6YN6ZMrfjA@mail.gmail.com>
<55A9421B.6040605@jrn.me.uk>
Date: Fri, 17 Jul 2015 15:06:33 -0400
Message-ID: <CAEieSeQs4OmyKr4AMcXhZfRccwPApzNJyd06yhRTOjYywsVLsQ@mail.gmail.com>
From: Chris Wardell <wardell.c@gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=001a1139909ce93d58051b16e29d
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,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: Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB
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: Fri, 17 Jul 2015 19:06:35 -0000
--001a1139909ce93d58051b16e29d
Content-Type: text/plain; charset=UTF-8
I would prefer a dynamic solution that did not necessitate a second hard
fork down the road.
I propose doubling the block size every 100k blocks (~2 years)
block 400,000 = 2MB (2016)
block 500,000 = 4MB (2017)
block 600,000 = 8MB (2018)
Chris
On Fri, Jul 17, 2015 at 1:57 PM, Ross Nicoll via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> I'd back this if we can't find a permanent solution - 2MB gives us a lot
> more wiggle room in the interim at least; one of my concerns with block
> size is 3 transactions per second is absolutely tiny, and we need space for
> the network to search for an equilibrium between volume and pricing without
> risk of an adoption spike rendering it essentially unusable.
>
> I'd favour switching over by block height rather than time, and I'd
> suggest that given virtually every wallet/node out there will require
> testing (even if many do not currently enforce a limit and therefore do not
> need changing), 6 months should be considered a minimum target. I'd open
> with a suggestion of block 390k as a target.
>
> Ross
>
>
> On 17/07/2015 16:55, Jeff Garzik via bitcoin-dev wrote:
>
> Opening a mailing list thread on this BIP:
>
> BIP PR: https://github.com/bitcoin/bips/pull/173
> Code PR: https://github.com/bitcoin/bitcoin/pull/6451
>
> The general intent of this BIP is as a minimum viable alternative plan
> to my preferred proposal (BIP 100).
>
> If agreement is not reached on a more comprehensive solution, then this
> solution is at least available and a known quantity. A good backup plan.
>
> Benefits: conservative increase. proves network can upgrade. permits
> some added growth, while the community & market gathers data on how an
> increased block size impacts privacy, security, centralization, transaction
> throughput and other metrics. 2MB seems to be a Least Common Denominator
> on an increase.
>
> Costs: requires a hard fork. requires another hard fork down the road.
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing listbitcoin-dev@lists.linuxfoundation.orghttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--001a1139909ce93d58051b16e29d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div><div><div>I would prefer a dynamic solution=
that did not necessitate a second hard fork down the road.<br><br></div>I =
propose doubling the block size every 100k blocks (~2 years)<br><br></div>b=
lock 400,000 =3D 2MB (2016)<br></div>block 500,000 =3D 4MB (2017)<br></div>=
block 600,000 =3D 8MB (2018)<br><br></div>Chris<br><div><div><br></div></di=
v></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, J=
ul 17, 2015 at 1:57 PM, Ross Nicoll via bitcoin-dev <span dir=3D"ltr"><<=
a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">b=
itcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
I'd back this if we can't find a permanent solution - 2MB gives=
us a
lot more wiggle room in the interim at least; one of my concerns
with block size is 3 transactions per second is absolutely tiny, and
we need space for the network to search for an equilibrium between
volume and pricing without risk of an adoption spike rendering it
essentially unusable.<br>
<br>
I'd favour switching over by block height rather than time, and I&#=
39;d
suggest that given virtually every wallet/node out there will
require testing (even if many do not currently enforce a limit and
therefore do not need changing), 6 months should be considered a
minimum target. I'd open with a suggestion of block 390k as a
target.<br>
<br>
Ross<div><div class=3D"h5"><br>
<br>
<div>On 17/07/2015 16:55, Jeff Garzik via
bitcoin-dev wrote:<br>
</div>
</div></div><blockquote type=3D"cite"><div><div class=3D"h5">
<div dir=3D"ltr">
<div>Opening a mailing list thread on this BIP:</div>
<div><br>
</div>
BIP PR:=C2=A0<a href=3D"https://github.com/bitcoin/bips/pull/173" t=
arget=3D"_blank">https://github.com/bitcoin/bips/pull/173</a>
<div>Code PR:=C2=A0<a href=3D"https://github.com/bitcoin/bitcoin/pu=
ll/6451" target=3D"_blank">https://github.com/bitcoin/bitcoin/pull/6451</a>=
</div>
<div><br>
</div>
<div>The general intent of this BIP is as a minimum viable
alternative plan to my preferred proposal (BIP 100).</div>
<div><br>
</div>
<div>If agreement is not reached on a more comprehensive
solution, then this solution is at least available and a known
quantity.=C2=A0 A good backup plan.</div>
<div><br>
</div>
<div>Benefits: =C2=A0conservative increase. =C2=A0proves network ca=
n
upgrade. =C2=A0permits some added growth, while the community &am=
p;
market gathers data on how an increased block size impacts
privacy, security, centralization, transaction throughput and
other metrics. =C2=A02MB seems to be a Least Common Denominator o=
n
an increase.</div>
<div><br>
</div>
<div>Costs: =C2=A0requires a hard fork. =C2=A0requires another hard=
fork
down the road.</div>
<div><br>
</div>
<div><br>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
</div></div><span class=3D""><pre>___________________________________=
____________
bitcoin-dev mailing list
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
target=3D"_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoi=
n-dev</a>
</pre>
</span></blockquote>
<br>
</div>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div><br></div>
--001a1139909ce93d58051b16e29d--
|
