-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement dynamic activation thresholds #3692
Conversation
c688e0c
to
8f676f8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See the two comments + What about extending the tests to verify either each threshold decrease period or at least the last before 60%, 60% and one after?
77bd404
to
dae4a19
Compare
dae4a19
to
60ae186
Compare
ACK, Looks good to me 👍 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK, code looks good, tests pass, ran locally
@@ -74,7 +74,7 @@ def signal(self, num_blocks, expected_lockin): | |||
assert_equal(get_bip9_status(self.nodes[0], 'realloc')['status'], 'started') | |||
|
|||
def threshold(self, attempt): | |||
threshold_calc = 400 - attempt * attempt; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LOL :P
* Implement dynamic activation thresholds * fix * Revert unrelated changes * Clarify switching to/staying in LOCKED_IN state * Fix signal function to work correctly with num_blocks=0 * Add simplified threshold calculation and use it in tests * Check that thresholds are decreasing, reach the min level and stay there * Drop `;`
* Implement dynamic activation thresholds * fix * Revert unrelated changes * Clarify switching to/staying in LOCKED_IN state * Fix signal function to work correctly with num_blocks=0 * Add simplified threshold calculation and use it in tests * Check that thresholds are decreasing, reach the min level and stay there * Drop `;`
This implements dynamic BIP9-like activation threshold and applies it to Block Reward Reallocation proposal.
Motivation: in Dash we used to use lower thresholds (80% vs 95% in BTC) to activate upgrades via BIP9-like mechanism for quite some time. While it's preferable to have as much of the network hashrate to signal update readiness as possible this can result in quite lengthy upgrades sometimes when one large non-upgraded entity would stale the whole progress. Simply lowering thresholds even further can result in network upgrades being too fast which can cause some chaos potentially. This PR implements dynamic thresholds which drop from some initial level to a minimally acceptable level over time at an increasing rate.
For regtest params it looks like this:
![Screenshot 2020-09-08 at 13 22 24](https://user-images.githubusercontent.com/1935069/92464817-5f286680-f1d6-11ea-97d1-4046ce0ac9e1.png)
(based on #3691 atm)