This proposal incorporates recent research done in the Bitcoin Cash (BCH) community on Difficulty Adjustment Algorithms (DAA). While the code added is nontrivial, it has been vetted by running on BCH for over 3 years. The “absolutely scheduled exponentially rising targets” (ASERT) algorithm uses 2**x where the exponent is a difference between the change in time and the number of blocks since an “anchor” block. This equation has a very useful property, f(a+b)=f(a)f(b), along with a mean-reverting reference to the anchor, which allows for a simplified implementation of e.g. changes in pow difficulty on pos blocks (rfc0020). By tuning the halflife “tau”, we attempt to balance the volatility of real hashpower with the fundamental statistical stability of the system with respect to the pos block target. The primary specification is with regards to the following:
Primary Spec: Avoid strings of PoW blocks with no PoS block in-between.
First takeaway message regarding the half-life Tau:
“If we can tolerate 3 PoW blocks in a row during dramatic price changes, then Tau = 12 hours is a good choice. If we can allow 4 or 5 PoW blocks in a row during extreme events, then Tau = 24 hours would be a more overall stable choice.”
Second takeaway message regarding the implementation of rfc0020:
“PoS blocks lower PoW difficulty, PoW blocks raise PoW difficulty”
Necessary protocol change:
nPoWHeight must be implemented. This variable would keep track of how many pow blocks there are, and has generality to be used for e.g. finding number of PoS blocks = nHeight - nPoWHeight.