[Bitcoin-ml] Alternative difficulty algorithm for Bitcoin Cash

Neil kyuupichan at gmail.com
Sun Oct 1 09:17:09 UTC 2017

I have uploaded a proposal for a Bitcoin Cash difficulty adjustment
algorithm, with tests, as an alternative to deadalnix's proposal.  The
tests are based on deadlnix's tests for his proposal, which saved me a
lot of time.


Like the current EDA, it uses the difference between the MTP of the
previous block and the MTP of the one 6 blocks before that.  This is
believed resistant to gaming via timestamp manipulation.  If blocks
arrived at the 10 minute average this difference would be 60 minutes.
Timestamps are stochastic so in reality the time difference varies
randomly over quite a wide range even with constant hashrate and
genuine timestamps.

The algorithm targets a window of [30 mins, 128 mins] for this
difference block by block; if it falls below 30 mins the difficulty of
the next block is bumped up a small fraction (about 0.4%), and if
above 128 mins the difficulty is bumped down a small but larger
fraction (about 1.6%).  This window was chosen so mean block time is
close to 600s in simulations (see below).  The 2016 block retargeting
window is eliminated entirely.

It is my belief that small but persistent block-to-block changes in
difficulty do a good job of eliminating wild oscillations, giving time
for miners to react to changing circumstances and difficulty.

Simulations of moving exchange rates, with miners of different
persuasions coming and going according to parametric rules, and with
inter-block times drawn from an exponential distribution according to
the instantaneous hash rate, show this reliably achieves a 600s mean
block time over several thousand blocks with low standard deviation.

I have written a Python simulator here (which defaults to the
algorithm parameters in the C++ code):


which is easily modified to various hashrate scenarios and miner
persuasions.  It runs 10,000 blocks, printing various stats like
instantaneous hashrate, difficulty, block times, etc., at each block.
Once the simulation is run it also shows stats for median block time,
mean block time, and maximum block time over the simulation.

Typically over 10,000 blocks, mean block time is within 1% of 600s,
median block time a little under 400s, and max block time between 1hr
40 minutes and 3 hours.  This compares favourably with the current

I believe that once Bitcoin Cash has more stable difficulty (by any
algorithm) that adjusts to changes in hash power smoothly, that large
fluctuations in hash power will not be attractive to miners or pools,
and that they will adjust hash power allocation more smoothly and
rationally themselves.  In such circumstances the maximum inter-block
time spacing of this algorithm would reduce to around 90 minutes,
similar to what randomness gives the current bitcoin network.

Things I believe this algorithm has in its favour:

- the code and idea are simple to understand and analyse
- reuses existing concepts such as 6-block MTP difference
- easy to implement in e.g. Electron Cash because it on information
  local to the current header that is embedded in the headers
  themselves.  It does not use chainwork, for example.

Things I could think of that might be against:

- Timestamp differences over a long period (as with the 2016-block
  retargeting of bitcoin legacy) are not used.  So if miners
  manipulate timestamps to be always within the window, blocks could
  be e.g. 5 minutes apart forever so we get twice as many blocks as we
  should over a long period of time.  As this requires miner collusion
  equivalent to a 50% attack, and block timestamps have shown
  themselves to be non-gamed in the current MTP setup, I don't
  currently consider this a serious problem.

- It might be susceptible to difficulty ramping attacks.  I have tried
  to mitigate that by having difficulty fall faster than it rises.  An
  attacker would need to sustain an attack over a long period of time,
  during which miners sensitive to profitability would leave, so the
  attacker shoulders most of the cost of the ramp.  It would cost a
  lot less to bring the difficulty back down in line with true hashrate.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-ml/attachments/20171001/14cb9c2d/attachment.html>

More information about the bitcoin-ml mailing list