Date: Wed, 11 May 2016 19:01:44 -0400
From: Peter Todd <pete@petertodd.org>
To: Timo Hanke <timo.hanke@web.de>
Message-ID: <20160511230144.GA5252@fedora-21-dvm>
References: <20160510185728.GA1149@fedora-21-dvm>
	<CAH6h1Ls_Dh_oBo-fUMoBtwCQ=U3XgBLhbuHvH+ra78bjHYNyXQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="J/dobhs11T7y2rNN"
Content-Disposition: inline
In-Reply-To: <CAH6h1Ls_Dh_oBo-fUMoBtwCQ=U3XgBLhbuHvH+ra78bjHYNyXQ@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Making AsicBoost irrelevant
Precedence: list


--J/dobhs11T7y2rNN
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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 no=
t.
> 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? Note that th=
is
> 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.

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 u=
sing
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 AsicBoo=
st
patent.

Obviously, the fact that miners can support such a change (assuming of cour=
se
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 1=
00%
public for all to use at a much reduced price, given you're lack of negotia=
tion
strength.

> Note that =E2=80=9CAsicBoost=E2=80=9D above is replaceable with =E2=80=9C=
optimization X=E2=80=9D. It=E2=80=99s
> 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=E2=80=99t make these kind of chan=
ges.
> 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 independen=
tly
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.

=2E..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 i=
t 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).

--=20
https://petertodd.org 'peter'[:-1]@petertodd.org

--J/dobhs11T7y2rNN
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJXM7nVAAoJEGOZARBE6K+y6LQH/1IrkZMlvNj5Q1CNsmdEvhzf
W3qjgzOnzTI5eEeNf3Rbpv4/+7UDLuL4QwYLLUTsY0ZaZhgfjCSfRPXiMuL4u4tP
KcqF5JZbPvFHiPsQIu+oFyGtyMengRTcESRYofFcqXlZrjP/9skC4+wrkPvGuqoo
LyS6MDTa04mOHlyDrgiUkQ1VzImVWz0QhhE1QtO04MqFr35qMCtNwGoqf5WqeZk8
7hv7howUIUJ+ognPNGFK0mLRoConLMnx1mL4QBjYqzzqRRRWVx8TrICL0bTH4geg
h4vLPNEmIQS6h0NZzZTToeM2fPnVTlaFuXZOmfZoKLOQu0pGSxXHi7fErO2oVuk=
=DsoY
-----END PGP SIGNATURE-----

--J/dobhs11T7y2rNN--