From: Peter Todd <pete@petertodd•org>
To: Timo Hanke <timo.hanke@web•de>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Making AsicBoost irrelevant
Date: Wed, 11 May 2016 19:01:44 -0400 [thread overview]
Message-ID: <20160511230144.GA5252@fedora-21-dvm> (raw)
In-Reply-To: <CAH6h1Ls_Dh_oBo-fUMoBtwCQ=U3XgBLhbuHvH+ra78bjHYNyXQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3255 bytes --]
On Tue, May 10, 2016 at 08:14:33PM -0700, Timo Hanke 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.
First of all, we can easily do this in a way where miners show their support
for this change, say with the usual 95% approval threshold we've been using for
soft-forks. That gets the % of hashing power on a AsicBoost chain fork down to
5% at most.
Secondly, we can probably make the consensus PoW allow blocks to be mined using
both the existing PoW algorithm, and a very slightly tweaked version where
implementing AsicBoost gives no advantage. That removes any incentive to
implement AsicBoost, without making any hardware obsolete (such as 21inc's
hardware). This means that no hashing power at all needs to use the AsicBoost
patent.
Obviously, the fact that miners can support such a change (assuming of course
the economic majority approves it as well) changes the negotiation position re:
licensing fees; the actual outcome may simply be you guys make the patent 100%
public for all to use at a much reduced price, given you're lack of negotiation
strength.
> 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.
I think _patented_ optimizations where one party has a monopoly are very
different than optimizations that anyone can independently rediscover -
AsicBoost itself looks to be something that two or three parties independently
discovered.
> 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.
...which is a scenario that may result in a dozen patented optimizations, with
new ASIC manufacturers needing a dozen licenses, from potentially hostile
entities.
For instance, it's not clear to me if you actually own this patent, or
Cointerra's creditors. Obviously in the latter case, it'd be quite possible
that some kind of bankrupcy court ruling results in the patent getting sold to
a hostile entity who will use it against all of Bitcoin. Equally, even if it is
100% owned by you and Sergio, it'd be very easy for a personal bankrupcy to
result in the same scenario (suppose you get into a car accident and lose a
negligence lawsuit over it).
--
https://petertodd.org 'peter'[:-1]@petertodd.org
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
next prev parent reply other threads:[~2016-05-11 23:01 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
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 [this message]
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=20160511230144.GA5252@fedora-21-dvm \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=timo.hanke@web$(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