path: root/b7/9427f9f5887be6886af25908758504418625ff

Return-Path: <timo.t.hanke@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 4CA0B267
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 11 May 2016 03:14:38 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lf0-f44.google.com (mail-lf0-f44.google.com
	[209.85.215.44])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 037C390
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 11 May 2016 03:14:36 +0000 (UTC)
Received: by mail-lf0-f44.google.com with SMTP id j8so35015491lfd.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 10 May 2016 20:14:36 -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;
	bh=PdcOqw70aRzmErtt3iZd6ezHmN/pkeAcwpnB5VmUCtw=;
	b=GwtIFADwV3BDHIAodJauGx0WvIMmxXuFFa13lHiP4/6U7nDcYG7P5Un4aX1XptdQg9
	nQndyLVZQlT8Ttx7eRkObVOaaV/HwPgG7vLIIU9zFU3k0NDd6DhsDuqiMdFa/3twjlH9
	JvvUoT7RwBWRLPtd7OmoVwXqqVRot2SgEWlvAUR41uMgPWYdOQHJm1XrXLKCjFTuWMfR
	aQW0ZptYjlGj6OJGkTewY05hxXK8oHDOTINwXXqQ/unXUUBafuKhtuqZpj2xMUMJ2+bJ
	gZIyVkC/rSmmtaFw0RakDNhjLrgY/aDS+99tX3QfOsu5fB73gaiUhwVhv5Lxdjp9+KJQ
	qZcQ==
X-Gm-Message-State: AOPr4FXmxnvmlMg+5evicCXdWgsRXRhBFAQ87KMpWJ6Jg+8HBK4KikVrL6De07RCuYXI7w==
X-Received: by 10.112.181.72 with SMTP id du8mr363893lbc.137.1462936475233;
	Tue, 10 May 2016 20:14:35 -0700 (PDT)
Received: from mail-lf0-f49.google.com (mail-lf0-f49.google.com.
	[209.85.215.49])
	by smtp.gmail.com with ESMTPSA id aq4sm893137lbc.18.2016.05.10.20.14.34
	for <bitcoin-dev@lists.linuxfoundation.org>
	(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 10 May 2016 20:14:34 -0700 (PDT)
Received: by mail-lf0-f49.google.com with SMTP id u64so35285269lff.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 10 May 2016 20:14:34 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.25.147.68 with SMTP id v65mr386315lfd.9.1462936474021; Tue,
	10 May 2016 20:14:34 -0700 (PDT)
Received: by 10.25.144.8 with HTTP; Tue, 10 May 2016 20:14:33 -0700 (PDT)
In-Reply-To: <20160510185728.GA1149@fedora-21-dvm>
References: <20160510185728.GA1149@fedora-21-dvm>
Date: Tue, 10 May 2016 20:14:33 -0700
X-Gmail-Original-Message-ID: <CAH6h1Ls_Dh_oBo-fUMoBtwCQ=U3XgBLhbuHvH+ra78bjHYNyXQ@mail.gmail.com>
Message-ID: <CAH6h1Ls_Dh_oBo-fUMoBtwCQ=U3XgBLhbuHvH+ra78bjHYNyXQ@mail.gmail.com>
From: Timo Hanke <timo.hanke@web.de>
To: Peter Todd <pete@petertodd.org>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a114029eedcfc460532887052
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
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 11 May 2016 03:14:38 -0000

--001a114029eedcfc460532887052
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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? 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 =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 mining alg=
orithm,
the kind of hardfork you are proposing would guarantee the persistence of
two chains.

Note that =E2=80=9CAsicBoost=E2=80=9D above is replaceable with =E2=80=9Cop=
timization 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 change=
s.
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 mak=
e
> the
> patented AsicBoost optimisation useless, and hopefully make further simil=
ar
> 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-266d47=
5a61ff
>
> 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
>
>

--001a114029eedcfc460532887052
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>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 has=
hrate uses AsicBoost at any point in time. How can you risk forking that pe=
rcentage out? Note that this would be a GUARANTEED chain fork. Meaning that=
 after you change the block mining algorithm some percentage of hardware wi=
ll 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 y=
ou are guaranteed to have two co-existing bitcoin blockchains afterwards.</=
div><div><br></div><div>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 persistence of two chains.</div><div><br></div><div>Note that=
 =E2=80=9CAsicBoost=E2=80=9D above is replaceable with =E2=80=9Coptimizatio=
n X=E2=80=9D. It=E2=80=99s simply a logical argument: If you want to make o=
ptimization X impossible and someone is already using optimization X you en=
d 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 changes. AsicBoost is known at least since middle of 201=
3.</div><div><br></div><div>To be more precise, if you change the block val=
idation 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.=C2=A0</div><div><br></div><div>The problem is that =
chip manufacturers will not tell you which optimizations they use. You woul=
d have to threaten to irreversibly fork their hardware out by a rule change=
, only then would they start shouting and reveal their optimization. It see=
ms extremely dangerous to set the precedence of a hardfork that irreversibl=
y forks out a certain type of mining hardware.</div><div><div><br></div><di=
v>The part &quot;Also the fix should be compatible with existing mining har=
dware.&quot; is impossible to achieve because it&#39;s unclear what &quot;e=
xisting mining hardware&quot; is. There has never been a specification of w=
hat mining hardware should do. There are only acceptance rules.</div></div>=
<div><br></div><div>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 poin=
t.=C2=A0</div><div><br></div><div>Timo</div><div><br></div><div><br></div><=
div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, May 10, 20=
16 at 11:57 AM, Peter Todd via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D=
"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-de=
v@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-=
left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">As pa=
rt of the hard-fork proposed in the HK agreement(1) we&#39;d like to make t=
he<br>
patented AsicBoost optimisation useless, and hopefully make further similar=
<br>
optimizations useless as well.<br>
<br>
What&#39;s the best way to do this? Ideally this would be SPV compatible, b=
ut if it<br>
requires changes from SPV clients that&#39;s ok too. Also the fix this shou=
ld be<br>
compatible with existing mining hardware.<br>
<br>
<br>
1) <a href=3D"https://medium.com/@bitcoinroundtable/bitcoin-roundtable-cons=
ensus-266d475a61ff" rel=3D"noreferrer" target=3D"_blank">https://medium.com=
/@bitcoinroundtable/bitcoin-roundtable-consensus-266d475a61ff</a><br>
<br>
2) <a href=3D"http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-A=
pril/012596.html" rel=3D"noreferrer" target=3D"_blank">http://lists.linuxfo=
undation.org/pipermail/bitcoin-dev/2016-April/012596.html</a><br>
<span class=3D""><font color=3D"#888888"><br>
--<br>
<a href=3D"https://petertodd.org" rel=3D"noreferrer" target=3D"_blank">http=
s://petertodd.org</a> &#39;peter&#39;[:-1]@<a href=3D"http://petertodd.org"=
 rel=3D"noreferrer" target=3D"_blank">petertodd.org</a><br>
</font></span><br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div><br></div></div>

--001a114029eedcfc460532887052--