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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jim@ergophobia.org>) id 1Yx4aS-0001hn-DO
for bitcoin-development@lists.sourceforge.net;
Tue, 26 May 2015 02:27:24 +0000
X-ACL-Warn:
Received: from mail-wi0-f171.google.com ([209.85.212.171])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Yx4aP-0001wr-3b
for bitcoin-development@lists.sourceforge.net;
Tue, 26 May 2015 02:27:24 +0000
Received: by wizk4 with SMTP id k4so62026328wiz.1
for <bitcoin-development@lists.sourceforge.net>;
Mon, 25 May 2015 19:27:13 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc:content-type;
bh=Vra5KrbunE4eW9m5nnUCta9BeXhUMYtfmSAAsN9NTL0=;
b=CYMwXs+KIsFA+od4bmtgMvoEtKLERtMhJIVgsmJ6/RYjmbL7VbKWlsqLUGAqeNikIR
UC/JagDJ7d3RF/Z+A/j4FKSiHgkuwc8GHg3QoMWg2t1N/1vkchbRz1dYY5NAKQKSntM2
ry8Z1p9DwZrU+vHPijOszNL2EtxaO8GXBLONw85PSZiFX52UC4fTl4jNF5FgTZ2lpvLU
KqtKm2CWxCZ3DeL0/Ps3MlqhcL/lqc0UpaqZuJ+FikiXpSAvlGJeVNsd91OTd1jKC706
htOUR21pMkWhPx3+J6WrmRTYUiDmERMBxd9HLOu/82fWxnC93Lox5FwvxuaO0TwO4NNu
9kVA==
X-Gm-Message-State: ALoCoQmSsXXScqW6sAnrbcYC9LuGnxFCE60L3DMjqDlhHzb5V0oCwBKn0AXghcuLtyp2SyBYFChm
X-Received: by 10.180.75.8 with SMTP id y8mr4067722wiv.31.1432607233000; Mon,
25 May 2015 19:27:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.194.246.69 with HTTP; Mon, 25 May 2015 19:26:42 -0700 (PDT)
In-Reply-To: <CANEZrP3AbNOW8G-4SyNZNLbD56TrB9c0zz8SCZPFacxDzDVt=g@mail.gmail.com>
References: <5554BDC1.6070206@thinlink.com>
<CANEZrP3AbNOW8G-4SyNZNLbD56TrB9c0zz8SCZPFacxDzDVt=g@mail.gmail.com>
From: Jim Phillips <jim@ergophobia.org>
Date: Mon, 25 May 2015 21:26:42 -0500
Message-ID: <CANe1mWz4qTOw8JYC-m8x6ajdLfm+Y__L1jn+W0HmNhCJ0tX4Kw@mail.gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=f46d043c7b9c39d7bd0516f2ddf8
X-Spam-Score: 1.0 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
1.0 HTML_MESSAGE BODY: HTML included in message
0.0 T_REMOTE_IMAGE Message contains an external image
X-Headers-End: 1Yx4aP-0001wr-3b
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] No Bitcoin For You
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Tue, 26 May 2015 02:27:24 -0000
--f46d043c7b9c39d7bd0516f2ddf8
Content-Type: text/plain; charset=UTF-8
On Mon, May 25, 2015 at 1:36 PM, Mike Hearn <mike@plan99.net> wrote:
This meme about datacenter-sized nodes has to die. The Bitcoin wiki is down
> right now, but I showed years ago that you could keep up with VISA on a
> single well specced server with today's technology. Only people living in a
> dreamworld think that Bitcoin might actually have to match that level of
> transaction demand with today's hardware. As noted previously, "too many
> users" is simply not a problem Bitcoin has .... and may never have!
>
>
... And will certainly NEVER have if we can't solve the capacity problem
SOON.
In a former life, I was a capacity planner for Bank of America's mid-range
server group. We had one hard and fast rule. When you are typically
exceeding 75% of capacity on a given metric, it's time to expand capacity.
Period. You don't do silly things like adjusting the business model to
disincentivize use. Unless there's some flaw in the system and it's leaking
resources, if usage has increased to the point where you are at or near the
limits of capacity, you expand capacity. It's as simple as that, and I've
found that same rule fits quite well in a number of systems.
In Bitcoin, we're not leaking resources. There's no flaw. The system is
performing as intended. Usage is increasing because it works so well, and
there is huge potential for future growth as we identify more uses and
attract more users. There might be a few technical things we can do to
reduce consumption, but the metric we're concerned with right now is how
many transactions we can fit in a block. We've broken through the 75%
marker and are regularly bumping up against the 100% limit.
It is time to stop debating this and take action to expand capacity. The
only questions that should remain are how much capacity do we add, and how
soon can we do it. Given that most existing computer systems and networks
can easily handle 20MB blocks every 10 minutes, and given that that will
increase capacity 20-fold, I can't think of a single reason why we can't go
to 20MB as soon as humanly possible. And in a few years, when the average
block size is over 15MB, we bump it up again to as high as we can go then
without pushing typical computers or networks beyond their capacity. We can
worry about ways to slow down growth without affecting the usefulness of
Bitcoin as we get closer to the hard technical limits on our capacity.
And you know what else? If miners need higher fees to accommodate the costs
of bigger blocks, they can configure their nodes to only mine transactions
with higher fees.. Let the miners decide how to charge enough to pay for
their costs. We don't need to cripple the network just for them.
--
*James G. Phillips IV*
<https://plus.google.com/u/0/113107039501292625391/posts>
*"Don't bunt. Aim out of the ball park. Aim for the company of immortals."
-- David Ogilvy*
*This message was created with 100% recycled electrons. Please think twice
before printing.*
--f46d043c7b9c39d7bd0516f2ddf8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Mon, May 25, 2015 at 1:36 PM, Mike Hearn <span dir=3D"ltr"><<a href=
=3D"mailto:mike@plan99.net" target=3D"_blank">mike@plan99.net</a>></span=
> wrote:</div><div class=3D"gmail_quote"><br><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-col=
or:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"l=
tr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>This meme ab=
out datacenter-sized nodes has to die. The Bitcoin wiki is down right now, =
but I showed years ago that you could keep up with VISA on a single well sp=
ecced server with today's technology. Only people living in a dreamworl=
d think that Bitcoin might actually have to match that level of transaction=
demand with today's hardware. As noted previously, "too many user=
s" is simply not a problem Bitcoin has .... and may never have!</div><=
div><br></div></div></div></div>
</blockquote></div><br></div><div class=3D"gmail_extra">... And will certai=
nly NEVER have if we can't solve the capacity problem SOON.=C2=A0</div>=
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">In a former=
life, I was a capacity planner for Bank of America's mid-range server =
group. We had one hard and fast rule. When you are typically exceeding 75% =
of capacity on a given metric, it's time to expand capacity. Period. Yo=
u don't do silly things like adjusting the business model to disincenti=
vize use. Unless there's some flaw in the system and it's leaking r=
esources, if usage has increased to the point where you are at or near the =
limits of capacity, you expand capacity. It's as simple as that, and I&=
#39;ve found that same rule fits quite well in a number of systems.=C2=A0</=
div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">In Bitc=
oin, we're not leaking resources. There's no flaw. The system is pe=
rforming as intended. Usage is increasing because it works so well, and the=
re is huge potential for future growth as we identify more uses and attract=
more users. There might be a few technical things we can do to reduce cons=
umption, but the metric we're concerned with right now is how many tran=
sactions we can fit in a block. We've broken through the 75% marker and=
are regularly bumping up against the 100% limit.</div><div class=3D"gmail_=
extra"><br></div><div class=3D"gmail_extra">It is time to stop debating thi=
s and take action to expand capacity. The only questions that should remain=
are how much capacity do we add, and how soon can we do it. Given that mos=
t existing computer systems and networks can easily handle 20MB blocks ever=
y 10 minutes, and given that that will increase capacity 20-fold, I can'=
;t think of a single reason why we can't go to 20MB as soon as humanly =
possible. And in a few years, when the average block size is over 15MB, we =
bump it up again to as high as we can go then without pushing typical compu=
ters or networks beyond their capacity. We can worry about ways to slow dow=
n growth without affecting the usefulness of Bitcoin as we get closer to th=
e hard technical limits on our capacity.</div><div class=3D"gmail_extra"><b=
r></div><div class=3D"gmail_extra">And you know what else? If miners need h=
igher fees to accommodate the costs of bigger blocks, they can configure th=
eir nodes to only mine transactions with higher fees.. Let the miners decid=
e how to charge enough to pay for their costs. We don't need to cripple=
the network just for them.</div><div class=3D"gmail_extra"><br clear=3D"al=
l"><div><div class=3D"gmail_signature"><div>--<div><b>James G. Phillips IV<=
/b>=C2=A0<a href=3D"https://plus.google.com/u/0/113107039501292625391/posts=
" target=3D"_blank" style=3D"font-size:x-small"><img src=3D"https://ssl.gst=
atic.com/images/icons/gplus-16.png"></a>=C2=A0</div></div><div><font size=
=3D"1"><i>"Don't bunt. Aim out of the ball park. Aim for the compa=
ny of immortals." -- David Ogilvy<br></i></font><div><font size=3D"1">=
<br></font></div></div><div><font size=3D"1"><img src=3D"http://findicons.c=
om/files/icons/1156/fugue/16/leaf.png">=C2=A0<em style=3D"font-family:verda=
na,geneva,sans-serif;line-height:16px;color:green">This message was created=
with 100% recycled electrons. Please think twice before printing.</em></fo=
nt></div><div><font size=3D"1"><em style=3D"font-family:verdana,geneva,sans=
-serif;line-height:16px;color:green"><br></em></font></div></div></div></di=
v></div>
--f46d043c7b9c39d7bd0516f2ddf8--
|
