From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 6FC8D83D for ; Tue, 4 Aug 2015 11:59:59 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D70CC89 for ; Tue, 4 Aug 2015 11:59:58 +0000 (UTC) Received: by wibud3 with SMTP id ud3so173723612wib.1 for ; Tue, 04 Aug 2015 04:59:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=MgK/DtJTsqVAet98EJvk2N9WDpk/21JAz0YldoE4tiA=; b=O2SjDOCLaCs25E0es3KDIXDo4+2QAmYSh1jMMipKhDhYjYDtUnAy2Z2Xp28c98Ie+k /CMp7vYAVHi9QCv0w3jEsO8oyKv4eTht8N5SIZ0Iivt4xfzdI5oFvkYJoy7eGaEvEkqh PsoNJhNfoT1U4/n+ZUdcDOPGL46b0ORFzbnK82z3IuNzFoEyugy5jvxyNRYULDtzk2FM CuspiWXPJAiqWAPurOEkdypavTrKI+kDHM++3dnyqvLCLrl9doOb2X0wyFcP6IanZJS7 1JqGbolWPNEG13N2W0Ii8LYE0abStrG5i9oAxLBy2d2qzqgbAfPUbYpC8kwn6kWRECxv 822g== X-Gm-Message-State: ALoCoQmsP7B1qXWayZL6uZDQ8646Y/ezjrJHyXlxeHtlTgHDAdn/klPZEDSGohDRUHhU2KkWOgkU MIME-Version: 1.0 X-Received: by 10.180.186.35 with SMTP id fh3mr44832949wic.7.1438689597333; Tue, 04 Aug 2015 04:59:57 -0700 (PDT) Received: by 10.194.31.230 with HTTP; Tue, 4 Aug 2015 04:59:57 -0700 (PDT) In-Reply-To: References: Date: Tue, 4 Aug 2015 13:59:57 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Hector Chu Content-Type: text/plain; charset=UTF-8 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 Subject: Re: [bitcoin-dev] Block size following technological growth 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, 04 Aug 2015 11:59:59 -0000 On Tue, Aug 4, 2015 at 1:04 PM, Hector Chu wrote: > Mike's position is that he wants the block size limit to eventually be > removed. That is of course an extreme view. I prefer to wait and let him talk by himself. > Meanwhile, your view that the > block size should be artificially constrained below the organic growth curve > (in a way that will penalize a majority of existing and future users) lies > at the other extreme. That is not my position. Again, I don't know what the right blocksize for the short term is (I don't think anybody does). But I know that the maximum block size limit consensus rule (no more artificial than any other consensus rule, like, say, the one that prohibits double-spends) serves to limit mining centralization. Therefore how the change can affect mining centralization must be the main concern, instead of (also artificial) projections about usage growth (no matter how organic their curves look). Also I don't think "hitting the limit" must be necessarily harmful and if it is, I don't understand why hitting it at 1MB will be more harmful than hitting it at 2MB, 8MB or 8GB. > The majority position lies somewhere in between (i.e. > a one-time increase to 8MB). This is the position that ultimately matters. I don't know where you get your "majority" from or what it even means (majority of users, majority of the coins, of miners?) But there's something I'm missing something there...why my position doesn't matter if it's not a majority? How is what the the majority has been told it's best an objective argument? > If the block size is increased to 8MB and things get demonstrably a whole > lot worse, then you will have a solid leg to stand on. In that case we can > always do another hard fork later to reduce the block size back to something > smaller, and henceforth the block size will never be touched again. Yes. And if we can "break things" in simulations first before we "break things" in production, maybe we don't need the later hardfork to "fix things" (if it's still possible to fix them without completely restarting the ASIC market). The fact is that we don't have a single simulation that can tell you "too centralized/shouldn't affect mining centralization much" for a given block size. So if you say 8, I must ask, why not 9? Why 9 MB is not safe for mining centralization but 8 MB is? There is NO criterion based on mining centralization to decide between 2 sizes in favor of the small one. It seems like the rationale it's always "the bigger the better" and the only limitation is what a few people concerned with mining centralization (while they still have time to discuss this) are willing to accept. If that's the case, then there won't be effectively any limit in the long term and Bitcoin will probably fail in its decentralization goals. I think its the proponents of a blocksize change who should propose such a criterion and now they have the tools to simulate different block sizes. I want us to simulate many blocksizes before rushing into a decision (specially because I disagree that taking a decision there is urgent in the first place).