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 OK
No Unit Test Coverage
Build Status
Buildable 950
Build 950: arc lint + arc unit
kyuupichan created this revision.Oct 1 2017, 09:16
Herald added 1 blocking reviewer(s): Restricted Project. · View Herald TranscriptOct 1 2017, 09:16
schancel added a subscriber: schancel.Oct 3 2017, 03:41

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?

deadalnix edited edge metadata.Oct 4 2017, 10:04

What's the DARI ?

71 ↗(On Diff #1466)

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

kyuupichan added a comment.EditedOct 5 2017, 01:41

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.

kyuupichan updated this revision to Diff 1491.Oct 5 2017, 04:08

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.

kyuupichan updated this revision to Diff 1492.Oct 5 2017, 07:56

Fix typos.

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
schancel added a comment.Oct 5 2017, 22:45

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 updated this revision to Diff 1500.Oct 6 2017, 00:19
kyuupichan edited edge metadata.

Squashed / rebased.

jasonbcox added inline comments.Oct 10 2017, 00:53

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 commandeered this revision.Nov 10 2017, 08:56
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.

schancel abandoned this revision.Nov 10 2017, 08:56