From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) id 1Yqab9-0007ot-Gw for bitcoin-development@lists.sourceforge.net; Fri, 08 May 2015 05:13:19 +0000 X-ACL-Warn: Received: from mail-pd0-f170.google.com ([209.85.192.170]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Yqab8-0005Ej-GH for bitcoin-development@lists.sourceforge.net; Fri, 08 May 2015 05:13:19 +0000 Received: by pdea3 with SMTP id a3so64205942pde.3 for ; Thu, 07 May 2015 22:13:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=xtoeju5NZ1vyej4l8EvrLR7WZn4JBM5f5z/5+V8rkGo=; b=Qtlw9GKewEOPTvUwGOYjgjfvas1n9p7zhxw12aL1upxnYVxPmkHQptWilblkSSxsfh ustiydkUFfE1G7Kc4SGZTkID1Axmqv+qcQPrDHMujAi3sEm1geNp+mEKMbQdIiggFsXR oIFWi1izpQ7bbYpVqDxiizNOLJee8YjA4FZGh089oSWNb/HmD8jyVLVgeIfF7ypP5043 PxYIbju6TRH7sj9pS4SckRftV/veqzvHnfFOJnsx5vnTm7ELl2JGFuL94wmznEQi2K50 6c4ADkEHc+RHP/x9jjOZSQ4DnqSEfZRrNimXgmNeO+ZPp8bl2qEu5lW8b7cDWuzK6Ff1 aSVQ== X-Gm-Message-State: ALoCoQlBS23iNHSSjSp56BVjpCzGpeWL60qxPhGok7PcoZguD1DJNK7GOtpHBE3qPgkDbriD2Idk X-Received: by 10.70.43.176 with SMTP id x16mr3489807pdl.83.1431061987702; Thu, 07 May 2015 22:13:07 -0700 (PDT) Received: from [192.168.1.89] (99-8-65-117.lightspeed.davlca.sbcglobal.net. [99.8.65.117]) by mx.google.com with ESMTPSA id hj11sm3763691pbd.33.2015.05.07.22.13.06 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 May 2015 22:13:07 -0700 (PDT) Message-ID: <554C45E4.1020208@thinlink.com> Date: Thu, 07 May 2015 22:13:08 -0700 From: Tom Harding 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 References: <554A91BE.6060105@bluematt.me> <554BA032.4040405@bluematt.me> <554BBDA2.7040508@gmail.com> <554C1410.7050406@thinlink.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. X-Headers-End: 1Yqab8-0005Ej-GH Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Block Size Increase 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: Fri, 08 May 2015 05:13:19 -0000 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.