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 CDB34A88 for ; Tue, 28 Mar 2017 19:56:50 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vk0-f53.google.com (mail-vk0-f53.google.com [209.85.213.53]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7EB05196 for ; Tue, 28 Mar 2017 19:56:50 +0000 (UTC) Received: by mail-vk0-f53.google.com with SMTP id d188so101170093vka.0 for ; Tue, 28 Mar 2017 12:56:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=kqJxr+Vl2fPEmryt0RpEFsa//IPSMPzdPnfNP9kaImM=; b=UFqJlMFT8LVSeDWqXu/bkDFPJTCoSmVkNV1ZyfqtsLyDUTXG1PQzBuQRmLt/I27QoB vJoPaBp3PijmDOIDjyCibQfVJYb2WnLDyavyZNzrtzXPwFoQEhGSrnLqmafZjtCkYa1H W7KNUeXVUn4Co55FD42v+DNT4IYvnE2XkGRfxwiSPi3KhPrUVhsCNx1tv1DGi6EWodx5 EQpR8PWFaIiay6FdbJSqmH0XWtdHvi6LTqWDK7aadgZcgCpCvpkdyrMyK2Y7XO4QVwWI e6vZEqktMg28xTFTD6DSyMJp+WOyrxtZNQL3RzjyliS6I6pTGuuaLJu3naaK0F6++Q+z a1sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=kqJxr+Vl2fPEmryt0RpEFsa//IPSMPzdPnfNP9kaImM=; b=njF+vNVUbm9bfbwinl/v7GQVv2wMFpo7epiSd0WlZQA6FrcXR2EeSXgtCgq4/Poj2y MhVaHl6ahjV0YFFe/PP+lsMbGBR2mLA1N+aqghlbB7NgThm4ahMRNJYiD66KwqKV1uHk hBLlMz1mygqP1EJ6FAUR1iAxXaVDPhaXYbk+lAfrsEVqU0JITwdacq+eVHmCxA2X6fZ1 7z4YGJt8C0Dk+bQMvVS5bPNClwQBpYuvgL+qFDWpmIVEcllxC1rWHnYEbGSWuAbrNtIt hzKGrTE8n6N/CTbnJ/QZaVZ6IemF2tZCVjkQSbipAL+v8mWME83krHSN7UDzo8mxLlUZ uC7g== X-Gm-Message-State: AFeK/H2qGFQ0mtRFlI8AdiExJQm7hRxUponund/od4AHvMMI+eBsj4kzeBEs88GnP2rWrrYs3OHzONmKoimIHQ== X-Received: by 10.176.88.194 with SMTP id r2mr8527252uac.139.1490731009404; Tue, 28 Mar 2017 12:56:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.254.15 with HTTP; Tue, 28 Mar 2017 12:56:49 -0700 (PDT) From: Paul Iverson Date: Tue, 28 Mar 2017 12:56:49 -0700 Message-ID: To: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary=f403045f8a86457589054bcfdc9a X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Tue, 28 Mar 2017 20:00:08 +0000 Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 19:56:50 -0000 --f403045f8a86457589054bcfdc9a Content-Type: text/plain; charset=UTF-8 Thank you for the proposal Wang Chung! It is clear that, spam aside, blocks are getting full and we need increase them soon. What I don't like about your proposal is it forces all node operators to implicitly accept larger blocks in 2020, even maybe against their will. 32 MB blocks might result in a loss of decentralization, and it might be too difficult to coordinate for small blocks before it's too late. So I think Core can't decide on hard forks like this. It must be left up to the users. I think only choice is for Core to add a run-time option to allow node operators to increase block size limit, so that this very controversial decision is not coming from Core. It must come from the community. --f403045f8a86457589054bcfdc9a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thank you for the proposal Wang Chung! =C2=A0

It is clear that, spam aside, blocks are getting full and we need in= crease them soon. What I don't like about your proposal is it forces al= l node operators to implicitly accept larger blocks in 2020, even maybe aga= inst their will. 32 MB blocks might result in a loss of decentralization, a= nd it might be too difficult to coordinate for small blocks before it's= too late. =C2=A0

So I think Core can't decide= on hard forks like this. It must be left up to the users. I think only cho= ice is for Core to add a run-time option to allow node operators to increas= e block size limit, so that this very controversial decision is not coming = from Core. It must come from the community. =C2=A0

--f403045f8a86457589054bcfdc9a--