summaryrefslogtreecommitdiff
path: root/92/4d780ce79a227489108bb186da7c0cc1b8f43c
blob: 34f401ceef1476ac1b4a4e34deb55f9a3de4264d (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
Return-Path: <jrn@jrn.me.uk>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 61F3740A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 17 Jul 2015 19:13:15 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from homiemail-a61.g.dreamhost.com (homie.mail.dreamhost.com
	[208.97.132.208])
	by smtp1.linuxfoundation.org (Postfix) with ESMTP id BC04A136
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 17 Jul 2015 19:13:14 +0000 (UTC)
Received: from homiemail-a61.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a61.g.dreamhost.com (Postfix) with ESMTP id 38B82578078
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 17 Jul 2015 12:13:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=jrn.me.uk; h=subject:to
	:references:from:message-id:date:mime-version:in-reply-to:
	content-type; s=jrn.me.uk; bh=N4ddyiKEYPvY2QirLWVOit1EbFo=; b=HJ
	kRK7+3DyKdlhgqd3XNcxf2yRzH/O3dF7A68y5G/vQcyEytOj6X+adHva1Mb9AN3e
	J3gEQOA2rJR8i4idbINocaPoFSgasliHxv2qZYOZMt4IxfdTpu+yO7TU7FIIsyFm
	ik6e/nMmoDM0qiUY/fr0sHqSEJ0RZCT3ZwHVV1PHI=
Received: from [10.9.1.131] (unknown [89.238.129.18])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	(Authenticated sender: jrn@jrn.me.uk)
	by homiemail-a61.g.dreamhost.com (Postfix) with ESMTPSA id 9ABC557806E
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 17 Jul 2015 12:13:13 -0700 (PDT)
To: bitcoin-dev@lists.linuxfoundation.org
References: <CADm_WcZKoMAhYvXbFMbE+5K9HOD75YkQu8_qTW4S6YN6ZMrfjA@mail.gmail.com>
	<55A9421B.6040605@jrn.me.uk>
	<CAEieSeQs4OmyKr4AMcXhZfRccwPApzNJyd06yhRTOjYywsVLsQ@mail.gmail.com>
From: Ross Nicoll <jrn@jrn.me.uk>
Message-ID: <55A953CA.7020701@jrn.me.uk>
Date: Fri, 17 Jul 2015 20:13:14 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101
	Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <CAEieSeQs4OmyKr4AMcXhZfRccwPApzNJyd06yhRTOjYywsVLsQ@mail.gmail.com>
Content-Type: multipart/alternative;
	boundary="------------000807080405030507060300"
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,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:13:15 -0000

This is a multi-part message in MIME format.
--------------000807080405030507060300
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

I'll leave others to comment on whether we can get consensus on that, 
but your years listed are inconsistent with everything else you've 
written. Should be:

block 400,000 = 2MB (2016)
block 500,000 = 4MB (2018)
block 600,000 = 8MB (2020)

On 17/07/2015 20:06, Chris Wardell via bitcoin-dev wrote:
> 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 
> <mailto: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 list
>>     bitcoin-dev@lists.linuxfoundation.org
>>     <mailto:bitcoin-dev@lists.linuxfoundation.org>
>>     https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>     _______________________________________________
>     bitcoin-dev mailing list
>     bitcoin-dev@lists.linuxfoundation.org
>     <mailto: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


--------------000807080405030507060300
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta content=3D"text/html; charset=3Dwindows-1252"
      http-equiv=3D"Content-Type">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    I'll leave others to comment on whether we can get consensus on
    that, but your years listed are inconsistent with everything else
    you've written. Should be:<br>
    <br>
    block 400,000 =3D 2MB (2016)<br>
    block 500,000 =3D 4MB (2018)<br>
    block 600,000 =3D 8MB (2020)<br>
    <br>
    <div class=3D"moz-cite-prefix">On 17/07/2015 20:06, Chris Wardell via
      bitcoin-dev wrote:<br>
    </div>
    <blockquote
cite=3D"mid:CAEieSeQs4OmyKr4AMcXhZfRccwPApzNJyd06yhRTOjYywsVLsQ@mail.gmai=
l.com"
      type=3D"cite">
      <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>
              block 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>
        </div>
      </div>
      <div class=3D"gmail_extra"><br>
        <div class=3D"gmail_quote">On Fri, Jul 17, 2015 at 1:57 PM, Ross
          Nicoll via bitcoin-dev <span dir=3D"ltr">&lt;<a
              moz-do-not-send=3D"true"
              href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org"
              target=3D"_blank"><a class=3D"moz-txt-link-abbreviated" hre=
f=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linu=
xfoundation.org</a></a>&gt;</span>
          wrote:<br>
          <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div bgcolor=3D"#FFFFFF" text=3D"#000000"> I'd back this if w=
e
              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'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:</di=
v>
                      <div><br>
                      </div>
                      BIP PR:=A0<a moz-do-not-send=3D"true"
                        href=3D"https://github.com/bitcoin/bips/pull/173"
                        target=3D"_blank">https://github.com/bitcoin/bips=
/pull/173</a>
                      <div>Code PR:=A0<a moz-do-not-send=3D"true"
                          href=3D"https://github.com/bitcoin/bitcoin/pull=
/6451"
                          target=3D"_blank">https://github.com/bitcoin/bi=
tcoin/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.=A0 A good
                        backup plan.</div>
                      <div><br>
                      </div>
                      <div>Benefits: =A0conservative increase. =A0proves
                        network can upgrade. =A0permits some added growth=
,
                        while the community &amp; market gathers data on
                        how an increased block size impacts privacy,
                        security, centralization, transaction throughput
                        and other metrics. =A02MB seems to be a Least
                        Common Denominator on an increase.</div>
                      <div><br>
                      </div>
                      <div>Costs: =A0requires a hard fork. =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 moz-do-not-send=3D"true" href=3D"mailto:bitcoin-dev@lists.linuxfoundat=
ion.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>
<a moz-do-not-send=3D"true" href=3D"https://lists.linuxfoundation.org/mai=
lman/listinfo/bitcoin-dev" target=3D"_blank">https://lists.linuxfoundatio=
n.org/mailman/listinfo/bitcoin-dev</a>
</pre>
                </span></blockquote>
              <br>
            </div>
            <br>
            _______________________________________________<br>
            bitcoin-dev mailing list<br>
            <a moz-do-not-send=3D"true"
              href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitco=
in-dev@lists.linuxfoundation.org</a><br>
            <a moz-do-not-send=3D"true"
              href=3D"https://lists.linuxfoundation.org/mailman/listinfo/=
bitcoin-dev"
              rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfou=
ndation.org/mailman/listinfo/bitcoin-dev</a><br>
            <br>
          </blockquote>
        </div>
        <br>
      </div>
      <br>
      <fieldset class=3D"mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap=3D"">_______________________________________________
bitcoin-dev mailing list
<a class=3D"moz-txt-link-abbreviated" href=3D"mailto:bitcoin-dev@lists.li=
nuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>
<a class=3D"moz-txt-link-freetext" href=3D"https://lists.linuxfoundation.=
org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailm=
an/listinfo/bitcoin-dev</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>

--------------000807080405030507060300--