Conversation
fb0ec8d to
84da777
Compare
The valid blocktime interval is changed to [previous blocktime + 1s, now]. This is changed from [previous MTP + 1s, now + 7200s]. For regtest, push generated blocktimes to 600s rather than 1s, and tolerate future blocktimes up to a large value.
To achieve faster response to hashrate changes and improve stability of inter-block times, a new and radically different difficulty adjustment algorithm is introduced. The proof-of-work target expressed by CheckProofOfWork is modified to depend on the timestamp offset t of the block itself. This subtarget g starts at a very low (difficult) value. It increases as the timestamp increases, and is given by: g = G(-1) * R * t^5 where: g = Subtarget G(-1) = Previous block's nominal target R = 1 / 11036254599009 t = Timestamp - Timestamp(-1), capped at 2 days for recalculation The calculation of the next nominal target G is also changed. G is given by: G = G(-1) * t^6/6 * R / 531 Unlike traditional difficulty adjustment algorithms, this algorithm does not depend on any historical blocktime offsets. It depends only on the target immediately prior, and the blocktime offset of the block itself. This algorithm is designed to maintain a mean inter-block time of 600 seconds, even as hashrate and difficulty may vary dramatically. G(0) and minumum difficulty are unchanged (0x1d00ffff for mainnet and testnet). To retain the property that sibling blocks with differing timestamps are equally preferred on the basis of chainwork, the block work comparator is modified to use chainwork(-1) as the primary sort. This is intuitive, because timestamps now affect the nominal target one block sooner than before.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Implement this new retargeting (difficulty adjustment) algorithm.
Real-time targeting (RTT) is designed to deal with severe hashrate fluctuations, such as those sure to occur with any new SHA256 coin. RTT aims to maximize responsiveness to hashrate changes by using only the freshest inputs, and by retargeting in a way that damps variation of inter-block times, while responding nonlinearly to them.
Input 1: The timestamp offset of the block being mined
Like a few other coins, RTT adjusts the difficulty target based on the timestamp offset of the block being mined (which changes each second until the block is solved), hence "real-time".
Input 2: The previous block's target
There is no averaging of timestamps and no reference to observed inter-block times other than that of the block being mined. The next block's target is constructed de novo by each block, using only its own timestamp and the timestamp and target of the previous block.
RTT can be viewed as analogous to a Dutch auction. Mining a block with time offset of one second is 11 trillion times more difficult than the nominal target set in place by the previous block. The block then rapidly becomes easier to mine as the offset approaches and extends beyond the target spacing (10 minutes), resulting in a "live sample" of the network hashrate.
Although the target (difficulty) will swing strongly, RTT exhibits highly stable inter-block times, enabling the consensus rules around allowable offsets to be tightened to eliminate negative and future offsets (these are also necessary conditions for RTT), which in turn eliminates various attacks, and mitigates others.
To retain the property that sibling blocks with different timestamps are equally preferred on the basis of chainwork, the block work comparator is modified to use the previous block's chainwork as the primary sort. This is intuitive, because timestamps now affect the target one block sooner than before.