Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Standardise deployment handling #16229
This is a different approach to burying csv/segwit deployments -- rather than converting them from
I think this should make future burials much simpler (it becomes a one-line change), but there's two other benefits: it doesn't change RPC or tests much, and I think it will make it easier to make future changes to activation methods should we wish to do so. The downside is that the activations aren't hardcoded anymore, so there's a function call and a few indirect lookups to determine a fixed-height activation is enabled, rather than just a direct test.
I've added some extra commits to tidy up the
with this patch set, or, on regtest something like:
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
Reviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.
I prefer the approach in #16060. The changes in this PR seem more complex for achieving a similar goal (+110 lines here vs -70 lines in 16060)
Softfork activation/burials are sufficiently rare that I don't think we have to optimize to minimize the code changes when they do happen.
I like the new RPC return object
We've been trying to bury these deployments for almost two years now (see #11398), so I just want to see it done. If people prefer this approach, I'm happy to close 16060 in favour of this.
I think the reason it's taken that long is because burying deployments isn't trivial. "Optimising to minimise the code changes when they do happen" makes them trivial -- after the upfront work to setup Consensus::Deployment, burying segwit is just two one-line changes (one for mainnet, one for testnet):
To expand on those numbers:
I think that's pretty representative: there's a chunk of new infrastructure in chainparams/versionbits with this PR, versus a bunch of dropped test code that's not compatible with hardcode fixed height deployments in 16060; versionbitsinfo is kind of verbose; and 16060 makes a few other choices that saves lines of code that aren't in this PR.