Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Yq8wl-00054L-DM for bitcoin-development@lists.sourceforge.net; Wed, 06 May 2015 23:41:47 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of bluematt.me designates 192.241.179.72 as permitted sender) client-ip=192.241.179.72; envelope-from=bitcoin-list@bluematt.me; helo=mail.bluematt.me; Received: from mail.bluematt.me ([192.241.179.72]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1Yq8wi-00085l-44 for bitcoin-development@lists.sourceforge.net; Wed, 06 May 2015 23:41:47 +0000 Received: from [172.17.0.2] (gw.vpn.bluematt.me [162.243.132.6]) by mail.bluematt.me (Postfix) with ESMTPSA id 555C154357; Wed, 6 May 2015 23:41:38 +0000 (UTC) Message-ID: <554AA6B1.8030701@bluematt.me> Date: Wed, 06 May 2015 23:41:37 +0000 From: Matt Corallo User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Tier Nolan References: <554A91BE.6060105@bluematt.me> <554A9FD1.80103@bluematt.me> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Score: -1.5 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -0.0 SPF_PASS SPF: sender matches SPF record X-Headers-End: 1Yq8wi-00085l-44 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: Wed, 06 May 2015 23:41:47 -0000 On 05/06/15 23:33, Tier Nolan wrote: > On Thu, May 7, 2015 at 12:12 AM, Matt Corallo > wrote: > > The point of the hard block size limit is exactly because giving miners > free rule to do anything they like with their blocks would allow them to > do any number of crazy attacks. The incentives for miners to pick block > sizes are no where near compatible with what allows the network to > continue to run in a decentralized manner. > > > Miners can always reduce the block size (if they coordinate). > Increasing the maximum block size doesn't necessarily cause an > increase. A majority of miners can soft-fork to set the limit lower > than the hard limit. Sure, of course. > Setting the hard-fork limit higher means that a soft fork can be used to > adjust the limit in the future. > > The reference client would accept blocks above the soft limit for wallet > purposes, but not build on them. Blocks above the hard limit would be > rejected completely. Yes, but this does NOT make an actual policy. Note that the vast majority of miners already apply their own patches to Bitcoin Core, so applying one more is not all that hard. When blocks start to become limited (ie there is any fee left on the table by transactions not included in a block) there becomes incentive for miners to change that behavior pretty quick. Not just that, the vast majority of the hashpower is behind very large miners, who have little to no decentralization pressure. This results in very incompatible incentives, mainly that the incentive would be for the large miners to interconnect in a private network and generate only maximum-size blocks, creating a strong centralization pressure in the network.