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
|
Return-Path: <gavinandresen@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 35586273
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 22 Jun 2015 19:54:29 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-la0-f47.google.com (mail-la0-f47.google.com
[209.85.215.47])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 671A4E3
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 22 Jun 2015 19:54:28 +0000 (UTC)
Received: by laka10 with SMTP id a10so116697771lak.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 22 Jun 2015 12:54:26 -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
:cc:content-type;
bh=QB7Fr7YLfMFd5df4/PQWzUSLod3YF+n3aH9+H7VkxeM=;
b=R2wthFLfM0b7yAXxFUhxmvkyQJMgMzqyeV64mRyUs7gOq+eTIzYc0lWxoGEp7rGUtV
XB974C6fIyLBzj5eJdPaT2RiRvU4pyTEXSk/Jhy2Vbm5Zd6BeRXqHVukdw6kb4Yl6yqn
HVXznbvkacsSEkgHtnveVDMM1VOwRnwmlR0DM3/ez1VSXrlejlXYRd7A42gCFSR8b6bA
JMhyiiwAC9fzcGKRHKa5Q57PE6mDq5f1imDM827QmP2jdtYFdUWvxYDc0ICjpt4HkNLK
58Wfs/MdghgniDoWRjnusWYRjXLdMPBTwjkWCYhQDDcQfLj1mipnI2LjCyWJVpsVn73c
CirQ==
MIME-Version: 1.0
X-Received: by 10.152.115.199 with SMTP id jq7mr3766420lab.113.1435002866689;
Mon, 22 Jun 2015 12:54:26 -0700 (PDT)
Received: by 10.25.90.75 with HTTP; Mon, 22 Jun 2015 12:54:26 -0700 (PDT)
In-Reply-To: <CAE-z3OWqiGPPNVxBVU0mx+TKFuysKrhXpwg6gOFcwGBQx26VtQ@mail.gmail.com>
References: <CABsx9T2HegqOBqd1jijk1bZBE6N+NH8x6nfwbaoLBACVf8-WBQ@mail.gmail.com>
<55885DB0.9040709@gmail.com>
<CAE-z3OWqiGPPNVxBVU0mx+TKFuysKrhXpwg6gOFcwGBQx26VtQ@mail.gmail.com>
Date: Mon, 22 Jun 2015 15:54:26 -0400
Message-ID: <CABsx9T0t=o9f6KxVDP01iPRErUCZS8nzO438T_bkLE-4kQV7hw@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Tier Nolan <tier.nolan@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c2588e1eee7b051920a499
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
Cc: bitcoin-dev@lists.linuxfoundation.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: Mon, 22 Jun 2015 19:54:29 -0000
--001a11c2588e1eee7b051920a499
Content-Type: text/plain; charset=UTF-8
As Tier says, the current network message limit is 2MB (reduced from 32MB
in the... uhh, 0.10? release).
I think keeping the consensus rules distinct from limitations of the p2p
network makes sense-- we are already seeing different protocols for
announcing transactions and blocks (Matt's relay network is, essentially, a
separate protocol). I could write a separate BIP describing the change to
the p2p network protocol, but that feels like busy-work to me.
RE: setting the DoS size check farther than 2 hours into the future: the
block, itself, will be rejected if it has a timestamp more than 2 hours in
the future. That is already a consensus rule.
RE: what happens if block timestamps are not in chronological order:
Nothing.
The activation counting happens in block-height-order, so timestamps on all
but the "activating" block are all that matters.
Code that looks for the activation condition must properly handle re-orgs
around the activation block, of course.
RE: testnet parameters: big blocks can be tested in -regtest mode with
arbitrary timestamps in the past or future. Testing maximum-8MB-blocks
mined "in the past" on testnet will just result in a testnet that is even
more useless for ordinary testing of products or services being developed
-- part of what makes testnet useful for things like testing transaction
creation code is it syncs quickly.
That said, I have thought for a while now somebody should take a fresh look
at the testnet, talk to people who might be customers for a reset testnet
or testnets (we probably want separate testnets for people testing mining
and people testing transaction creation, for example), and implement
testnets designed to make it easy to test what people need testing.
RE: scraping together money to run a few hundred full-load full-nodes:
hardware is cheap, people are expensive. You seem to expect that companies
will be willing to invest the time of their people testing something that
may never happen (8MB of transactions every ten minutes). Maybe they would,
but most companies are very busy trying to stay in business by attracting
customers to their products or services. Scaling up is a good problem to
have, and, in my experience, the way to be successful scaling up is to
tackle problems as they occur.
Because there's no use spending a bunch of person-hours hyper-optimizing
for 8MB blocks stored in MySQL if a year from now you find out your
customers don't actually want your product or MySQL 5.11 comes out and is
100 times faster....
--
--
Gavin Andresen
--001a11c2588e1eee7b051920a499
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">As Tier says, the current network message limit is 2MB (re=
duced from 32MB in the... uhh, 0.10? release).<div><br></div><div>I think k=
eeping the consensus rules distinct from limitations of the p2p network mak=
es sense-- we are already seeing different protocols for announcing transac=
tions and blocks (Matt's relay network is, essentially, a separate prot=
ocol). I could write a separate BIP describing the change to the p2p networ=
k protocol, but that feels like busy-work to me.<br><div><br></div><div>RE:=
setting the DoS size check farther than 2 hours into the future: the block=
, itself, will be rejected if it has a timestamp more than 2 hours in the f=
uture. That is already a consensus rule.</div></div><div><br></div><div>RE:=
what happens if block timestamps are not in chronological order: Nothing.<=
/div><div><br></div><div>The activation counting happens in block-height-or=
der, so timestamps on all but the "activating" block are all that=
matters.</div><div><br></div><div>Code that looks for the activation condi=
tion must properly handle re-orgs around the activation block, of course.</=
div><div><br></div><div><br></div><div>RE: testnet parameters: =C2=A0big bl=
ocks can be tested in -regtest mode with arbitrary timestamps in the past o=
r future. Testing maximum-8MB-blocks mined "in the past" on testn=
et will just result in a testnet that is even more useless for ordinary tes=
ting of products or services being developed -- part of what makes testnet =
useful for things like testing transaction creation code is it syncs quickl=
y.</div><div><br></div><div>That said, I have thought for a while now someb=
ody should take a fresh look at the testnet, talk to people who might be cu=
stomers for a reset testnet or testnets (we probably want separate testnets=
for people testing mining and people testing transaction creation, for exa=
mple), and implement testnets designed to make it easy to test what people =
need testing.</div><div class=3D"gmail_extra"><div class=3D"gmail_quote"><b=
r></div><div class=3D"gmail_quote">RE: scraping together money to run a few=
hundred full-load full-nodes: =C2=A0hardware is cheap, people are expensiv=
e. You seem to expect that companies will be willing to invest the time of =
their people testing something that may never happen (8MB of transactions e=
very ten minutes). Maybe they would, but most companies are very busy tryin=
g to stay in business by attracting customers to their products or services=
. Scaling up is a good problem to have, and, in my experience, the way to b=
e successful scaling up is to tackle problems as they occur.</div><div clas=
s=3D"gmail_quote"><br></div><div class=3D"gmail_quote">Because there's =
no use spending a bunch of person-hours hyper-optimizing for 8MB blocks sto=
red in MySQL if a year from now you find out your customers don't actua=
lly want your product or MySQL 5.11 comes out and is 100 times faster....</=
div><div class=3D"gmail_quote"><br></div>-- <br><div class=3D"gmail_signatu=
re">--<br>Gavin Andresen<br></div>
</div></div>
--001a11c2588e1eee7b051920a499--
|
