<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, May 9, 2015 at 4:08 AM, Peter Todd <span dir="ltr"><<a href="mailto:pete@petertodd.org" target="_blank">pete@petertodd.org</a>></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="">
> I wonder if having a "miner" flag would be good for the network.<br>
<br>
</span>Makes it trivial to find miners and DoS attack them - a huge risk to the<br>
network as a whole, as well as the miners.<br></blockquote><div><br><div>To mitigate against this, two chaintips could be tracked. The miner tip and the client tip.<br><br></div>Miners would build on the miner tip. When performing client services, like wallets, they would use the client tip.<br><br><div>The client would act exactly the same as any node, the only change would be that it gives miner work based on the mining tip.<br></div><br></div><div>If the two tips end up significantly forking, there would be a warning to the miner and perhaps eventually refuse to give out new work.<br><br></div><div>That would happen when there was a miner level hard-fork.<br></div><div> <br></div><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>That'd be an excellent way to double-spend merchants, significantly<br>
increasing the chance that the double-spend would succeed as you only<br>
have to get sufficient hashing power to get the lucky blocks; you don't<br>
need enough hashing power to *also* ensure those blocks don't become the<br>
longest chain, removing the need to sybil attack your target.<br></blockquote><div><br></div><div>To launch that attack, you need to produce fake blocks. That is expensive. <br><br>Stephen Cale's suggestion to wait more than one block before counting a transaction as confirmed would also help mitigate.<br></div></div></div></div>