Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 259C9411 for ; Wed, 11 May 2016 10:36:17 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from smtp.uni-ulm.de (smtp.uni-ulm.de [134.60.1.26]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 53FA4E4 for ; Wed, 11 May 2016 10:36:15 +0000 (UTC) X-Virus-Scanned: amavisd-new at uni-ulm.de Received: from banane.informatik.uni-ulm.de (banane.informatik.uni-ulm.de [134.60.77.114]) (authenticated bits=0) by mail.uni-ulm.de (8.14.9/8.14.9) with ESMTP id u4BAa6cV005304 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 11 May 2016 12:36:07 +0200 (CEST) Date: Wed, 11 May 2016 12:36:01 +0200 From: Henning Kopp To: Jannes Faber , Bitcoin Protocol Discussion Message-ID: <20160511103601.GC2439@banane.informatik.uni-ulm.de> References: <20160510185728.GA1149@fedora-21-dvm> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) X-DCC-x.dcc-servers-Metrics: poseidon 104; Body=3 Fuz1=3 Fuz2=3 X-Spam-Status: No, score=-3.3 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_NONE, RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Making AsicBoost irrelevant 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: Wed, 11 May 2016 10:36:17 -0000 On Wed, May 11, 2016 at 11:21:10AM +0200, Jannes Faber via bitcoin-dev wrote: > On 11 May 2016 at 05:14, Timo Hanke via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > > There is no way to tell from a block if it was mined with AsicBoost or > > not. So you don’t know what percentage of the hashrate uses AsicBoost at > > any point in time. How can you risk forking that percentage out? Note that > > this would be a GUARANTEED chain fork. Meaning that after you change the > > block mining algorithm some percentage of hardware will no longer be able > > to produce valid blocks. That hardware cannot “switch over” to the majority > > chain even if it wanted to. Hence you are guaranteed to have two > > co-existing bitcoin blockchains afterwards. > > > > Again: this is unlike the hypothetical persistence of two chains after a > > hardfork that is only contentious but doesn’t change the mining algorithm, > > the kind of hardfork you are proposing would guarantee the persistence of > > two chains. > > > > Assuming AsicBoost miners are in the minority, their chain will constantly > get overtaken. So it will not be one endless hard fork as you claim, but > rather AsicBoost blocks will continue to be ignored (orphaned) until they > stop making them. At least until a difficulty adjustment on the AsicBoost chain takes place. From that point on, both chains, the AsicBoost one and the forked one will grow approximately at the same speed. All the best Henning -- Henning Kopp Institute of Distributed Systems Ulm University, Germany Office: O27 - 3402 Phone: +49 731 50-24138 Web: http://www.uni-ulm.de/in/vs/~kopp