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 02821256 for ; Wed, 11 May 2016 22:42:41 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 510679C for ; Wed, 11 May 2016 22:42:39 +0000 (UTC) Received: by mail-lb0-f178.google.com with SMTP id pj6so2589234lbb.2 for ; Wed, 11 May 2016 15:42:39 -0700 (PDT) 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:date :message-id:subject:from:to:cc; bh=9+VVc4wbZ6yIZJ3PuooIPpjeKIleY53xvq/d3udxTAU=; b=KfSQsoOAFAf56o7ZkAyNHvpKBznSt8UjC7/HCYDwXB1OPvt3EDcCaOFCTs1NckNsfn qjRA4IcUTPwYmKane4As9ZpHxV6DAl4wfKuTn44kmaMHp4j6AS7QCyVAQiv7pCa6Ef6p JjWmNgIN7xAodIoEVihaAd+v12o5U+Tl077Rr9ba6qTGzRInPn/cwcmpOnnzKKPwk2IM QvxEFlZoY1GX35SSpvkULj8wlJEgtXHeQBBAcFBQbMtpQ3meREqAUvdRTVIrsJmnm3UC fMlPp9dlFyzl2aYjnZ7wUap1e5rMLVL81vlF7j0pusJ/txxCTm5yLiS55t83DDtWES7w iQVA== X-Gm-Message-State: AOPr4FUnfBDARgK7GeFscLWOAfFgr7f9D8GZMc2YIzZzPiVTv+PPDEj7IHIjfmDyaslQvg== X-Received: by 10.112.147.7 with SMTP id tg7mr2806985lbb.118.1463006557587; Wed, 11 May 2016 15:42:37 -0700 (PDT) Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com. [209.85.217.175]) by smtp.gmail.com with ESMTPSA id rf6sm1621878lbb.0.2016.05.11.15.42.35 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 May 2016 15:42:37 -0700 (PDT) Received: by mail-lb0-f175.google.com with SMTP id jj5so2581165lbc.0 for ; Wed, 11 May 2016 15:42:35 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.158.135 with SMTP id wu7mr2828761lbb.2.1463006555539; Wed, 11 May 2016 15:42:35 -0700 (PDT) Received: by 10.25.144.8 with HTTP; Wed, 11 May 2016 15:42:35 -0700 (PDT) In-Reply-To: References: <20160510185728.GA1149@fedora-21-dvm> <20160511103601.GC2439@banane.informatik.uni-ulm.de> Date: Wed, 11 May 2016 15:42:35 -0700 X-Gmail-Original-Message-ID: Message-ID: From: Timo Hanke To: Jannes Faber Content-Type: multipart/alternative; boundary=001a11c388760c14ac053298c247 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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 22:42:41 -0000 --001a11c388760c14ac053298c247 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, May 11, 2016 at 3:47 AM, Jannes Faber wrote: > 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 = 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? Not= e >> 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 >> after a >> > > hardfork that is only contentious but doesn=E2=80=99t change the min= ing >> 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, b= ut >> > 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. >> >> > 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 rep= ly > 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 sellin= g > those forked coins asap). > This is what I meant. If existing hardware gets forked-out it will inevitably lead to the creation of an altcoin. Simply because the hardware exists and can't be used for anything else both chains will survive. I was only comparing the situation to a contentious hardfork that does not fork out any hardware. If the latter one is suspected to lead to the permanent existence of two chains then a hardfork that forks out hardware is even more likely to do so (I claim it's guaranteed). > 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 > --001a11c388760c14ac053298c247 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, May 11, 2016 at 3:47 AM, Jannes Faber <jannes.faber@gmail.com= > wrote:
On 11 May 2016 at 12:36, Henning Kopp <henning.kopp@uni-= ulm.de> 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 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 Asic= Boost 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).
<= /div>

This is what I mean= t. If existing hardware gets forked-out it will inevitably lead to the crea= tion of an altcoin. Simply because the hardware exists and can't be use= d for anything else both chains will survive. I was only comparing the situ= ation to a contentious hardfork that does not fork out any hardware. If the= latter one is suspected to lead to the permanent existence of two chains t= hen a hardfork that forks out hardware is even more likely to do so (I clai= m it's guaranteed).

=

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

Hope thi= s helps clear things up.

--
Jannes

--001a11c388760c14ac053298c247--