[Bitcoin-ml] Alternative difficulty algorithm for Bitcoin Cash

Neil kyuupichan at gmail.com
Thu Oct 5 04:31:48 UTC 2017

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.

I have eliminated this weakness in the algorithm with the latest push to


by slightly bumping difficulty if the 2016-block time difference is
approximately 2.5 standard deviations too fast.

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.

For those trying to understand how the algorithm evolves difficulty, it is
fairly easy to intuit why it doesn'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.

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's sandcastle and recent deep
footprints.  Each wave (block) doesn'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.


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

More information about the bitcoin-ml mailing list