Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id B4D7B895 for ; Mon, 17 Aug 2015 16:11:18 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-la0-f49.google.com (mail-la0-f49.google.com [209.85.215.49]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2E0C4EA for ; Mon, 17 Aug 2015 16:11:18 +0000 (UTC) Received: by labd1 with SMTP id d1so82702852lab.1 for ; Mon, 17 Aug 2015 09:11:16 -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=NcecRELCyrKNfvK+1poRWGajPfxFG364l1nM5yNfKsk=; b=GCREyy86b5ctR1K3p65G5t5Ybl3xYSljLmJB48DC5H67nQU2pHQMecZWpsFmnWafRI gW4q6sV3WG+dqZQSKnrENfYKzBp8h/KP45SkGlw1M1iShKkIoFdr5bXU8nwTR8cAByBt mQAkHk8r4Ea8mnPw1+VAeChUGV9QFRoLo256Z0/1504aW5zJUtBJSyfT7AhiGYmM/uUG arfDGZEZ35ll2d+BEcPLJV6PAAFVBOFErUzzYiRaL+PvOrGvMfKqBQgUN0fGsyGdghS6 J52fFgmItzLduqtOM245Lwh6yZYm40fkYUOyUgM2y4j8Jo6jZ3JdzSsGUN/ybX+BFxOQ VsCQ== X-Gm-Message-State: ALoCoQlH7PmJ2VPlx3eTPt32k/yuV8GDpeYM3ztLS5Zy7Aiezhl8v5GA1FLWabSidAaFMq8U4IAa MIME-Version: 1.0 X-Received: by 10.112.89.201 with SMTP id bq9mr1712822lbb.39.1439827876581; Mon, 17 Aug 2015 09:11:16 -0700 (PDT) Received: by 10.25.15.22 with HTTP; Mon, 17 Aug 2015 09:11:16 -0700 (PDT) In-Reply-To: References: <558A0B4A.7090205@riseup.net> <558A1E8E.30306@novauri.com> <0CAB4453-0C88-4CCB-86C1-DA192D4F77A1@gmail.com> Date: Mon, 17 Aug 2015 18:11:16 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Tier Nolan 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] Draft BIP : fixed-schedule block size increase 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, 17 Aug 2015 16:11:18 -0000 On Fri, Jun 26, 2015 at 3:47 PM, Tier Nolan wrote: > - Miner vote to decide soft limit (lowest size ignoring bottom 20% but 1MB > minimum) I don't think is all that interesting to make miners vote on lower limit. Say the community wants to reduce the size to limit mining centralization, it's not unthinkable that the hashrate majority (which may have to face more competition or harvest less transactions after the change) may oppose to that and then the community is forced to deploy an anti-miner's hardfork (maybe even asic-reset hardfork?) instead of a softfork. Yes, uncontroversial sofforks are easier and less risky to deploy than uncontroversial hardforks, but anti-miner hardforks are not. Not only I don't think it's a good idea for miners to vote on the block size (which is there to control them), I don't even buy the assumption that "we can always just softfork a smallwer size later". If you give something to miners they may not want to give it back later. We could hardfork to 42 M supply and then "just softfork back to 21 M", right? Or what's the same, we could "just softfork supply to 15 M". Such a change would be clearly controversial among miners, so it wouldn't be an uncontroversial softfork anymore. Some of these cases are discussed in BIP99.