From: Jannes Faber <jannes.faber@gmail•com>
To: Henning Kopp <henning.kopp@uni-ulm•de>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Making AsicBoost irrelevant
Date: Wed, 11 May 2016 12:47:58 +0200 [thread overview]
Message-ID: <CABeL=0ih+BB+AKO6uJRCDGZoVo5is4+GBUfQAJkE48Pd_4vzOQ@mail.gmail.com> (raw)
In-Reply-To: <20160511103601.GC2439@banane.informatik.uni-ulm.de>
[-- Attachment #1: Type: text/plain, Size: 2585 bytes --]
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 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.
>
>
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
[-- Attachment #2: Type: text/html, Size: 3302 bytes --]
next prev parent reply other threads:[~2016-05-11 10:48 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-10 18:57 Peter Todd
2016-05-10 20:27 ` Tier Nolan
2016-05-10 21:35 ` Matt Corallo
2016-05-10 21:43 ` Sergio Demian Lerner
2016-05-10 22:59 ` Matt Corallo
2016-05-11 12:20 ` Sergio Demian Lerner
2016-05-11 13:08 ` Marek Palatinus
2016-05-11 21:01 ` Matt Corallo
2016-05-11 22:16 ` Simon Liu
2016-05-11 22:50 ` Peter Todd
2016-05-11 14:28 ` Luke Dashjr
2016-05-11 16:24 ` Timo Hanke
2016-05-11 18:28 ` Timo Hanke
2016-05-11 22:49 ` Timo Hanke
2016-05-12 2:27 ` Tom Harding
2016-05-12 2:31 ` Allen Piscitello
2016-05-12 2:33 ` Peter Todd
2016-05-12 4:01 ` Tom Harding
2016-05-10 21:49 ` Marco Pontello
2016-05-10 22:17 ` Sergio Demian Lerner
2016-05-10 22:27 ` Chris Riley
2016-05-11 3:14 ` Timo Hanke
2016-05-11 9:21 ` Jannes Faber
2016-05-11 10:36 ` Henning Kopp
2016-05-11 10:47 ` Jannes Faber [this message]
2016-05-11 22:42 ` Timo Hanke
2016-05-11 22:58 ` Gregory Maxwell
2016-05-12 7:29 ` Tom
2016-05-12 11:05 ` Jorge Timón
2016-05-11 14:07 ` Jorge Timón
2016-05-11 14:18 ` Sergio Demian Lerner
2016-05-11 14:30 ` Jannes Faber
2016-05-11 20:50 ` Matt Corallo
2016-05-11 22:00 ` James Hilliard
2016-05-11 23:01 ` Peter Todd
2016-05-12 0:02 ` Gregory Maxwell
2016-05-12 1:23 ` Russell O'Connor
2016-05-12 1:58 ` Peter Todd
2016-05-12 1:58 ` Matt Corallo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CABeL=0ih+BB+AKO6uJRCDGZoVo5is4+GBUfQAJkE48Pd_4vzOQ@mail.gmail.com' \
--to=jannes.faber@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=henning.kopp@uni-ulm$(echo .)de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox