Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Yx501-00051y-RI for bitcoin-development@lists.sourceforge.net; Tue, 26 May 2015 02:53:49 +0000 X-ACL-Warn: Received: from mail-wi0-f175.google.com ([209.85.212.175]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Yx4zz-0002x6-DB for bitcoin-development@lists.sourceforge.net; Tue, 26 May 2015 02:53:49 +0000 Received: by wifw1 with SMTP id w1so13916409wif.0 for ; Mon, 25 May 2015 19:53:41 -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=M2+EPWXpXd6jfPxS8ikB2+gEkOJ9St5hz6qSemIczZQ=; b=IsYR0RzoADT8lNUiwvRzQSPILsHQsAlUGCYxNkcAmQqHU31qlvx+1iWlMwhx3kbLAb 9Vw33J9aZ8U3stdaMcMA3qKMIva2DYncCxrI1trYEfiDMY5rjhc/Foxcj1H9VFnwGF1y 1P+iScuINnR5vZmvyi/HbtVFJJarp2TAF1xGENKhhYLI43XYIhjvM5gQb4/hp4/DWg4h vsDkncFUYGr3wiVX+AdjNwRWuZS1Ad27Zc8xX1DZBh75MVMFy1M4rLHwRJ9aIUnz0Oe9 SC+e4sk37uuRRkcZc1PdCKNcJKJpVxzt87McKWauqLpZKWacwe9osa4gml0BF6xX/pvO Bg4A== X-Gm-Message-State: ALoCoQkwlnEY261JE07H+BnaL4L8Q2vpSm6VMU2nHPE+jfwkzXDoA1xXmG4zbfjlFFo3mRtJ/4gE X-Received: by 10.180.107.138 with SMTP id hc10mr36235951wib.2.1432608821330; Mon, 25 May 2015 19:53:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.246.69 with HTTP; Mon, 25 May 2015 19:53:10 -0700 (PDT) In-Reply-To: References: From: Jim Phillips Date: Mon, 25 May 2015 21:53:10 -0500 Message-ID: To: Thy Shizzle Content-Type: multipart/alternative; boundary=e89a8f235739e5daff0516f33b0b 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: 1Yx4zz-0002x6-DB 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:53:49 -0000 --e89a8f235739e5daff0516f33b0b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Frankly I'm good with either way. I'm definitely in favor of faster confirmation times. The important thing is that we need to increase the amount of transactions that get into blocks over a given time frame to a point that is in line with what current technology can handle. We can handle WAY more than we are doing right now. The Bitcoin network is not currently Disk, CPU, or RAM bound.. Not even close. The metric we're closest to being restricted by would be Network bandwidth. I live in a developing country. 2Mbps is a typical broadband speed here (although 5Mbps and 10Mbps connections are affordable). That equates to about 17MB per minute, or 170x more capacity than what I need to receive a full copy of the blockchain if I only talk to one peer. If I relay to say 10 peers, I can still handle 17x larger block sizes on a slow 2Mbps connection. Also, even if we reduce the difficulty so that we're doing 1MB blocks every minute, that's still only 10MB every 10 minutes. Eventually we're going to have to increase that, and we can only reduce the confirmation period so much. I think someone once said 30 seconds or so is about the shortest period you can practically achieve. -- *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.* On Mon, May 25, 2015 at 9:30 PM, Thy Shizzle wrote= : > Nah don't make blocks 20mb, then you are slowing down block propagation > and blowing out conf tikes as a result. Just decrease the time it takes t= o > make a 1mb block, then you still see the same propagation times today and > just increase the transaction throughput. > ------------------------------ > From: Jim Phillips > Sent: =E2=80=8E26/=E2=80=8E05/=E2=80=8E2015 12:27 PM > To: Mike Hearn > Cc: Bitcoin Dev > Subject: Re: [Bitcoin-development] No Bitcoin For You > > > 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 o= n > 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 o= f > 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 expan= d > 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 system= s. > > 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 ho= w > 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 c= an > 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 enoug= h > to pay for their costs. We don't need to cripple the network just for the= m. > > -- > *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.* > > --e89a8f235739e5daff0516f33b0b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Frankly I'm good with either way. I'm definitely i= n favor of faster confirmation times.=C2=A0

The importan= t thing is that we need to increase the amount of transactions that get int= o blocks over a given time frame to a point that is in line with what curre= nt technology can handle. We can handle WAY more than we are doing right no= w. The Bitcoin network is not currently Disk, CPU, or RAM bound.. Not even = close. The metric we're closest to being restricted by would be Network= bandwidth. I live in a developing country. 2Mbps is a typical broadband sp= eed here (although 5Mbps and 10Mbps connections are affordable). That equat= es to about 17MB per minute, or 170x more capacity than what I need to rece= ive a full copy of the blockchain if I only talk to one peer. If I relay to= say 10 peers, I can still handle 17x larger block sizes on a slow 2Mbps co= nnection.

Also, even if we reduce the difficulty so that= we're doing 1MB blocks every minute, that's still only 10MB every = 10 minutes. Eventually we're going to have to increase that, and we can= only reduce the confirmation period so much. I think someone once said 30 = seconds or so is about the shortest period you can practically achieve.

--
James G. Phillips IV=C2=A0=C2=A0
&q= uot;Don't bunt. Aim out of the ball park. Aim for the company of immort= als." -- David Ogilvy

<= /div>
=C2=A0Th= is message was created with 100% recycled electrons. Please think twice bef= ore printing.

On Mon, May 25, 2015 at 9:30 PM, Thy Shizzle= <thyshizzle@outlook.com> wrote:
Nah don't = make blocks 20mb, then you are slowing down block propagation and blowing o= ut conf tikes as a result. Just decrease the time it takes to make a 1mb bl= ock, then you still see the same propagation times today and just increase the transaction throughput.
From: Jim Phillips Sent: =E2=80= =8E26/=E2=80=8E05/=E2=80=8E2015 12:27 PM
To: Mike Hearn
Cc: Bi= tcoin Dev
Subject: Re: [B= itcoin-development] No Bitcoin For You

... And will certainly NEVER have if we can't solve the capacity p= roblem SOON.=C2=A0

In a former life, I was a capacity planner for Bank of America's m= id-range server group. We had one hard and fast rule. When you are typicall= y exceeding 75% of capacity on a given metric, it's time to expand capa= city. Period. You don't do silly things like adjusting the business model to disincentiv= ize use. Unless there's some flaw in the system and it's leaking re= sources, if usage has increased to the point where you are at or near the l= imits 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.=C2=A0

In Bitcoin, we're not leaking resources. There's no flaw. The = system is performing as intended. Usage is increasing because it works so w= ell, 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 consumpti= on, but the metric we're concerned with right now is how many transacti= ons 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. T= he only questions that should remain are how much capacity do we add, and h= ow soon can we do it. Given that most existing computer systems and network= s can easily handle 20MB blocks every 10 minutes, and given that that will increase cap= acity 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 bloc= k 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 transac= tions 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.

"Don't bunt. Aim out of the ball park. Ai= m for the company of immortals." -- David Ogilvy

=C2=A0This message was created with 100% recycled ele= ctrons. Please think twice before printing.


--e89a8f235739e5daff0516f33b0b--