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 6469E71E for ; Wed, 11 May 2016 09:21:33 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wm0-f53.google.com (mail-wm0-f53.google.com [74.125.82.53]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8FF9D63 for ; Wed, 11 May 2016 09:21:32 +0000 (UTC) Received: by mail-wm0-f53.google.com with SMTP id g17so71033974wme.1 for ; Wed, 11 May 2016 02:21:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ylHEjThBMowkJv4b4hJb5LeiWPKeY3IXWUbmmR3QgPQ=; b=pcu63lzguybZsuNPLOrQZEEnvW5xsCv7uUAuLg/7+MW7yCDqoW6S+lCNmvpKHAd8AQ fXPwB7mW1MiVpyksagp3ZLp71sQeyquWq4tFM8Af7NV7urbL84XwisR/QXZ7pMdZUDzb TQ35MgNBwk5FnTAs7g3Xd3ydzeZ1aJWx9kCHgwB8FoR0huUHzrANuBK6exwJm3kmE4zj UsQydd90aKEVs8Il5VeFn6104fNF5vrrh4D6C5N2pg8VJy3MigPIGrJm9WakolyrUB4l J5ABkVshG/K8Xpz7S4oY7OpmywIxxDJQZ1SB1ttHjA6Y34xbW57hMHkf9O5jkU3Dvg4Q NdVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ylHEjThBMowkJv4b4hJb5LeiWPKeY3IXWUbmmR3QgPQ=; b=BWse8XQWdGiG8Kd2ct2tci0cs6T/GvZV5xdVfeb8PDhm7yb+FBSLkvBf/jMum9zu+S CeQRb/RWhoQjwt+X0OMvkqXeS3DzswhhSV6WNeSudBZx8XPkHa4THIA4V0btT7UpEVCP K8RZptf+HazydoSTP9vZflFXJAsKHw9aV/Oegm8oIjbezN0a4NyRaS1zNF6Mt2x3Zvqq TY4MCTqxk3bgMZa6vklDgq+s7yfO/Und9rzUT43LGwTJmPS8WV2byQo5RXyYqGhgRwVQ 8WNdsNfQrRinKljbRUGqcTnWA9Q60K6bY7OHN9r0LuiGs3xhvubcuPtbzd4l6zJphUnH pwTQ== X-Gm-Message-State: AOPr4FXkHI7ZZ6wzfD+FW7gSEDKA60lRQxKFHUg/vmaqBhMFUR4gNpXoDyqY/O3Z3qgOqg== X-Received: by 10.28.32.147 with SMTP id g141mr245585wmg.22.1462958491193; Wed, 11 May 2016 02:21:31 -0700 (PDT) Received: from mail-wm0-f50.google.com (mail-wm0-f50.google.com. [74.125.82.50]) by smtp.gmail.com with ESMTPSA id f135sm7421590wmf.22.2016.05.11.02.21.29 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 May 2016 02:21:30 -0700 (PDT) Received: by mail-wm0-f50.google.com with SMTP id n129so210943339wmn.1 for ; Wed, 11 May 2016 02:21:29 -0700 (PDT) X-Received: by 10.194.205.167 with SMTP id lh7mr2568942wjc.30.1462958489785; Wed, 11 May 2016 02:21:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.155.36 with HTTP; Wed, 11 May 2016 02:21:10 -0700 (PDT) In-Reply-To: References: <20160510185728.GA1149@fedora-21-dvm> From: Jannes Faber Date: Wed, 11 May 2016 11:21:10 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Timo Hanke , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary=047d7b8739e81af01e05328d91a1 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,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: 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 09:21:33 -0000 --047d7b8739e81af01e05328d91a1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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=E2=80=99t know what percentage of the hashrate uses AsicB= oost at > any point in time. How can you risk forking that percentage out? Note tha= t > 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 =E2=80=9Cswitch over=E2=80= =9D 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=E2=80=99t change the mining a= lgorithm, > 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. That hardware cannot =E2=80=9Cswitch over=E2=80=9D to the majority chain ev= en if it wanted > to. > They will in fact continually "switch over" to the majority, they just are unable to extend that majority chain themselves. -- Jannes --047d7b8739e81af01e05328d91a1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On 11 May 2016 at 05:14, Timo Hanke via bitcoin-dev <<= a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">b= itcoin-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=E2= =80=99t 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 b= e a GUARANTEED chain fork. Meaning that after you change the block mining a= lgorithm some percentage of hardware will no longer be able to produce vali= d blocks. That hardware cannot =E2=80=9Cswitch over=E2=80=9D to the majorit= y chain even if it wanted to. Hence you are guaranteed to have two co-exist= ing bitcoin blockchains afterwards.

Again: this is= unlike the hypothetical persistence of two chains after a hardfork that is= only contentious but doesn=E2=80=99t change the mining algorithm, the kind= of hardfork you are proposing would guarantee the persistence of two chain= s.

Assuming AsicBoost miners ar= e in the minority, their chain will constantly get overtaken. So it will no= t be one endless hard fork as you claim, but rather AsicBoost blocks will c= ontinue to be ignored (orphaned) until they stop making them.

=
Tha= t hardware cannot =E2=80=9Cswitch over=E2=80=9D to the majority chain even = if it wanted to.

They will in f= act continually "switch over" to the majority, they just are unab= le to extend that majority chain themselves.

--
Jannes=
--047d7b8739e81af01e05328d91a1--