Proposed new algo for BCC difficulty adjustments
AbandonedPublic
Actions

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

Details

Reviewers

deadalnix
kyuupichan

Group Reviewers

Restricted Project

Summary

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

Repository

rABC Bitcoin ABC

Branch

mtpd_window

Lint

Lint Passed

Unit

No Test Coverage

Build Status

Buildable 945
Build 945: arc lint + arc unit

Event Timeline

kyuupichan created this revision.Oct 1 2017, 09:16

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?

src/pow.cpp
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 ?

src/pow.cpp
71 ↗	(On Diff #1466)	nPowTargetSpacing is 10 minutes, so it's consistent with the comment.

In D578#10469, @schancel wrote:

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.

https://lists.linuxfoundation.org/pipermail/bitcoin-ml/2017-October/000305.html

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.

src/pow.cpp
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.

Fix typos.

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.

Squashed / rebased.

Harbormaster completed remote builds in B950: Diff 1500.Oct 6 2017, 00:19

jasonbcox added a subscriber: jasonbcox.Oct 9 2017, 17:14

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

src/pow.cpp
70–71 ↗	(On Diff #1500)	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.
75 ↗	(On Diff #1500)	There's no indication how 95/100 was selected here (is it related to the std deviation?).

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

Revision Contents
Changeset List

Path

Size

src/

pow.cpp

6 lines

Diff 1492

View Options

Proposed new algo for BCC difficulty adjustmentsAbandonedPublicActions