consensus/params: Move version bits period/threshold to bip9 param

Rather than having the rule change period/threshold be constant for all
potential deployments on a chain, have it be specific to the deployment
itself. This both matches history (BIP 9 specified a 2016 block period
and 1916 block threshold; BIP 91 specified a 336 block period and 269
block threshold; and BIP 341 specified a 2016 block period and 1815
block threshold), and allows the code to be simplified, as only the
BIP9Deployment structure is needed, not the full Consensus::Params
structure.
This commit is contained in:
Anthony Towns
2023-12-07 12:16:22 +10:00
parent e9d617095d
commit a679040ec1
5 changed files with 76 additions and 45 deletions

View File

@@ -53,6 +53,14 @@ struct BIP9Deployment {
* boundary.
*/
int min_activation_height{0};
/** Period of blocks to check signalling in (usually retarget period, ie params.DifficultyAdjustmentInterval()) */
uint32_t period{2016};
/**
* Minimum blocks including miner confirmation of the total of 2016 blocks in a retargeting period,
* which is also used for BIP9 deployments.
* Examples: 1916 for 95%, 1512 for testchains.
*/
uint32_t threshold{1916};
/** Constant for nTimeout very far in the future. */
static constexpr int64_t NO_TIMEOUT = std::numeric_limits<int64_t>::max();
@@ -98,13 +106,6 @@ struct Params {
/** Don't warn about unknown BIP 9 activations below this height.
* This prevents us from warning about the CSV and segwit activations. */
int MinBIP9WarningHeight;
/**
* Minimum blocks including miner confirmation of the total of 2016 blocks in a retargeting period,
* (nPowTargetTimespan / nPowTargetSpacing) which is also used for BIP9 deployments.
* Examples: 1916 for 95%, 1512 for testchains.
*/
uint32_t nRuleChangeActivationThreshold;
uint32_t nMinerConfirmationWindow;
std::array<BIP9Deployment,MAX_VERSION_BITS_DEPLOYMENTS> vDeployments;
/** Proof of work parameters */
uint256 powLimit;