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 4DB14415 for ; Sat, 26 Nov 2016 15:01:06 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mx-out03.mykolab.com (mx.kolabnow.com [95.128.36.1]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 49F45A1 for ; Sat, 26 Nov 2016 15:01:05 +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 mx05.mykolab.com (mx05.mykolab.com [10.20.7.161]) by mx-out03.mykolab.com (Postfix) with ESMTPS id 4C771235A6 for ; Sat, 26 Nov 2016 16:01:02 +0100 (CET) From: Tom Zander To: Bitcoin Protocol Discussion Date: Sat, 26 Nov 2016 16:01:16 +0100 Message-ID: <2318925.r6f9XVyAit@cherry> In-Reply-To: References: 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: Sat, 26 Nov 2016 15:22:19 +0000 Subject: Re: [bitcoin-dev] The Excessive-Block Gate: How a Bitcoin Unlimited Node Deals With Large Blocks 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: Sat, 26 Nov 2016 15:01:06 -0000 On Friday, 25 November 2016 20:45:20 CET Sergio Demian Lerner wrote: > I now think my reasoning and conclusions are based on a false premise: > that BU block size policies for miners can be heterogeneous. Agreed. > There can't be short forks because forks are not in the best interest of > the honest miner majority. All miners need to announce and follow the same > block size policy to prevent short forks. What you appear to want to say is that it is in everyones best interest to avoid short forks. Its impossible to guarentee they can't happen, but very possible to minimize them. > If block size negotiations are meant to be open and carried on on-chain, > then it's much better to let miners increase or decrease the block size > limit by 1% per block (such as what Ethereum does with the gas limit). No, there are no block-size-negotiations on chain. The blockchain is used here for one purpose, to state the position of individual miners. But what may not be clear is that you can use this as a time-stamped way to hold them to it. Which means that if they lie (by rejecting a block), everyone in the world will be able to individually verify that fact and their credibility will be affected. Which will not help their case next time any block size negotiations will happen. -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel