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 BB326A04 for ; Sat, 27 Jun 2015 14:39:53 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2C5E221C for ; Sat, 27 Jun 2015 14:39:53 +0000 (UTC) Received: by wicgi11 with SMTP id gi11so39062625wic.0 for ; Sat, 27 Jun 2015 07:39:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=pmyUkPZ/jIr8rfgc1LRSctT0dVZtJw/J3ptt5BTH2Cw=; b=u1LoXVyE9zroMGfGsabY4r0QmokYYje4RuZKcNDaAAWnnL2bo/2pU28aKTC0k42NDM kmwwpOISe4DHUBvAqcrrqn+ESouGbLcIbxrPQVlPtLRBBaW8X0aOGKOUzc9/J0N0gZ8N 9eG8jZeddwtOE5per72//dwmZ954v9xRZ/YugE6AYp3lRqGya2IaelRz5ZtPTXBZg8DU oRvPzY6QYFOaQktyOwytfQ94Hqa6k4dyfzMKeh34WRk2rm3xR+7/mnjQjSuhS1lmrLjx gIGAzYkZloKsgAWDEYWb2udZ4lAvNXgKD8WLAiJkyUxaLPWgGRh4LNRHCdPTGRvtG2tj /C4Q== MIME-Version: 1.0 X-Received: by 10.180.95.35 with SMTP id dh3mr6446521wib.30.1435415991561; Sat, 27 Jun 2015 07:39:51 -0700 (PDT) Received: by 10.27.10.1 with HTTP; Sat, 27 Jun 2015 07:39:51 -0700 (PDT) Date: Sat, 27 Jun 2015 10:39:51 -0400 Message-ID: From: Michael Naber To: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary=f46d04447e1d48340b051980d40c X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_05,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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 Subject: [bitcoin-dev] A Proposed Compromise to the Block Size Limit 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: Sat, 27 Jun 2015 14:39:53 -0000 --f46d04447e1d48340b051980d40c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Demand to participate in a low-fee global consensus network will likely continue to rise. Technology already exists to meet that rising demand using a blockchain with sufficient block size. Whether that blockchain is Bitcoin Core with an increased block size, or whether it is a fork, market forces make it almost certain that demand will be met by a blockchain with adequate capacity. These forces ensure that not only today=E2=80=99s block = size will be increased, but also that future increases will occur should the demand arise. In order to survive, Bitcoin Core must remain the lowest-fee, highest-capacity, most secure, distributed, fastest, overall best solution possible to the global consensus problem. Attempting to artificially constrain the block size below the limits of technology for any reason is a conflict with this objective and a threat to the survival of Bitcoin Core. At the same time, scheduling large future increases or permitting unlimited dynamic scaling of the block size limit raises concerns over availability of future computing resources. Instead, we should manually increase the block size limit as demand occurs, except in the special case that increasing the limit would cause an undue burden upon users wishing to validate the integrity of the blockchain. Compromise: Can we agree that raising the block size to a static 8MB now with a plan to increase it further should demand necessitate except in the special case above is a reasonable path forward? --f46d04447e1d48340b051980d40c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Demand to participate in a low-fee global consensus n= etwork will likely continue to rise. Technology already exists to meet that= rising demand using a blockchain with sufficient block size. Whether that = blockchain is Bitcoin Core with an increased block size, or whether it is a= fork, market forces make it almost certain that demand will be met by a bl= ockchain with adequate capacity. These forces ensure that not only today=E2= =80=99s block size will be increased, but also that future increases will o= ccur should the demand arise.=C2=A0

In order to su= rvive, Bitcoin Core must remain the lowest-fee, highest-capacity, most secu= re, distributed, fastest, overall best solution possible to the global cons= ensus problem. Attempting to artificially constrain the block size below th= e limits of technology for any reason is a conflict with this objective and= a threat to the survival of Bitcoin Core. At the same time, scheduling lar= ge future increases or permitting unlimited dynamic scaling of the block si= ze limit raises concerns over availability of future computing resources. I= nstead, we should manually increase the block size limit as demand occurs, = except in the special case that increasing the limit would cause an undue b= urden upon users wishing to validate the integrity of the blockchain.=C2=A0=

Compromise: Can we agree that raising the block s= ize to a static 8MB now with a plan to increase it further should demand ne= cessitate except in the special case above is a reasonable path forward?
--f46d04447e1d48340b051980d40c--