Implement dynamic activation thresholds - #3692
Merged
Merged
Conversation
thephez
reviewed
Sep 8, 2020
UdjinM6
force-pushed
the
dynthresholds
branch
from
September 8, 2020 16:36
c688e0c to
8f676f8
Compare
xdustinface
requested changes
Sep 10, 2020
xdustinface
left a comment
xdustinface
left a comment
There was a problem hiding this comment.
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?
UdjinM6
force-pushed
the
dynthresholds
branch
2 times, most recently
from
September 10, 2020 16:23
77bd404 to
dae4a19
Compare
UdjinM6
force-pushed
the
dynthresholds
branch
from
September 10, 2020 16:25
dae4a19 to
60ae186
Compare
|
ACK, Looks good to me 👍 |
xdustinface
approved these changes
Sep 11, 2020
PastaPastaPasta
approved these changes
Sep 12, 2020
PastaPastaPasta
left a comment
PastaPastaPasta
left a comment
Member
There was a problem hiding this comment.
ACK, code looks good, tests pass, ran locally
| assert_equal(get_bip9_status(self.nodes[0], 'realloc')['status'], 'started') | ||
|
|
||
| def threshold(self, attempt): | ||
| threshold_calc = 400 - attempt * attempt; |
PastaPastaPasta
pushed a commit
to PastaPastaPasta/dash
that referenced
this pull request
Sep 12, 2020
* 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 `;`
gades
pushed a commit
to cosanta/cosanta-core
that referenced
this pull request
Mar 11, 2022
* 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 was referenced Oct 21, 2025
PastaPastaPasta
added a commit
that referenced
this pull request
Jul 28, 2026
…itcoin#24579, bitcoin#25412, bitcoin#27853 (deployment backports) 5b7f870 merge bitcoin#27853: bugfix, fix crash error when calling `/deploymentinfo` (Kittywhiskers Van Gogh) 60fd0b5 merge bitcoin#25412: add `/deploymentinfo` endpoint (Kittywhiskers Van Gogh) 55421eb merge bitcoin#24579: Fix getblockchaininfo/getdeploymentinfo RPC docs (Kittywhiskers Van Gogh) b380a6b merge bitcoin#24528: rename getdeploymentinfo status-next to status_next (Kittywhiskers Van Gogh) c94b91a merge bitcoin#24187: Followups for getdeploymentinfo (Kittywhiskers Van Gogh) 0fa73c6 merge bitcoin#23508: Add getdeploymentinfo RPC (Kittywhiskers Van Gogh) 3e9c558 fix: remove duplicate `min_activation_height`, `activation_height` fields (Kittywhiskers Van Gogh) Pull request description: ## Additional Information * Depends on #6901 * Depends on #6933 * In [bitcoin#23508](bitcoin#23508), `AbstractThresholdConditionChecker::GetStateStatisticsFor()` retains `pindexEndOfPrevPeriod` unlike upstream as it's used to calculate dynamic activation threshold (see [dash#3692](#3692) for more information) but it _isn't_ used to calculate `elapsed` as [bitcoin#23508](bitcoin#23508) no longer calculates the status of the _next_ block but the _current_ block, which prevents complete preservation of old logic. * Due to this change in behavior, test adjustments were necessary in `feature_mnehf.py` and `feature_new_quorum_type_activation.py` to mine one more block to get status information expected by the tests. ## Breaking Changes Requesting deployment information from `getblockchaininfo` is now deprecated (replaced by `getdeploymentinfo`) and restoring old behaviour will require the runtime flag `-deprecatedrpc=softforks`. ## Checklist - [x] I have performed a self-review of my own code - [x] I have commented my code, particularly in hard-to-understand areas **(note: N/A)** - [x] I have added or updated relevant unit/integration/functional/e2e tests - [x] I have made corresponding changes to the documentation - [x] I have assigned this pull request to a milestone _(for repository code-owners and collaborators only)_ ACKs for top commit: knst: utACK 5b7f870 Tree-SHA512: b945985508cb46632f0cec4ac50db93fc13e65977d5446a1ae17b6ebae41b63d811b366c03439ad8a9e3c73a3b0f59e53a3ca132f560a658b873b954659e4b16
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
4 participants
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.
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:
(based on #3691 atm)