[Bitcoin-ml] Alternative difficulty algorithm for Bitcoin Cash

Neil kyuupichan at gmail.com
Thu Oct 12 02:23:07 UTC 2017


This discussion seems to have dried up; I think it is fairly urgent
we resolve this soon.

The current network situation is far from ideal.  Either we have fast
blocks that are accelerating the emission schedule and penalizing
current holders and future miners, or we have the situation as I write
where miners of BCC are being penalized about 30% to mine it.  That
blocks are slow is a sign they are not happy to being paying that
unnecessary premium.

The following are all stochastic and unknown when miners decide to
commit hashrate to mining one or more blocks on either chain: the
hashrate actually mining each chain, the time to the next block, the
expected fees, and the exchange rate when your block is mined - more
so if you consider waiting 100 blocks for the reward to mature.  Hence
there is a natural and unavoidable uncertainty of the relative payout
of the chains, and I suggest that it is at least 5% and probably
closer to 10% for any given block.

Hence I do not believe miners will ever be in the habit of switching
chains on a block-to-block basis; instead their decisions will be a
function of relative revenue expectations and other preferences drawn
over a longer time frame of at least 6 blocks, and probably longer than
that.  There is some evidence this is true in the miner behaviour we
have already observed since the split.

Based on my simulator with plausible but simplified assumptions about
3 different miner behaviours driven by relative chain revenue, my
suggested difficulty adjustment seems to be more stable and perform
better than deadalnix's - the only other concrete suggestion on the
table.  I think this is because hashrate and difficulty are inversely
related, and the relationship is not continuous.  There will be places
where if relative revenue has drifted too far, hashrate will come or
go in lumps.

I don't think TomZ has suggested anything concrete; if he does I'd be
happy to try and code it up in my simulator.

What can go wrong with my algorithm?  Not much, I believe.  Here
it is qualitatively:

- I believe it is generally accepted that the 6-block MTP difference
  is not timestamp gameable.
- it cannot give rise to anything more than a 5% speed up in the
  emission schedule because of the persistent 2016-block lookback,
  which gives a very small difficulty bump if it is 5% too fast.  If
  also cannot give rise to a significant slowdown as miners cannot
  push timestamps more than 2 hours ahead of wall time, and difficulty
  drops would kick in.
- it cannot oscillate wildly because block-to-block difficulty changes
  are small.  So the possibility of sudden chain death from sudden
  reluctance to mine is negligible In practice I believe this will
  mean hashrate is generally stable because difficulty in the
  near-term is predictable and the current difficulty has presumably
  already adjusted to ambient miner chain preferences.
- if significant hash comes in when it was previously in balance,
  perhaps because the legacy chain had a difficulty retarget, blocks
  will be fast for a while but the persistent per-block small
  difficulty increases will whittle it away fairly quickly,
  particularly in time terms (and this might be compounded by the 2016
  block lookback).  Such ongoing difficulty increases will erode the
  preference for the BCC chain that was presumably in balance before,
  causing some of the prior hashrate to leave.
- if significant hash disappears, difficulty will come down 4x as
  quickly as it goes up, so in time terms the adjustment will be similar
  and not too drawn-out.  Like difficulty increases, falls are still gradual
  and in small increments, encouraging hashrate to adjust its preferences
  gradually too.

So I think the downsides of this approach are quite limited, and the better
network experience for users and miners will increase the value of the
BCC chain for all.

Please let's make a decision soon.

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/927013d6/attachment.html>


More information about the bitcoin-ml mailing list