Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id CF6B1282 for ; Wed, 11 May 2016 10:48:21 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wm0-f54.google.com (mail-wm0-f54.google.com [74.125.82.54]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D6502E4 for ; Wed, 11 May 2016 10:48:20 +0000 (UTC) Received: by mail-wm0-f54.google.com with SMTP id a17so75142411wme.0 for ; Wed, 11 May 2016 03:48:20 -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=u/3SSxsQOMNLKa8CuNemWVRfqA7FTKxG4QOVf7v459U=; b=HtTyEioYSoHBMbXRyCxqZz3gl4DV2gQQxxGNJRKx1r5S7QJbf27cSGBrmnvX5yJZXD Rtlbhd1Ck1E8I/EmemQiru1/Cez+1raRXxpA29hd0dEsDBSSx/Ngu1dfPBFCkzStZFRS 1ed+Hfe3xSVO9SuBtDeIz6ZEwBCsZ8Ytv23hA6UzI3q8t3G5HTGyb44pDYBiIUA3dfJw R1xmYrXbG+P0JnRDsohk0RYBaGNhlJyRCmabdTe6eM3hBGquNeFRS74kKnbGmM4C0s9w NpcfRWNQ4kBvSwCe8zl//wKYZbCUh0EtCrga7HCAmROazgG0jXUv2JJQ/JaDvdyLYJw3 0SXQ== 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=u/3SSxsQOMNLKa8CuNemWVRfqA7FTKxG4QOVf7v459U=; b=cVzpFge3g2ONJmhovs9F/5aaqtv0iZsLF7JLUPBCwGACiXJtyqq/NwfJfJ5VcEuE5r FH69pp/RA4QJzB+VbdGH2MGS9mNI3+La/1ArVxlmZP5pBpbKALvffXsGZeptoooPmC/h uetoGWUZ2ZoV8sX1RgzQM3rAHPBCtf+v+WU/KUK9q8mat9ddg4fs5PiGtRMhmEKNwoc6 WvbVL4XJdOJxZPWsG5AAOtFHV/BIHq4JGXvyfkCsqsj7PafkmCLnSZ2y6ihPPXdwKcCK BkHQ135CzNEu2SU735/DMxXEx2bQ8H9SO6UD08YA+ABhE37NlJg0fN4aQEsX4jbIEQHX kMrw== X-Gm-Message-State: AOPr4FXRcZhEiKaJqsxDWHdgTN8TNma91GBUgWhHLoPbseETIsLFQqLha2Nw0HuiaoiOQw== X-Received: by 10.194.63.226 with SMTP id j2mr2973304wjs.27.1462963699379; Wed, 11 May 2016 03:48:19 -0700 (PDT) Received: from mail-wm0-f48.google.com (mail-wm0-f48.google.com. [74.125.82.48]) by smtp.gmail.com with ESMTPSA id gk6sm7405153wjc.31.2016.05.11.03.48.18 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 May 2016 03:48:18 -0700 (PDT) Received: by mail-wm0-f48.google.com with SMTP id n129so213999034wmn.1 for ; Wed, 11 May 2016 03:48:18 -0700 (PDT) X-Received: by 10.28.181.148 with SMTP id e142mr3387151wmf.38.1462963698154; Wed, 11 May 2016 03:48:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.155.36 with HTTP; Wed, 11 May 2016 03:47:58 -0700 (PDT) In-Reply-To: <20160511103601.GC2439@banane.informatik.uni-ulm.de> References: <20160510185728.GA1149@fedora-21-dvm> <20160511103601.GC2439@banane.informatik.uni-ulm.de> From: Jannes Faber Date: Wed, 11 May 2016 12:47:58 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Henning Kopp Content-Type: multipart/alternative; boundary=001a114a0dc68c5c7305328ec76c 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 Cc: Bitcoin Protocol Discussion 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:48:21 -0000 --001a114a0dc68c5c7305328ec76c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 11 May 2016 at 12:36, Henning Kopp wrote: > 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 o= r > > > not. So you don=E2=80=99t know what percentage of the hashrate uses A= sicBoost > 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 =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 afte= r > a > > > hardfork that is only contentious but doesn=E2=80=99t change the mini= ng > algorithm, > > > the kind of hardfork you are proposing would guarantee the persistenc= e > 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, bu= t > > rather AsicBoost blocks will continue to be ignored (orphaned) until th= ey > > 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. > > No: you are still assuming AsicBoost miners would reject normal blocks. They don't now and they would have to specifically code for that as a reply to AsicBoost being banned. So there won't be two chains at all, only the main chain with a lot (more than usual) of short (few blocks) forks. Each forks starts anew, it's not one long fork. Therefore there is no "difficulty adjustment on the AiscBoost chain". Now if they do decide to ban non-AsicBoost blocks as a response to being banned themselves, they're just another altcoin with a different PoW and no one would have a reason to use them over Bitcoin (apart from maybe selling those forked coins asap). You're confused about what "longest" means as well: it's not just the number of blocks, it's the aggregate difficulty that counts: so AsicBoost would never become "longer" (more total work) either. Hope this helps clear things up. -- Jannes --001a114a0dc68c5c7305328ec76c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 11 May 2016 at 12:36, Henning Kopp &l= t;henning.kopp= @uni-ulm.de> wrote:
On Wed, Ma= y 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@l= ists.linuxfoundation.org> wrote:
>
> > There is no way to tell from a block if it was mined with AsicBoo= st or
> > not. So you don=E2=80=99t know what percentage of the hashrate us= es 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 cha= nge the
> > block mining algorithm some percentage of hardware will no longer= be able
> > to produce valid blocks. That hardware cannot =E2=80=9Cswitch ove= r=E2=80=9D to the majority
> > chain even if it wanted to. Hence you are guaranteed to have two<= br> > > 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 algorithm,
> > the kind of hardfork you are proposing would guarantee the persis= tence of
> > two chains.
> >
>
> Assuming AsicBoost miners are in the minority, their chain will consta= ntly
> get overtaken. So it will not be one endless hard fork as you claim, b= ut
> rather AsicBoost blocks will continue to be ignored (orphaned) until t= hey
> stop making them.

At least until a difficulty adjustment on the AsicBoost chain takes<= br> place. From that point on, both chains, the AsicBoost one and the
forked one will grow approximately at the same speed.


No: you are still assuming AsicBoost m= iners would reject normal blocks. They don't now and they would have to= specifically code for that as a reply to AsicBoost being banned. So there = won't be two chains at all, only the main chain with a lot (more than u= sual) of short (few blocks) forks. Each forks starts anew, it's not one= long fork. Therefore there is no "difficulty adjustment on the AiscBo= ost chain".

Now if they do decide to ban non-AsicBoo= st blocks as a response to being banned themselves, they're just anothe= r altcoin with a different PoW and no one would have a reason to use them o= ver Bitcoin (apart from maybe selling those forked coins asap).

You're confused about what "longest" means as well: it= 's not just the number of blocks, it's the aggregate difficulty tha= t counts: so AsicBoost would never become "longer" (more total wo= rk) either.

Hope this helps c= lear things up.

--
Jannes
--001a114a0dc68c5c7305328ec76c--