Re: [bitcoin-dev] Making AsicBoost irrelevant

From: James Hilliard <james.hilliard1@gmail•com>
To: Matt Corallo <lf-lists@mattcorallo•com>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Making AsicBoost irrelevant
Date: Wed, 11 May 2016 18:00:59 -0400	[thread overview]
Message-ID: <CADvTj4pmH2+TE4hdfr3Yo9CMxuDBjzAXj2j-gmpGkmrOMH6Pjg@mail.gmail.com> (raw)
In-Reply-To: <57339B02.3060806@mattcorallo.com>

I was told that the patent appears to be owned exclusively by Bitmain
in China https://www.google.com/patents/CN105245327A?cl=en

On Wed, May 11, 2016 at 4:50 PM, Matt Corallo via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> That's the reason for this post! All current major ASIC manufacturers
> have made warrants that they are not using AsicBoost (with the exception
> of the 21 Inc Bitcoin computer).
>
> The fact that the optimization was patented is what has required that we
> work to hardfork it out, not that people might have such private
> optimizations. The fact that AsicBoost was independently discovered by
> at least two (if not three) organizations seems to lend credence to the
> idea that private optimizations will only provide a temporary win over
> competitors.
>
> Matt
>
> On 05/11/16 03:14, Timo Hanke via bitcoin-dev 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.
>>
>> 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
>> <mailto: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 <http://petertodd.org>
>>
>>     _______________________________________________
>>     bitcoin-dev mailing list
>>     bitcoin-dev@lists•linuxfoundation.org
>>     <mailto:bitcoin-dev@lists•linuxfoundation.org>
>>     https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev