Page MenuHomePhabricator

Proposed new algo for BCC difficulty adjustments

Authored by schancel on Oct 1 2017, 09:16.


Group Reviewers
Restricted Project

Target a window for the difference of MTP over 6 blocks - the same
quantity used in the current EDA.

The window is chosen so that with stochastic randomness of block
times the block interval will average approximately 600s.

The bump sizes are chosen to:-

a) make a difficulty ramp attack from temporary excess hash power

a lot more expensive to attempt than to recover from

b) minimise the maximum time between 2 blocks over long-run simulations

of hash rate coming and going, including in large chunks, and randomised
exchange rate moves

Includes tests.

Test Plan

Tests added; make check.

Diff Detail

rABC Bitcoin ABC
Lint Passed
No Test Coverage
Build Status
Buildable 950
Build 950: arc lint + arc unit

Event Timeline

Herald added 1 blocking reviewer(s): Restricted Project. · View Herald TranscriptOct 1 2017, 09:16

When considering the DARI, it seems like this algorithm encourages oscillations in hashpower. Can you link to your simulations?

71 ↗(On Diff #1466)

Where is the 10 coming from? Comment doesn't seem to match if chain params differ from expectation?

What's the DARI ?

71 ↗(On Diff #1466)

nPowTargetSpacing is 10 minutes, so it's consistent with the comment.

When considering the DARI, it seems like this algorithm encourages oscillations in hashpower. Can you link to your simulations?

I linked in the mailing list post.

The reason it doesn't oscillate is fairly simple to see: it doesn't try and adjust to some measurement of how different hash rate and difficulty are - doing that is what causes oscillations. It just makes a small change for each block the mismatch persists, gradually eroding it.

71 ↗(On Diff #1466)

nPowTargetSpacing is 600. So it rescales to be in minutes. I wanted to keep the 30 (like the 128) rather than simplify to 3, which is less clear.

Raise difficulty if blocks are too fast over a 2016 block period

Although unlikely, this completely removes any incentive for miners
to collude to game timestamps in order to slightly increase the coin
emission schedule. Includes test.

Rebased to current git HEAD.

deadalnix requested changes to this revision.Oct 5 2017, 12:47

Please update the actual diff.

This revision now requires changes to proceed.Oct 5 2017, 12:47

DARI is the Difficulty Adjusted Reward Index. (i.e value of reward/cost of mining). If the difficulty takes too long to adjust, there's an good incentive to switch to mining BCC until the BCC DARI <= BTC DARI, and then go back. Due to the nature of this, it makes sense for all miners to do basically the same thing at the same time.

kyuupichan edited edge metadata.

Squashed / rebased.


I recommend calling p2016 something like pindex2016 instead (like line 82). Other than the indication that this is a pointer, it's a bit odd to name a variable just a number, imo.


There's no indication how 95/100 was selected here (is it related to the std deviation?).

schancel added a reviewer: kyuupichan.

Commandeering revision so I can close this. I'm happy to have it reopened if we want to discuss this for a HF down the road.