Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YqlZ4-0005zx-Qy for bitcoin-development@lists.sourceforge.net; Fri, 08 May 2015 16:55:54 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.215.41 as permitted sender) client-ip=209.85.215.41; envelope-from=kanzure@gmail.com; helo=mail-la0-f41.google.com; Received: from mail-la0-f41.google.com ([209.85.215.41]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YqlYz-0003cx-9T for bitcoin-development@lists.sourceforge.net; Fri, 08 May 2015 16:55:54 +0000 Received: by layy10 with SMTP id y10so56831899lay.0 for ; Fri, 08 May 2015 09:55:42 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.156.97 with SMTP id wd1mr3494612lbb.30.1431104142891; Fri, 08 May 2015 09:55:42 -0700 (PDT) Received: by 10.152.18.168 with HTTP; Fri, 8 May 2015 09:55:42 -0700 (PDT) In-Reply-To: <16096345.A1MpJQQkRW@crushinator> References: <16096345.A1MpJQQkRW@crushinator> Date: Fri, 8 May 2015 11:55:42 -0500 Message-ID: From: Bryan Bishop To: Matt Whitlock , Bryan Bishop Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -1.6 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (kanzure[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1YqlYz-0003cx-9T Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Proposed alternatives to the 20MB step function X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 16:55:54 -0000 On Fri, May 8, 2015 at 2:20 AM, Matt Whitlock wrote: > - Perhaps the hard block size limit should be a function of the actual block sizes over some > trailing sampling period. For example, take the median block size among the most recent > 2016 blocks and multiply it by 1.5. This allows Bitcoin to scale up gradually and organically, > rather than having human beings guessing at what is an appropriate limit. Block contents can be grinded much faster than hashgrinding and mining. There is a significant run-away effect there, and it also works in the gradual sense as a miner probabilistically mines large blocks that get averaged into that 2016 median block size computation. At least this proposal would be a slower way of pushing out miners and network participants that can't handle 100 GB blocks immediately.. As the size of the blocks are increased, low-end hardware participants have to fall off the network because they no longer meet the minimum performance requirements. Adjustment might become severely mismatched with general economic trends in data storage device development or availability or even current-market-saturation of said storage devices. With the assistance of transaction stuffing or grinding, that 2016 block median metric can be gamed to increase faster than other participants can keep up with or, perhaps worse, in a way that was unintended by developers yet known to be a failure mode. These are just some issues to keep and mind and consider. - Bryan http://heybryan.org/ 1 512 203 0507