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 9428C259 for ; Tue, 18 Aug 2015 06:38:07 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-yk0-f171.google.com (mail-yk0-f171.google.com [209.85.160.171]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0367389 for ; Tue, 18 Aug 2015 06:38:06 +0000 (UTC) Received: by ykll84 with SMTP id l84so85720557ykl.0 for ; Mon, 17 Aug 2015 23:38:06 -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:date:message-id:subject:from:to :content-type; bh=ch9VbC0igdusCJMziXoFbpBYrmR87vTPxbzHxLJQLpw=; b=krqrnCpzex0NR2K5dgoozn0xe4weh1Jyr5gaHYOY+9NwZmSZyedvSO5VkYuMiRNUtE 7k7MZgCpUOlO5sS0hXrc/mX5dqiOnWxFdkLriK/dRq8hkT4PRaftTH/0BTOYpKhUy/+p pktw4Jqw0B40b21XN1BEMx1RXR0ZIxgUZx9ilnFHllZQdun9MTaz+Din0m6ELIDgQptE lSGicb9qTR6YDRFRKtRvZV8DNlEjnnlvNPqMcVPswiTCK3Zexn40znVAQ8gRFrp3WdPP EBqQkhd5xPY14g3fSF3oe5KM8MkBCXjwUsTpyQxEHME798uonl3x2Slh1q4GO6VdE3V/ 6/Fw== X-Gm-Message-State: ALoCoQkgIVKs7YgFTJkiwr3OJS7Hm6KhA3fKEAeEfr1cPX7WvR5IE2RlAzFycqLw/iWMbSETfYmi MIME-Version: 1.0 X-Received: by 10.129.83.136 with SMTP id h130mr5669985ywb.95.1439879885949; Mon, 17 Aug 2015 23:38:05 -0700 (PDT) Received: by 10.13.205.6 with HTTP; Mon, 17 Aug 2015 23:38:05 -0700 (PDT) Date: Tue, 18 Aug 2015 08:38:05 +0200 Message-ID: From: Marcel Jamin To: bitcoin-dev Content-Type: multipart/alternative; boundary=001a114d6f181f3cab051d902997 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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] Simplifying the blocksize limit debate 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, 18 Aug 2015 06:38:07 -0000 --001a114d6f181f3cab051d902997 Content-Type: text/plain; charset=UTF-8 I'm going to list a few assumtions / observations / understandings around this debate. Please point out the incorrect ones. * Most developers here agree that 1 MB is not a magic constant and that the limit has to increase eventually. * Most developers want to reduce the amount of policy decisions bitcoin-core makes as much as possible. * The most conservative option for the 4 billion dollar system that is bitcoin is to keep the limit. * Technological growth in bandwidth, cpu and storage exists and relative to that growth, the blocksize limit is effectively decreased. Keeping the limit as it is today, or was five years ago, means we need to adjust for technological growth. * Doing so will not reduce current decentralization, however measured. * Increasing the blocksize limit will always require a hard-fork. Decreasing, or stopping the growth of the blocksize limit will always be possible via soft-fork. * Problems arising from underestimating the need for a larger blocksize limit are increasingly harder to fix. Problems arising from a limit that is getting too high are more easy to fix. * This means we can be optimistic when estimating future technological growth. --001a114d6f181f3cab051d902997 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm going to list a few assumtions / observations= / understandings around this debate. Please point out the incorrect ones.<= br>

* Most developers here agree that 1 MB is not = a magic constant and that the limit has to increase eventually.
<= br>
* Most developers want to reduce the amount of policy decisio= ns bitcoin-core makes as much as possible.

* The m= ost conservative option for the 4 billion dollar system that is bitcoin is = to keep the limit.

* Technological growth in bandw= idth, cpu and storage exists and relative to that growth, the blocksize lim= it is effectively decreased. Keeping the limit as it is today, or was five = years ago, means we need to adjust for technological growth.

=
* Doing so will not reduce current decentralization, however mea= sured.

* Increasing the blocksize limit will alway= s require a hard-fork. Decreasing, or stopping the growth of the blocksize = limit will always be possible via soft-fork.

* Pro= blems arising from underestimating the need for a larger blocksize limit ar= e increasingly harder to fix. Problems arising from a limit that is getting= too high are more easy to fix.

* This means = we can be optimistic when estimating future technological growth.

--001a114d6f181f3cab051d902997--