Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id ACCC79C for ; Mon, 2 Jan 2017 22:32:22 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mx-out01.mykolab.com (mx.kolabnow.com [95.128.36.1]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C88E217B for ; Mon, 2 Jan 2017 22:32:21 +0000 (UTC) X-Virus-Scanned: amavisd-new at kolabnow.com X-Spam-Score: -2.9 X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 Received: from mx03.mykolab.com (mx03.mykolab.com [10.20.7.101]) by mx-out01.mykolab.com (Postfix) with ESMTPS id 1485760201 for ; Mon, 2 Jan 2017 23:32:19 +0100 (CET) From: Tom Zander To: Bitcoin Protocol Discussion Date: Mon, 02 Jan 2017 23:33:16 +0100 Message-ID: <2491464.ujv6hLnuF3@cherry> In-Reply-To: References: <1944321.hguq3JoYe1@cherry> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Tue, 03 Jan 2017 07:09:02 +0000 Subject: Re: [bitcoin-dev] BIP - 'Block75' - New algorithm 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: Mon, 02 Jan 2017 22:32:22 -0000 On Monday, 2 January 2017 16:05:58 CET t. khan wrote: > On Mon, Jan 2, 2017 at 3:35 PM, Tom Zander wrote: > > If the input of your math is completely free and human created, how does > > it follow that it was math that created it ? > > Why do you want it math created anyway? > > The beauty of math is that everyone on the planet agrees how it works. > Everything in Bitcoin is math, with the exception of the blocksize limit > (1MB) which was a stop-gap solution at the time. In actual fact the block size *is* set by miners, not math. And always has been. In your proposal the max blocksize continues to be set by miners as a secondary effect of them choosing the block size. Saying the max is actually math is painting an illusion that is rather thin and easy to see through because every single usecase for your suggestion starts with the choice of blocksize that a human makes. There is not really any other input except some rather simple algorithm. > > A maximum is needed, yes. But does it have to be part of the protocol? > > A simple policy which is set by node operators (reject block if greater > > than > > X bytes) will solve this just fine, no? > > No. That would be an epic disaster. There's no such thing as a "simple > policy" when humans are involved. This is ignoring history where miners have successfully set policy on block size for years now. > Obviously no one would agree on what X > bytes would be and you'd have some nodes rejecting blocks that others > already accepted. Not sure about your "obviously". I don't agree. In fact, there is plenty of reason to think it does work. Miners have always been the ones to decide on the block size, and they have always done this in a coordinated fashion. This is a natural consequence of the rather elegant (economic) design of Bitcoin. * Miners earn more fee-based income when they produce bigger blocks. * Miners take more risk of their blocks being orphaned with bigger blocks. * Miners want to avoid emptying the memory pool every block as that removes a total need for users to pay fees. * Miners want to make sure the mempool does not become backlogged because users that do not see their transactions confirmed will get disappointed and find other means to do payments. Which hurts the price and in effect hurts the miners income. This behaviour in block size means blocks will not get huge and they will not stay small either, because there are reasons for both. And so the size will be something in the middle. -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel