public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Timo Hanke <timo.hanke@web.de>
To: Peter Todd <pete@petertodd.org>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Making AsicBoost irrelevant
Date: Tue, 10 May 2016 20:14:33 -0700	[thread overview]
Message-ID: <CAH6h1Ls_Dh_oBo-fUMoBtwCQ=U3XgBLhbuHvH+ra78bjHYNyXQ@mail.gmail.com> (raw)
In-Reply-To: <20160510185728.GA1149@fedora-21-dvm>

[-- Attachment #1: Type: text/plain, Size: 3307 bytes --]

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.

Note that “AsicBoost” above is replaceable with “optimization X”. It’s
simply a logical argument: If you want to make optimization X impossible
and someone is already using optimization X you end up with two chains. So
unless you know exactly which optimizations are in use (and therefore also
know which ones are not in use) you can’t make these kind of changes.
AsicBoost is known at least since middle of 2013.

To be more precise, if you change the block validation ruleset R to block
validation ruleset S you have to make sure that every hardware that was
capable of mining R-valid blocks is also capable of mining S-valid blocks.

The problem is that chip manufacturers will not tell you which
optimizations they use. You would have to threaten to irreversibly fork
their hardware out by a rule change, only then would they start shouting
and reveal their optimization. It seems extremely dangerous to set the
precedence of a hardfork that irreversibly forks out a certain type of
mining hardware.

The part "Also the fix should be compatible with existing mining hardware."
is impossible to achieve because it's unclear what "existing mining
hardware" is. There has never been a specification of what mining hardware
should do. There are only acceptance rules.

The only way out is to go the exact opposite way and to embrace as many
optimizations as possible to the point where there are no more
optimizations left to do, or hopefully getting very close to that point.

Timo



On Tue, May 10, 2016 at 11:57 AM, Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> As part of the hard-fork proposed in the HK agreement(1) we'd like to make
> the
> patented AsicBoost optimisation useless, and hopefully make further similar
> optimizations useless as well.
>
> What's the best way to do this? Ideally this would be SPV compatible, but
> if it
> requires changes from SPV clients that's ok too. Also the fix this should
> be
> compatible with existing mining hardware.
>
>
> 1)
> https://medium.com/@bitcoinroundtable/bitcoin-roundtable-consensus-266d475a61ff
>
> 2)
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-April/012596.html
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 4533 bytes --]

  parent reply	other threads:[~2016-05-11  3:14 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-10 18:57 [bitcoin-dev] Making AsicBoost irrelevant 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 [this message]
2016-05-11  9:21   ` Jannes Faber
2016-05-11 10:36     ` Henning Kopp
2016-05-11 10:47       ` Jannes Faber
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='CAH6h1Ls_Dh_oBo-fUMoBtwCQ=U3XgBLhbuHvH+ra78bjHYNyXQ@mail.gmail.com' \
    --to=timo.hanke@web.de \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=pete@petertodd.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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