summaryrefslogtreecommitdiff
path: root/84/1cec21c2c05ca6d80ddd9dd90d2f2b93b59aec
blob: e8b8182e5517551244cdc33cb1853204313cc489 (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
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 C0C17279
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 19 Jul 2015 22:51:10 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from homiemail-a7.g.dreamhost.com (homie.mail.dreamhost.com
	[208.97.132.208])
	by smtp1.linuxfoundation.org (Postfix) with ESMTP id 0802FE9
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 19 Jul 2015 22:51:09 +0000 (UTC)
Received: from homiemail-a7.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a7.g.dreamhost.com (Postfix) with ESMTP id 61B2125C072
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 19 Jul 2015 15:51:09 -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=YS2dfpktmsvp9zIH1fXDVGX0M3A=; b=sL
	gGDs8h7TvS1R9cmWoLgdb8zAY+xDBHjk0LcpgOm7Q+2jcdwPpmjX9ul4jkPtcDL1
	AccI/oa6lezRoZbNFqJaT/+RL+rHILcgR//PWEOWF9DveVErfl5UU2tAE6pNJMil
	uAvABgybtPAlLvYb2LlemAVhRjaGnIaGYozc5L54E=
Received: from [192.168.0.4] (cpc12-cmbg17-2-0-cust830.5-4.cable.virginm.net
	[86.30.131.63])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	(Authenticated sender: jrn@jrn.me.uk)
	by homiemail-a7.g.dreamhost.com (Postfix) with ESMTPSA id D9B7B25C075
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 19 Jul 2015 15:51:08 -0700 (PDT)
To: bitcoin-dev@lists.linuxfoundation.org
References: <CADm_WcZKoMAhYvXbFMbE+5K9HOD75YkQu8_qTW4S6YN6ZMrfjA@mail.gmail.com>
	<55A9421B.6040605@jrn.me.uk>
From: Ross Nicoll <jrn@jrn.me.uk>
Message-ID: <55AC29DB.4060800@jrn.me.uk>
Date: Sun, 19 Jul 2015 23:51:07 +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: <55A9421B.6040605@jrn.me.uk>
Content-Type: multipart/alternative;
	boundary="------------090007010103030407090103"
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: Sun, 19 Jul 2015 22:51:10 -0000

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

Further to that - please disregard what I said about using block height. 
Had failed to realise that in using contextual information (block 
height) it complicates block validation (i.e. it would be impossible to 
tell if a block is too big, without having all previous blocks first). 
Block time is in fact the better option.

Ross

On 17/07/2015 18:57, Ross Nicoll via bitcoin-dev 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
>> 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


--------------090007010103030407090103
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">
    Further to that - please disregard what I said about using block
    height. Had failed to realise that in using contextual information
    (block height) it complicates block validation (i.e. it would be
    impossible to tell if a block is too big, without having all
    previous blocks first). Block time is in fact the better option.<br>
    <br>
    Ross<br>
    <br>
    <div class=3D"moz-cite-prefix">On 17/07/2015 18:57, Ross Nicoll via
      bitcoin-dev wrote:<br>
    </div>
    <blockquote cite=3D"mid:55A9421B.6040605@jrn.me.uk" type=3D"cite">
      <meta content=3D"text/html; charset=3Dwindows-1252"
        http-equiv=3D"Content-Type">
      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'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<br>
      <br>
      <div class=3D"moz-cite-prefix">On 17/07/2015 16:55, Jeff Garzik via
        bitcoin-dev wrote:<br>
      </div>
      <blockquote
cite=3D"mid:CADm_WcZKoMAhYvXbFMbE+5K9HOD75YkQu8_qTW4S6YN6ZMrfjA@mail.gmai=
l.com"
        type=3D"cite">
        <div dir=3D"ltr">
          <div>Opening a mailing list thread on this BIP:</div>
          <div><br>
          </div>
          BIP PR:=A0<a moz-do-not-send=3D"true"
            href=3D"https://github.com/bitcoin/bips/pull/173">https://git=
hub.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">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.=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 f=
ork
            down the road.</div>
          <div><br>
          </div>
          <div><br>
          </div>
        </div>
        <br>
        <fieldset class=3D"mimeAttachmentHeader"></fieldset>
        <br>
        <pre wrap=3D"">_______________________________________________
bitcoin-dev mailing list
<a moz-do-not-send=3D"true" class=3D"moz-txt-link-abbreviated" href=3D"ma=
ilto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfounda=
tion.org</a>
<a moz-do-not-send=3D"true" class=3D"moz-txt-link-freetext" href=3D"https=
://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.=
linuxfoundation.org/mailman/listinfo/bitcoin-dev</a>
</pre>
      </blockquote>
      <br>
      <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>

--------------090007010103030407090103--