<div dir="ltr">There&#39;s quite a bit of confusion in this thread.<div><br></div><div>Peter is referring to block withholding attacks. Ittay Eyal (as sole </div><div>author -- I was not involved in this paper [1]) was the first </div><div>to analyze these attacks and to discover a fascinating, paradoxical </div><div>result. An attacker pool (A) can take a certain portion of its hashpower,</div><div>use it to mine on behalf of victim pool (B), furnish partial proofs of work</div><div>to B, but discard any full blocks it discovers. If A picks the amount of</div><div>attacking hashpower judiciously, it can make more money using this</div><div>attack, than it would if it were to use 100% of its hashpower for its own</div><div>mining. This last sentence should sound non-sensical to most of you, </div><div>at least, it did to me. Ittay did the math, and his paper can tell you </div><div>exactly how much of your hashpower you need to peel off and use</div><div>to attack another open pool, and you will come out ahead. </div><div><br></div><div>Chris Priest is confusing these attacks with selfish mining, and further,</div><div>his characterization of selfish mining is incorrect. Selfish Mining is </div><div>guaranteed to yield profits for any pool over 33% (as a result, Nick</div><div>Szabo has dubbed this the &quot;34% attack&quot;) and it may pay off even</div><div>below that point if the attacker is well-positioned in the network; </div><div>or it may not, depending on the makeup of the rest of the pools </div><div>as well as the network characteristics (the more centralized</div><div>and bigger the other pools are, the less likely it is to pay off). There</div><div>was a lot of noise in the community when the SM paper came out, </div><div>so there are tons of incorrect response narrative out there. By now,</div><div>everyone who seems to be Bitcoin competent sees SM as a </div><div>concern, and Ethereum has already adopted our fix. I&#39;d have hoped</div><div>that a poster to this list would be better informed than to repeat the</div><div>claim that &quot;majority will protect Bitcoin&quot; to refute a paper whose title</div><div>is &quot;majority is not enough.&quot;</div><div><br></div><div>Back to Ittay&#39;s paradoxical discovery:</div><div><br></div><div>We have seen pool-block withholding attacks before; I believe Eligius</div><div>caught one case. I don&#39;t believe that any miners will deploy strong KYC</div><div>measures, and even if they did, I don&#39;t believe that these measures</div><div>will be effective, at least, as long as the attacker is somewhat savvy.</div><div>The problem with these attacks are that statistics favor the attackers.</div><div>Is someone really discarding the blocks they find, or are they just </div><div>unlucky? This is really hard to tell for small miners. Even with KYC, </div><div>one could break up one&#39;s servers, register them under different </div><div>people&#39;s names, and tunnel them through VPNs.</div><div><br></div><div>Keep in mind that when an open pool gets big, like GHash did and <br></div><div>two other pools did before them, the only thing at our disposal used</div><div>to be to yell at people about centralization until they left the big</div><div>pools and reformed into smaller groups. Not only was such yelling</div><div>kind of desperate looking, it wasn&#39;t incredibly effective, either. </div><div>We had no protocol mechanisms that put pressure on big pools to </div><div>stop signing up people. Ittay&#39;s discovery changed that: pools that </div><div>get to be very big by indiscriminately signing up miners are likely to</div><div>be infiltrated and their profitability will drop. And Peter&#39;s post is </div><div>evidence that this is, indeed, happening as predicted. This is a</div><div>good outcome, it puts pressure on the big pools to not grow. </div><div><br></div><div>Peter, you allude to a specific suggestion from Luke-Jr. Can you </div><div>please describe what it is? </div><div><br></div><div>Hope this is useful,</div><div>- egs</div><div><br></div><div>[1] <a href="https://www.cs.cornell.edu/~ie53/publications/btcPoolsSP15.pdf">https://www.cs.cornell.edu/~ie53/publications/btcPoolsSP15.pdf</a></div><div><br></div></div>