<div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote">On Sun, Dec 20, 2015 at 12:42 PM, Natanael <span dir="ltr">&lt;<a href="mailto:natanael.l@gmail.com" target="_blank">natanael.l@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class=""></span>If total difficulty is X and the ratio for full blocks to candidate blocks shared with the pool is Y, then the candidate block PoW now has to meet X/Y while hashing the candidate block PoW + the pool&#39;s commitment hash must meet Y, which together makes for X/Y*Y and thus the same total difficulty.
</blockquote><div><br></div>This gives the same total difficulty but miners are throwing away otherwise valid blocks.<br><br></div><div class="gmail_quote">This means that it is technically a soft fork.  All new blocks are valid according to the old rule.<br></div><div class="gmail_quote"><br></div>In practice, it is kind of a hard fork.  If Y is 10, then all upgraded miners are throwing away 90% of the blocks that are valid under the old rules.<br><br></div>From the perspective of non-upgraded clients, the upgraded miners operate at a 10X disadvantage.<br><br></div><div>This means that someone with 15% of the network power has a majority of the effective hashing power, since 15% is greater than 8.5% (85% * 0.1).<br><br></div><div>The slow roll-out helps mitigate this though.  It gives non-upgraded clients time to react.  If there is only a 5% difference initially, then the attacker doesn&#39;t get much benefit.<br><br></div><div><div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The main differences are that there&#39;s a public key identifier the miners are told about in advance and expect to see in block templates, and that that now the pool has to publish this commitment value together with the block that also contains the commitment hash, and that this is verified together with the PoW. 
</blockquote></div><br></div><div class="gmail_extra">I don&#39;t think public keys are strictly required.  Registering them with DNSSEC is way over the top.  They can just publish the key on their website and then use that for their identity.  <br></div></div></div></div>