Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 82E6D88B for ; Mon, 3 Aug 2015 13:57:56 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f195.google.com (mail-io0-f195.google.com [209.85.223.195]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1549C115 for ; Mon, 3 Aug 2015 13:57:56 +0000 (UTC) Received: by ioeo62 with SMTP id o62so11473105ioe.2 for ; Mon, 03 Aug 2015 06:57:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ChsgeDtS0sA2Qn+Ef8hEaf9OYoXZCeeUuXyPfyidTxI=; b=PiyXn3my/neAMoRala3NopBCw2VJX9NDa5K0Z0m8X6c9CFRZ71M+v32aysN+ruw+GM 17CTv9Ji0/cI3v5hfonTZNiSmLoQmkWFJsid/xZrNgH6/Gvun24pPGzfGnAqGItfn56d Jl031fL9TMZq8hVGoX5mCe+hvxK+uBkXEX8q6Y7iWhMk0QP56x/P/t8/qwcmVQiveiyu EyKjfX6umqt73oxNb//oCrnevt98fcdNSRuFBx5F/9dsLAH/9SiGs4yVFxxgVK/8IFZ+ XA7XrpRbags6UA+0cLmp7v7zczYFeNFBEFttv3F4qIJOS145ppRAbtJLebjzyJMZgogc B9Qg== MIME-Version: 1.0 X-Received: by 10.107.33.65 with SMTP id h62mr22431498ioh.11.1438610275461; Mon, 03 Aug 2015 06:57:55 -0700 (PDT) Received: by 10.107.24.198 with HTTP; Mon, 3 Aug 2015 06:57:55 -0700 (PDT) In-Reply-To: References: Date: Mon, 3 Aug 2015 09:57:55 -0400 Message-ID: From: Michael Ruddy To: Adam Back Content-Type: text/plain; charset=UTF-8 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, 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 Subject: Re: [bitcoin-dev] A reason we can all agree on to increase block size 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: Mon, 03 Aug 2015 13:57:56 -0000 Does that not sound like a useful check-and-balance? It does to me. In a scenario where these network limitations and miner rate distributions are the same to begin, and the block and transaction size limits are raised or removed, your observation would seem to indicate that blocks that are outstandingly large would not be mined often or at all (due to orphan risk), until at least the network limitations or rate distributions changed. Such a scenario could shape up to be a non-event. Miner majority could choose to not change their policy regarding effective block and transaction sizes (which includes both the size of the blocks they create and the size of the blocks that they choose to build upon). To make it not a total non-event, then the miners might update their policy to increase the effective sizes a measured amount. They wouldn't want to go too far because of the risk of spooking the economic majority, or because of their own technological limitations (which I'm supposing would remain transport layer limitations). To me, in absence of these transport layer limitations that have crept up into the consensus rules layer (clear layer violations), it seems that one thing that would otherwise naturally bound the upper and lower limits of effective block and transaction size is the economic majority feedback loop to miners. Get too far out of line and the effect on usefulness, or properties of the system, will make people react by lowering the purchasing power of the block rewards. For example, attack other miners to drive more mining centralization, or create blocks that are currently too big for people to validate/use, and that feedback loop will start to direct negatively. Why do miners not currently choose policy that favors smaller blocks and transactions than they do? Laziness/indifference only explains so much. I submit that they don't because if they make the system less useful, then people will react by selling off coins and potentially leaving the ecosystem (they might also just wait on the sidelines to see if the system self-corrects). If the miners tested those waters, and found out that they made a mistake, at least they would be free to correct their actions (and quickly). Not all would be lost. Some value could be (temporarily) lost. It could also be re-gained if the system self-corrected. To follow-up on the layer violation idea that I started on before, I think a secondary, non-consensus rule layer, indication of what block and transaction sizes are acceptable to the economic majority would be found in the transport protocols that they use. For example, the effective P2P protocol limit that is 2MB or 32MB (depending on version of the Core client) would be one such indication. Doesn't anyone think that separating the consensus layer rules from the transport layer supporting it should be a goal? On Mon, Aug 3, 2015 at 2:34 AM, Adam Back via bitcoin-dev wrote: > If block-sizes are increased in a way detrimental to the Chinese miners, it > is not the Chinese miners that lose, it is all of the non-Chinese miners - > this is because the Chinese miners have the slight majority of the hashrate. > The relatively low external bandwidth connecting China to the net is > actually the problem of the non-Chinese miners problem. Non Chinese miners > will experience higher orphan rate once Chinese miners cease to build on top > of blocks that are too large to sync in a timely fashion into China. > > Adam