<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jul 11, 2015 at 4:04 PM, Dave Hudson <span dir="ltr">&lt;<a href="mailto:dave@hashingit.com" target="_blank">dave@hashingit.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"><div style="word-wrap:break-word"><div><div>This would probably be worse. The 1 MB would include the highest fee transactions, leaving the lowest fees in the remaining 0.5 MB.</div></div></div></blockquote><div><br></div><div>Right, in the example, I was assuming all transactions had the same fee per byte.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div>If hashing isn&#39;t constantly applied all the time then the inter-block times will expand and the difficulty will reduce. This means that a pool that decides to use all of its available hashing 100% of the time now has a distinct advantage over those who are playing nicely. This is the same problem that the &quot;proof of idle&quot; idea had; it only works if no-one chooses to try to exploit it (which seems very unlikely).</div></div></blockquote><div><br></div><div>Uh, I don&#39;t think so.  Pools would offer a price per hash based on how much tx fees that they can get at that moment. <br><br></div><div>Offering more than that would mean they make a loss on average.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div>Say, for the sake of argument that over a nominal 10 minute period we see 10 BTC worth of transaction fees. If the mempool is empty of interesting fees at the start of a block then we might like to imagine that rational miners will power down their hashing to save energy costs until the fees are worthwhile. Let&#39;s assume, for the sake of argument, that this nominally takes 5 minutes.</div></div></blockquote><div><br></div><div>I think the hardware would be able to power down nearly instantly.  Granted, if they have generators or similar, they may not be able to do it so fast.<br><br></div><div>Switching to an altcoin is pretty much instant though.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div>After 5 minutes we go from 0% to 100% as all hashing engines switch on. The difficulty will have corrected to mean that 100% of the work will nominally happen in the next 5 minutes, but that means that a malicious miner has a 2x amplification of their nominal hashing rate to do mischief in the preceding 5 minutes.</div></div></blockquote><div><br></div><div>I think you need to split it into hashers and pools, rather than miners.  Hashers have to pay electricity costs to keep their equipment running.  Powering down for 5 minutes is cheaper than using that hashing for other things.<br><br></div><div>The ratio of capital costs and electricity determines which wins out.<br><br></div><div>In the example given, it would work out as something like this.<br><br></div><div>0 mins: pool offers 0<br></div><div>2 mins: pool offers 20% of average<br></div><div>4 mins: pool offers 40% of average<div>6 mins: pool offers 60% of average<div>8 mins: pool offers 80% of average<div>10 mins: pool offers 100% of average</div><div>12 mins: pool offers 120% of average<br>14 mins: pool offers 140% of average<br></div></div></div></div>...<br> <br></div><div class="gmail_quote">This means that more and more miners will accept the offer as time passes.  If a miner was using solar power for their miners, then they might as well run it for the full 10 mins, since it is pointless to leave the equipment off.  With batteries they could shift some of their output to the more profitable period. <br></div><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div>Such a malicious miner would choose to spend their 5 minutes re-mining the previous block, but dropping some amount of the transactions from it. Let&#39;s say that they try to re-mine only 9.5 BTC out the previous 10 BTC. If they succeed then they&#39;re offering everyone else an extra 0.5 BTC (5%) if they mine on top of their re-mined block and as an incentive to orphan the original block. Rational miners would definitely choose to build on the re-mined block because they get more reward from doing so.</div></div></blockquote><div><br></div><div>If they find that block, it will be a tie with the other block, but created much later.  That means that nobody will build on the block they found.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div>Of course the extra hashing that our malicious miner is doing will actually push the difficulty back up somewhat, but they&#39;re still running at an advantage over the long-term. I&#39;ve also ignored some of the other security implications of the hashing amplification effects (e.g. 25% of the hash rate can end up controlling 50% of the blocks in the scenario above).</div><div><br></div></div></blockquote><div>I think mining strategy once minting fees are greatly reduced is an interesting question.  We can&#39;t assume that miners are all going to build on the tip.<br><br></div><div>In your example, you can bribe the miner of the next block by paying to OP_TRUE.<br><br></div><div>A &lt;- B &lt;-C<br><br></div><div>Assume that C pays 1BTC in fees and the miner creates a new version of C that pays 1.1BTC in fees.<br><br></div><div>C&#39; pays 1.1 BTC in fees and also pays 0.05BTC to OP_TRUE.<br><br></div><div>This means that miners who build on C&#39; instead of C get a 0.05BTC &#39;bribe&#39; to ignore the fact that C&#39; was found much later.<br><br></div><div>It isn&#39;t clear if other miners would be better off building D anyway, since they could take 100% of the fees.<br><br></div><div>If the average fees per block was 1BTC and someone send a block that pays 10BTC in fees, it could stall the block chain.  You can do the same bribery trick.<br><br></div><div>If C has the 10BTC transaction, you can create a C&#39; block and pay 1BTC to OP_TRUE.  The miner who builds on C&#39; include a transaction which pays that money to him. <br><br></div><div>Another miner can produce C&#39;&#39; that pays 2BTC to OP_TRUE.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div></div><div>The only way I can see that this wouldn&#39;t be the case would be if there were always useful fees available to mine immediately after a block is found. If block space is kept moderately scarce then immediately a block is found then everyone will keep mining and the incentives to try to deliberately orphan the last block are dramatically reduced.</div></div></blockquote></div><br></div><div class="gmail_extra">True, if there is multiple blocks worth of transactions in the memory pool, then losing one block&#39;s worth of transactions won&#39;t drop the total fees down to zero.<br></div></div>