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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
