Message-ID: <554C45E4.1020208@thinlink.com>
Date: Thu, 07 May 2015 22:13:08 -0700
From: Tom Harding <tomh@thinlink.com>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Jeff Garzik <jgarzik@bitpay.com>
References: <554A91BE.6060105@bluematt.me>
	<CANEZrP3wGWHdz+ut6pvke5TJJsc1rTFt8sn2KziX35oL5LAsyg@mail.gmail.com>
	<CABm2gDpDvk2VsQ+mJ-BoeBKmvu9jBXNujZEFKuCStRNjFL6VOA@mail.gmail.com>
	<CANEZrP2zAGCCBhNa4=9yw+A_Dn5o4SQXoPTE_qcJzZ1dFuF2tw@mail.gmail.com>
	<CABm2gDqd6iHRUDKZWWTudcC1QkYa+rCuHjz7pMC2K1Db8wpgfA@mail.gmail.com>
	<CANEZrP1CU0kB0vXeXUX1L8byaT-Zf2xg+3N+GeNthi_i6bn1qw@mail.gmail.com>
	<CABsx9T2Nxvr4fqREMw3_LXftzsxrUAR1+9sVMa8_EpTnH1nN1Q@mail.gmail.com>
	<554BA032.4040405@bluematt.me>
	<CANEZrP3yM9wsSPNgpOsXDk-DjUy5PW2XuRTvK2AyCNbVJ5hZHw@mail.gmail.com>
	<CADJgMzti7ROH90APiwg4NOAT5+Av=4i295b8VN0sbSLr4+WWRw@mail.gmail.com>
	<CANEZrP39jWHLF02z-81Z4+9X1vH5+hMuS=-3ED81=Q1o9U=DKw@mail.gmail.com>
	<554BBDA2.7040508@gmail.com>
	<CAJHLa0NcxOHkrtW2=-JgfsXQJkCO8Ym7icBwMx_2RsaWcPBnTw@mail.gmail.com>
	<554C1410.7050406@thinlink.com>
	<CAJHLa0PeEd19ooHbOHUMxX9-5=iyUng-9GWnQFOn_F3aXxVWLQ@mail.gmail.com>
In-Reply-To: <CAJHLa0PeEd19ooHbOHUMxX9-5=iyUng-9GWnQFOn_F3aXxVWLQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Block Size Increase
Precedence: list

On 5/7/2015 7:09 PM, Jeff Garzik wrote:
>
> G proposed 20MB blocks, AFAIK - 140 tps
> A proposed 100MB blocks - 700 tps
> For ref,
> Paypal is around 115 tps
> VISA is around 2000 tps (perhaps 4000 tps peak)
>
> I ask again:  where do we want to go?   This is the existential
> question behind block size.
>
> Are we trying to build a system that can handle Paypal volumes?  VISA
> volumes?
>
> It's not a snarky or sarcastic question:  Are we building a system to
> handle all the world's coffees?  Is bitcoin's main chain and network -
> Layer 1 - going to receive direct connections from 500m mobile phones,
> broadcasting transactions?
>
> We must answer these questions to inform the change being discussed
> today, in order to decide what makes the most sense as a new limit.=20
> Any responsible project of this magnitude must have a better story
> than "zomg 1MB, therefore I picked 20MB out of a hat"  Must be able to
> answer /why/ the new limit was picked.
>
> As G notes, changing the block size is simply kicking the can down the
> road:
> http://gavinandresen.ninja/it-must-be-done-but-is-not-a-panacea =20
> Necessarily one must ask, today, what happens when we get to the end
> of that newly paved road.
>
>

Accepting that outcomes are less knowable further into the future is not
the same as failing to consider the future at all.  A responsible
project can't have a movie-plot roadmap.  It needs to give weight to
multiple possible future outcomes.
http://en.wikipedia.org/wiki/Decision_tree

One way or another, the challenge is to decide what to do next.  Beyond
that, it's future decisions all the way down.=20

Alan argues that 7 tps is a couple orders of magnitude too low for any
meaningful commercial activity to occur, and too low to be the final
solution, even with higher layers.  I agree.  I also agree with you,
that we don't really know how to accomplish 700tps right now.

What we do know is if we want to bump the limit in the short term, we
ought to start now, and until there's a better alternative root to the
decision tree, it just might be time to get moving.