<div dir="ltr">I have uploaded a proposal for a Bitcoin Cash difficulty adjustment<br>algorithm, with tests, as an alternative to deadalnix&#39;s proposal.  The<br>tests are based on deadlnix&#39;s tests for his proposal, which saved me a<br>lot of time.<br><br>  <a href="https://reviews.bitcoinabc.org/D578">https://reviews.bitcoinabc.org/D578</a><br><br>Like the current EDA, it uses the difference between the MTP of the<br>previous block and the MTP of the one 6 blocks before that.  This is<br>believed resistant to gaming via timestamp manipulation.  If blocks<br>arrived at the 10 minute average this difference would be 60 minutes.<br>Timestamps are stochastic so in reality the time difference varies<br>randomly over quite a wide range even with constant hashrate and<br>genuine timestamps.<br><br>The algorithm targets a window of [30 mins, 128 mins] for this<br>difference block by block; if it falls below 30 mins the difficulty of<br>the next block is bumped up a small fraction (about 0.4%), and if<br>above 128 mins the difficulty is bumped down a small but larger<br>fraction (about 1.6%).  This window was chosen so mean block time is<br>close to 600s in simulations (see below).  The 2016 block retargeting<br>window is eliminated entirely.<br><br>It is my belief that small but persistent block-to-block changes in<br>difficulty do a good job of eliminating wild oscillations, giving time<br>for miners to react to changing circumstances and difficulty.<br><br>Simulations of moving exchange rates, with miners of different<br>persuasions coming and going according to parametric rules, and with<br>inter-block times drawn from an exponential distribution according to<br>the instantaneous hash rate, show this reliably achieves a 600s mean<br>block time over several thousand blocks with low standard deviation.<br><br>I have written a Python simulator here (which defaults to the<br>algorithm parameters in the C++ code):<br><br>   <a href="https://github.com/kyuupichan/difficulty">https://github.com/kyuupichan/difficulty</a><br><br>which is easily modified to various hashrate scenarios and miner<br>persuasions.  It runs 10,000 blocks, printing various stats like<br>instantaneous hashrate, difficulty, block times, etc., at each block.<br>Once the simulation is run it also shows stats for median block time,<br>mean block time, and maximum block time over the simulation.<br><br>Typically over 10,000 blocks, mean block time is within 1% of 600s,<br>median block time a little under 400s, and max block time between 1hr<br>40 minutes and 3 hours.  This compares favourably with the current<br>EDA.<br><br>I believe that once Bitcoin Cash has more stable difficulty (by any<br>algorithm) that adjusts to changes in hash power smoothly, that large<br>fluctuations in hash power will not be attractive to miners or pools,<br>and that they will adjust hash power allocation more smoothly and<br>rationally themselves.  In such circumstances the maximum inter-block<br>time spacing of this algorithm would reduce to around 90 minutes,<br>similar to what randomness gives the current bitcoin network.<br><br>Things I believe this algorithm has in its favour:<br><br>- the code and idea are simple to understand and analyse<br>- reuses existing concepts such as 6-block MTP difference<br>- easy to implement in e.g. Electron Cash because it on information<br>  local to the current header that is embedded in the headers<br>  themselves.  It does not use chainwork, for example.<br><br>Things I could think of that might be against:<br><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.<br><br>- It might be susceptible to difficulty ramping attacks.  I have tried<br>  to mitigate that by having difficulty fall faster than it rises.  An<br>  attacker would need to sustain an attack over a long period of time,<br>  during which miners sensitive to profitability would leave, so the<br>  attacker shoulders most of the cost of the ramp.  It would cost a<br>  lot less to bring the difficulty back down in line with true hashrate.<br><br>Neil.<br><br></div>