Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 4CA0B267 for ; 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 ; Wed, 11 May 2016 03:14:36 +0000 (UTC) Received: by mail-lf0-f44.google.com with SMTP id j8so35015491lfd.2 for ; 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 (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 ; 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: Message-ID: From: Timo Hanke To: Peter Todd , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
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.

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.

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.

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

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.

The part "Also the fix should be compatible with existing mining har= dware." is impossible to achieve because it's unclear what "e= xisting mining hardware" is. There has never been a specification of w= hat 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 poin= t.=C2=A0

Timo


<= div class=3D"gmail_extra">
On Tue, May 10, 20= 16 at 11:57 AM, Peter Todd via bitcoin-dev <bitcoin-de= v@lists.linuxfoundation.org> wrote:
As pa= rt of the hard-fork proposed in the HK agreement(1) we'd like to make t= he
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, b= ut if it
requires changes from SPV clients that's ok too. Also the fix this shou= ld be
compatible with existing mining hardware.


1) https://medium.com= /@bitcoinroundtable/bitcoin-roundtable-consensus-266d475a61ff

2) http://lists.linuxfo= undation.org/pipermail/bitcoin-dev/2016-April/012596.html

--
http= s://petertodd.org 'peter'[:-1]@petertodd.org

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev


--001a114029eedcfc460532887052--