path: root/40/ede8b616907ea7c1ef03b090bd34eee86c907c

Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <thyshizzle@outlook.com>) id 1Yx4eS-0004Ey-OD
	for bitcoin-development@lists.sourceforge.net;
	Tue, 26 May 2015 02:31:32 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of outlook.com
	designates 65.54.190.215 as permitted sender)
	client-ip=65.54.190.215; envelope-from=thyshizzle@outlook.com;
	helo=BAY004-OMC4S13.hotmail.com; 
Received: from bay004-omc4s13.hotmail.com ([65.54.190.215])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.76) id 1Yx4eQ-0008NE-Fj
	for bitcoin-development@lists.sourceforge.net;
	Tue, 26 May 2015 02:31:32 +0000
Received: from BAY403-EAS278 ([65.54.190.201]) by BAY004-OMC4S13.hotmail.com
	over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751);
	Mon, 25 May 2015 19:31:24 -0700
X-TMN: [UeLOzFQF/nu/rms4rDn+OlF/mwG+8mKl]
X-Originating-Email: [thyshizzle@outlook.com]
Message-ID: <BAY403-EAS278EF7A9628FBB64F90CF09C2CC0@phx.gbl>
Content-Type: multipart/related;
	boundary="_35254d88-6edc-40d6-9c09-8d4ed66c6fb0_"
MIME-Version: 1.0
To: Jim Phillips <jim@ergophobia.org>, Mike Hearn <mike@plan99.net>
From: Thy Shizzle <thyshizzle@outlook.com>
Date: Tue, 26 May 2015 12:30:52 +1000
X-OriginalArrivalTime: 26 May 2015 02:31:24.0873 (UTC)
	FILETIME=[0FA0DB90:01D0975C]
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(thyshizzle[at]outlook.com)
	-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
	no trust [65.54.190.215 listed in list.dnswl.org]
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	0.0 T_REMOTE_IMAGE         Message contains an external image
X-Headers-End: 1Yx4eQ-0008NE-Fj
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:31:32 -0000

--_35254d88-6edc-40d6-9c09-8d4ed66c6fb0_
Content-Type: multipart/alternative;
	boundary="_a5980cfb-02de-4bbf-889c-d555a9a7d26b_"

--_a5980cfb-02de-4bbf-889c-d555a9a7d26b_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"

Nah don't make blocks 20mb=2C then you are slowing down block propagation a=
nd blowing out conf tikes as a result. Just decrease the time it takes to m=
ake a 1mb block=2C then you still see the same propagation times today and =
just increase the transaction throughput.
________________________________
From: Jim Phillips<mailto:jim@ergophobia.org>
Sent: =E2=80=8E26/=E2=80=8E05/=E2=80=8E2015 12:27 PM
To: Mike Hearn<mailto:mike@plan99.net>
Cc: Bitcoin Dev<mailto:bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] No Bitcoin For You

On Mon=2C May 25=2C 2015 at 1:36 PM=2C Mike Hearn <mike@plan99.net> wrote:

This meme about datacenter-sized nodes has to die. The Bitcoin wiki is down
> right now=2C 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=2C "too man=
y
> 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=2C I was a capacity planner for Bank of America's mid-rang=
e
server group. We had one hard and fast rule. When you are typically
exceeding 75% of capacity on a given metric=2C 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=2C if usage has increased to the point where you are at or near t=
he
limits of capacity=2C you expand capacity. It's as simple as that=2C and I'=
ve
found that same rule fits quite well in a number of systems.

In Bitcoin=2C we're not leaking resources. There's no flaw. The system is
performing as intended. Usage is increasing because it works so well=2C 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=2C 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=2C and ho=
w
soon can we do it. Given that most existing computer systems and networks
can easily handle 20MB blocks every 10 minutes=2C and given that that will
increase capacity 20-fold=2C 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=2C when the average
block size is over 15MB=2C 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=2C they can configure their nodes to only mine transaction=
s
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.*

--_a5980cfb-02de-4bbf-889c-d555a9a7d26b_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="utf-8"

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html=3B charset=3Dutf-8">
</head>
<body>
<div>
<div style=3D"font-family: Calibri=2Csans-serif=3B font-size: 11pt=3B">Nah =
don't make blocks 20mb=2C then you are slowing down block propagation and b=
lowing out conf tikes as a result. Just decrease the time it takes to make =
a 1mb block=2C then you still see the same propagation
 times today and just increase the transaction throughput.</div>
</div>
<div dir=3D"ltr">
<hr>
<span style=3D"font-family: Calibri=2Csans-serif=3B font-size: 11pt=3B font=
-weight: bold=3B">From:
</span><span style=3D"font-family: Calibri=2Csans-serif=3B font-size: 11pt=
=3B"><a href=3D"mailto:jim@ergophobia.org">Jim Phillips</a></span><br>
<span style=3D"font-family: Calibri=2Csans-serif=3B font-size: 11pt=3B font=
-weight: bold=3B">Sent:
</span><span style=3D"font-family: Calibri=2Csans-serif=3B font-size: 11pt=
=3B">=E2=80=8E26/=E2=80=8E05/=E2=80=8E2015 12:27 PM</span><br>
<span style=3D"font-family: Calibri=2Csans-serif=3B font-size: 11pt=3B font=
-weight: bold=3B">To:
</span><span style=3D"font-family: Calibri=2Csans-serif=3B font-size: 11pt=
=3B"><a href=3D"mailto:mike@plan99.net">Mike Hearn</a></span><br>
<span style=3D"font-family: Calibri=2Csans-serif=3B font-size: 11pt=3B font=
-weight: bold=3B">Cc:
</span><span style=3D"font-family: Calibri=2Csans-serif=3B font-size: 11pt=
=3B"><a href=3D"mailto:bitcoin-development@lists.sourceforge.net">Bitcoin D=
ev</a></span><br>
<span style=3D"font-family: Calibri=2Csans-serif=3B font-size: 11pt=3B font=
-weight: bold=3B">Subject:
</span><span style=3D"font-family: Calibri=2Csans-serif=3B font-size: 11pt=
=3B">Re: [Bitcoin-development] No Bitcoin For You</span><br>
<br>
</div>
<div>
<div dir=3D"ltr">
<div class=3D"x_gmail_extra"><br>
<div class=3D"x_gmail_quote">On Mon=2C May 25=2C 2015 at 1:36 PM=2C Mike He=
arn <span dir=3D"ltr">
&lt=3B<a href=3D"mailto:mike@plan99.net" target=3D"_blank">mike@plan99.net<=
/a>&gt=3B</span> wrote:</div>
<div class=3D"x_gmail_quote"><br>
<blockquote class=3D"x_gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=3B bo=
rder-left-width:1px=3B border-left-color:rgb(204=2C204=2C204)=3B border-lef=
t-style:solid=3B padding-left:1ex">
<div dir=3D"ltr">
<div class=3D"x_gmail_extra">
<div class=3D"x_gmail_quote">
<div>This meme about datacenter-sized nodes has to die. The Bitcoin wiki is=
 down right now=2C 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=2C &quot=3Btoo many users&quot=3B 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"x_gmail_extra">... And will certainly NEVER have if we can't =
solve the capacity problem SOON.&nbsp=3B</div>
<div class=3D"x_gmail_extra"><br>
</div>
<div class=3D"x_gmail_extra">In a former life=2C I was a capacity planner f=
or 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=2C 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=2C i=
f usage has increased to the point where you are at or near the limits of c=
apacity=2C you expand capacity. It's
 as simple as that=2C and I've found that same rule fits quite well in a nu=
mber of systems.&nbsp=3B</div>
<div class=3D"x_gmail_extra"><br>
</div>
<div class=3D"x_gmail_extra">In Bitcoin=2C we're not leaking resources. The=
re's no flaw. The system is performing as intended. Usage is increasing bec=
ause it works so well=2C and there is huge potential for future growth as w=
e identify more uses and attract more
 users. There might be a few technical things we can do to reduce consumpti=
on=2C but the metric we're concerned with right now is how many transaction=
s we can fit in a block. We've broken through the 75% marker and are regula=
rly bumping up against the 100% limit.</div>
<div class=3D"x_gmail_extra"><br>
</div>
<div class=3D"x_gmail_extra">It is time to stop debating this and take acti=
on to expand capacity. The only questions that should remain are how much c=
apacity do we add=2C and how soon can we do it. Given that most existing co=
mputer systems and networks can easily
 handle 20MB blocks every 10 minutes=2C and given that that will increase c=
apacity 20-fold=2C 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=2C when the average block =
size is over 15MB=2C 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.</div>
<div class=3D"x_gmail_extra"><br>
</div>
<div class=3D"x_gmail_extra">And you know what else? If miners need higher =
fees to accommodate the costs of bigger blocks=2C they can configure their =
nodes to only mine transactions with higher fees.. Let the miners decide ho=
w to charge enough to pay for their
 costs. We don't need to cripple the network just for them.</div>
<div class=3D"x_gmail_extra"><br clear=3D"all">
<div>
<div class=3D"x_gmail_signature">
<div>--
<div><b>James G. Phillips IV</b>&nbsp=3B<a href=3D"https://plus.google.com/=
u/0/113107039501292625391/posts" target=3D"_blank" style=3D"font-size:x-sma=
ll"><img src=3D"https://ssl.gstatic.com/images/icons/gplus-16.png"></a>&nbs=
p=3B</div>
</div>
<div><font size=3D"1"><i>&quot=3BDon't bunt. Aim out of the ball park. Aim =
for the company of immortals.&quot=3B -- David Ogilvy<br>
</i></font>
<div><font size=3D"1"><br>
</font></div>
</div>
<div><font size=3D"1"><img src=3D"http://findicons.com/files/icons/1156/fug=
ue/16/leaf.png">&nbsp=3B<em style=3D"font-family:verdana=2Cgeneva=2Csans-se=
rif=3B line-height:16px=3B color:green">This message was created with 100% =
recycled electrons. Please think twice before printing.</em></font></div>
<div><font size=3D"1"><em style=3D"font-family:verdana=2Cgeneva=2Csans-seri=
f=3B line-height:16px=3B color:green"><br>
</em></font></div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>

--_a5980cfb-02de-4bbf-889c-d555a9a7d26b_--

--_35254d88-6edc-40d6-9c09-8d4ed66c6fb0_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
--_35254d88-6edc-40d6-9c09-8d4ed66c6fb0_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--_35254d88-6edc-40d6-9c09-8d4ed66c6fb0_--