Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 2769A982 for ; Tue, 30 Jun 2015 22:56:01 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pd0-f181.google.com (mail-pd0-f181.google.com [209.85.192.181]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id AFD7211F for ; Tue, 30 Jun 2015 22:56:00 +0000 (UTC) Received: by pdcu2 with SMTP id u2so13860335pdc.3 for ; Tue, 30 Jun 2015 15:56:00 -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=kxqoD1BmCTJEtZcIo0/1h9YoJhs/wPq0ZyTSAQSiwq8=; b=ZL8s2IWG8jkICpIAFtVEYEo/mgoMdbwASgV67ahDWz6Q/H27+HbeCGeWHJtwZdOr21 mzGhJrsYdDZXmNPsgMABwDsTt9CIjEgLF8aRxbUyddbM6pkCqCWNNylNC7kUlQYsf5D2 4XK/Q42dDhhavMrwNUSh1zKQn0WCFPz3lJWF6p/oef8ZDG00LvNRtYfpLjFjl+12yFKA Vo4gQtXAOrjSrO5RmssXN0qzp6Be7YMqYzOSFqVK7TC9ST/TPaCm3A3GQ1YnxthXhNvy 9MABfy6Hi1tHQWdcPitoMEDBLkgHp9W6oNUaKxn783pbNkQNGdnppdzV433sAJzRSVhz iisw== X-Gm-Message-State: ALoCoQn8EUYMAA7ItRITf4ySaLsmA5VE+nAhmSgsiFyqnySS/mWaMzeTvvKmB1diA7F/gqTzydGw X-Received: by 10.66.255.67 with SMTP id ao3mr47970602pad.60.1435704960403; Tue, 30 Jun 2015 15:56:00 -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 sc7sm34758599pbb.85.2015.06.30.15.55.58 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Jun 2015 15:55:58 -0700 (PDT) Message-ID: <55931E84.3060307@thinlink.com> Date: Tue, 30 Jun 2015 15:56:04 -0700 From: Tom Harding User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Adam Back References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: bitcoin-dev@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] block-size tradeoffs & hypothetical alternatives (Re: Block size increase oppositionists: please clearly define what you need done to increase block size to a static 8MB, and help do it) X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 22:56:01 -0000 On 6/30/2015 12:54 PM, Adam Back wrote: > Secondly on the interests and incentives - miners also play an > important part of the ecosystem and have gone through some lean times, > they may not be overjoyed to hear a plan to just whack the block-size > up to 8MB. While it's true (within some limits) that miners could > collectively keep blocks smaller, there is the ongoing reality that > someone else can take break ranks and take any fee however de minimis > fee if there is a huge excess of space relative to current demand and > drive fees to zero for a few years. A major thing even preserving > fees is wallet defaults, which could be overridden(plus protocol > velocity/fee limits). Let's pretend it is late 2012. Nobody has ever violated the soft limit of 500KB/block. Block reward is about to be cut in half. Fees are right where they are today. 1 BTC =3D about $15. It's a good thing nothing was done in 2012 to try to boost fees out of concern for miner profits. Nor should we today. The 16X rise in the economic value=B9 of the block reward since that time covers the entire .5X effect of the halving itself, plus three additional halvings. There is far less reason today to worry on miners' behalf about fees than there was in late 2012. Running out of ways to grow does threaten miner profit, and therefore security, growth. So let's hope all the scaling ideas work. > I'm not sure if anyone has a clear picture of what limits are imposed > by hash-rate even today. =46rom the all-blocksizes plot, it's clear visually that the 750K soft limit, and another less common soft limit at 900K, are being imposed, but broken more and more frequently as demand outpaces them. These soft limits serve no purpose, other than to delay transactions. A 750KB block is followed by another 750KB or larger block just as frequently as you would expect from the actual block time distribution, which recently (prior to spam now underway) had a rate of a full 1MB block being needed every 104 minutes (in an earlier post I gave a relation which is very stable, given the stable average transaction size)= =2E ___________________ =B9Someday, if bitcoin is wildly successful, exchange rates vs. obsolete currencies won't be meaningful. If that happens, increases in the economic value of bitcoin will likely be measured by decreases in the general price level of all goods and services.