<div dir="ltr">Things I could think of that might be against:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br>- Timestamp differences over a long period (as with the 2016-block<br>  retargeting of bitcoin legacy) are not used.  So if miners<br>  manipulate timestamps to be always within the window, blocks could<br>  be e.g. 5 minutes apart forever so we get twice as many blocks as we<br>  should over a long period of time.  As this requires miner collusion<br>  equivalent to a 50% attack, and block timestamps have shown<br>  themselves to be non-gamed in the current MTP setup, I don&#39;t<br>  currently consider this a serious problem.</div></blockquote><div> </div><div>I have eliminated this weakness in the algorithm with the latest push to</div><div><br></div><div>  <a href="https://reviews.bitcoinabc.org/D578">https://reviews.bitcoinabc.org/D578</a></div><div><br></div><div>by slightly bumping difficulty if the 2016-block time difference is approximately 2.5 standard deviations too fast.<br></div><div><br></div><div><div>This change prevents any possibility of an increase in the 
coin production schedule by miners colluding to artificially constrain 
timestamps to be just within the window.  This removes my final major concern about this approach and I 
believe it deserves serious consideration as a replacement difficulty 
adjustment algorithm.  I have provided a fairly realistic simulator 
in Python which is easily tweakable, and implementing the algorithm in SPV wallets
 like Electron Cash is straightforward.</div><div><br></div></div><div>For those trying to understand how the algorithm evolves difficulty, it is fairly easy to intuit why it doesn&#39;t oscillate.  Oscillations are caused by attempts to estimate how far difficulty is from current hashrate and adjusting difficulty to bring them in line.  The problem is that estimating current hashrate is difficult and noisy.<br></div><div><br></div><div>Here the idea is instead not to worry too much about estimating how far different they are, but instead to bump difficulty a small amount in the appropriate direction if timestamps indicate they are not in balance.  This happens consecutively for each block if necessary.  The result is to erode any difference over several blocks without a tendency to overshoot.  Think of waves on a beach eliminating a child&#39;s sandcastle and recent deep footprints.  Each wave (block) doesn&#39;t take out the difference in relief in one go; it simply erodes the difference bit by bit.  Several waves later the beach is back to flat - difficulty and hashrate are aligned.  MTP and the 2016-block timestamp difference are used to ensure timestamps cannot be manipulated to game the algorithm.<br></div><div><br></div>Thanks,<div><br></div><div>Neil.<br></div></div></div>