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
|
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 1C97C8B4
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 23 Jun 2015 07:35:38 +0000 (UTC)
X-Greylist: delayed 10:03:25 by SQLgrey-1.7.6
Received: from homiemail-a8.g.dreamhost.com (homie.mail.dreamhost.com
[208.97.132.208])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id 7499DA8
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 23 Jun 2015 07:35:37 +0000 (UTC)
Received: from homiemail-a8.g.dreamhost.com (localhost [127.0.0.1])
by homiemail-a8.g.dreamhost.com (Postfix) with ESMTP id B350DD22070
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 23 Jun 2015 00:35:36 -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=DkqMhy6CLlx4ByhyxNP8FuxSAUM=; b=Gc
Q1j4uXld3vPkmXXLFJH/Q2CprPuWeFya5nIUtPKhc5vvNlDx7vvCTkEJS2JKIwMi
acvdKofzBCJj4KXxP18JO9WyPjH64ZVDOdFiAyLcGkAWRcukYiWMg6MfbYJ1a41A
78P+Qwj1gABRrQUH7bEimoQLels4oN9fxd5erGVMw=
Received: from [192.168.0.6] (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-a8.g.dreamhost.com (Postfix) with ESMTPSA id 54550D22074
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 23 Jun 2015 00:35:36 -0700 (PDT)
To: bitcoin-dev@lists.linuxfoundation.org
References: <CABsx9T2HegqOBqd1jijk1bZBE6N+NH8x6nfwbaoLBACVf8-WBQ@mail.gmail.com>
<20150622192308.GA23545@savin.petertodd.org>
From: Ross Nicoll <jrn@jrn.me.uk>
Message-ID: <55890C4C.3070909@jrn.me.uk>
Date: Tue, 23 Jun 2015 08:35:40 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101
Thunderbird/38.0.1
MIME-Version: 1.0
In-Reply-To: <20150622192308.GA23545@savin.petertodd.org>
Content-Type: multipart/alternative;
boundary="------------030703040606090100070205"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE 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] Draft BIP : fixed-schedule block size increase
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, 23 Jun 2015 07:35:38 -0000
This is a multi-part message in MIME format.
--------------030703040606090100070205
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
I don't think essentially replacing most of Testnet with a specialised
test chain is a good idea, but this might be a good time to consider a
4th test network with very large blocks from genesis onwards.
I do tend to think 2 years of 8mb blocks is excessive as a test, too,
and while certainly large projects should have or can raise funds for
test infrastructure, I would worry about the smaller stuff out there. Is
there anything specific 2 years gives us over, say, 6 months?
Ross
On 22/06/2015 20:23, Peter Todd wrote:
> On Mon, Jun 22, 2015 at 02:18:19PM -0400, Gavin Andresen wrote:
>> I promised to write a BIP after I'd implemented
>> increase-the-maximum-block-size code, so here it is. It also lives at:
>> https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki
> It's important that we see a wide range of realistic testing of what an
> 8MB limit could look in the near future. An important part of that
> testing is load testing.
>
> As of writing the BIP above has no mention of what switchover rules will
> be used for testnet; code floating around has August 1st 2015 as that
> date. I propose we use August 1st 2013.
>
> This switch over date should be set in the _past_ to allow for the
> creation (via reorg) of a realistic full-load blockchain on testnet to
> fully test the real-world behavior of the entire infrastructure
> ecosystem, including questions like the scalability of block explorers,
> SPV wallets, feasibility of initial syncronization, scalability of the
> UTXO set, etc. While this is of course inconvenient - 2 years of 8MB
> blocks is 840GB worth of data - the Bitcoin ecosystem can-not afford to
> make a change like this blindly.
>
> I'm sure with a $3.5 billion market cap at stake we can scrape together
> the resources to voluntarily run a few hundred full-load full-nodes for
> testing a change with the potential to destroy that market cap.
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--------------030703040606090100070205
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
I don't think essentially replacing most of Testnet with a
specialised test chain is a good idea, but this might be a good time
to consider a 4th test network with very large blocks from genesis
onwards.<br>
<br>
I do tend to think 2 years of 8mb blocks is excessive as a test,
too, and while certainly large projects should have or can raise
funds for test infrastructure, I would worry about the smaller stuff
out there. Is there anything specific 2 years gives us over, say, 6
months?<br>
<br>
Ross<br>
<br>
<div class="moz-cite-prefix">On 22/06/2015 20:23, Peter Todd wrote:<br>
</div>
<blockquote cite="mid:20150622192308.GA23545@savin.petertodd.org"
type="cite">
<pre wrap="">On Mon, Jun 22, 2015 at 02:18:19PM -0400, Gavin Andresen wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I promised to write a BIP after I'd implemented
increase-the-maximum-block-size code, so here it is. It also lives at:
<a class="moz-txt-link-freetext" href="https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki">https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki</a>
</pre>
</blockquote>
<pre wrap="">
It's important that we see a wide range of realistic testing of what an
8MB limit could look in the near future. An important part of that
testing is load testing.
As of writing the BIP above has no mention of what switchover rules will
be used for testnet; code floating around has August 1st 2015 as that
date. I propose we use August 1st 2013.
This switch over date should be set in the _past_ to allow for the
creation (via reorg) of a realistic full-load blockchain on testnet to
fully test the real-world behavior of the entire infrastructure
ecosystem, including questions like the scalability of block explorers,
SPV wallets, feasibility of initial syncronization, scalability of the
UTXO set, etc. While this is of course inconvenient - 2 years of 8MB
blocks is 840GB worth of data - the Bitcoin ecosystem can-not afford to
make a change like this blindly.
I'm sure with a $3.5 billion market cap at stake we can scrape together
the resources to voluntarily run a few hundred full-load full-nodes for
testing a change with the potential to destroy that market cap.
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
bitcoin-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>
<a class="moz-txt-link-freetext" href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>
--------------030703040606090100070205--
|
