From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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: References: <5554BDC1.6070206@thinlink.com> From: Jim Phillips Date: Mon, 25 May 2015 21:26:42 -0500 Message-ID: To: Mike Hearn 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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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* *"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

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

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>

... And will certai= nly NEVER have if we can't solve the capacity problem SOON.=C2=A0
=

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

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.

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.
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.

--
James G. Phillips IV<= /b>=C2=A0=C2=A0
"Don't bunt. Aim out of the ball park. Aim for the compa= ny of immortals." -- David Ogilvy
=
=C2=A0This message was created= with 100% recycled electrons. Please think twice before printing.

--f46d043c7b9c39d7bd0516f2ddf8--