<div dir="ltr"><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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. </div><div><br></div><div>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.</div><div><div><br></div><div>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.</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 point. </div><div><br></div><div>Timo</div><div><br></div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 10, 2016 at 11:57 AM, Peter Todd via bitcoin-dev <span dir="ltr"><<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="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 part of the hard-fork proposed in the HK agreement(1) we'd like to make the<br>
patented AsicBoost optimisation useless, and hopefully make further similar<br>
optimizations useless as well.<br>
<br>
What's the best way to do this? Ideally this would be SPV compatible, but if it<br>
requires changes from SPV clients that's ok too. Also the fix this should be<br>
compatible with existing mining hardware.<br>
<br>
<br>
1) <a href="https://medium.com/@bitcoinroundtable/bitcoin-roundtable-consensus-266d475a61ff" rel="noreferrer" target="_blank">https://medium.com/@bitcoinroundtable/bitcoin-roundtable-consensus-266d475a61ff</a><br>
<br>
2) <a href="http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-April/012596.html" rel="noreferrer" target="_blank">http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-April/012596.html</a><br>
<span class=""><font color="#888888"><br>
--<br>
<a href="https://petertodd.org" rel="noreferrer" target="_blank">https://petertodd.org</a> 'peter'[:-1]@<a href="http://petertodd.org" rel="noreferrer" target="_blank">petertodd.org</a><br>
</font></span><br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
<br></blockquote></div><br></div></div>