[Bitcoin-ml] Alternative difficulty algorithm for Bitcoin Cash

Neil kyuupichan at gmail.com
Thu Oct 12 07:49:36 UTC 2017


One concern people have expressed with my algo is it may be too slow
to adjust to shocks.  To allow people to more easily study this I've
updated the simulator at

   https://github.com/kyuupichan/difficulty

and incorporated 2 improvements:

1 - algorithms are now named and can be parameterised.  You specify
    the algo on the command line.  My original algo is the default and
    named "k-1".  I've added 2 others, "k-2" and "k-3" as examples of
    more sensitive recalibration of difficulty (tighter windows and
    shorter MTP differences of 4 and 2 blocks rather than 6).
    Deadalnix's algo is named "d-1".  It will be easy to add TomZ's
    algo if it is specified.

2 - the simluation now randomly introduces FX shocks of plus or minus
    10 or 15 percent at a few blocks in the simulation.  This allows
    us to see how well the algos react to shocks.

Specify an algo on the command line with the -a switch:

  ./mining.py -a k-3

for example.

I've not drawn any conclusions yet.  k-2 and k-3 seem to show more
unpredictability / variance in mean block times, and perhaps worse max
block time.  They are also more tricky to calibrate to achieve sensible mean
block times of around 600s and median of around 400s (theoretical
median at constant hashrate is 415s, medians seem to decrease with
algorithmic variance).

Enjoy!

Neil.

On Sun, 1 Oct 2017 at 18:17 Neil <kyuupichan at gmail.com> wrote:

> 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.
>
>   https://reviews.bitcoinabc.org/D578
>
> 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):
>
>    https://github.com/kyuupichan/difficulty
>
> 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
> EDA.
>
> 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.
>
>
> Neil.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-ml/attachments/20171012/65589031/attachment-0001.html>


More information about the bitcoin-ml mailing list