Versionbits extensions for BIP-110

dathonohm commented at 6:55 pm on March 26, 2026: none

This PR implements the Deployment portion of BIP-110. There is a second PR, built on this one, that implements the BIP-110 consensus changes and deployment parameters. I have split these two features into separate PRs in order to facilitate review.

This first PR is a generic extension of the pre-existing BIP9 framework to add the BIP8-style activation and temporary deployment pieces BIP-110 needs, namely:

max_activation_height: mandatory activation deadline - forces LOCKED_IN one period before the specified height, regardless of miner signaling (similar to BIP8’s lockinontimeout=true)
active_duration: number of blocks a deployment remains active after activation, after which it transitions to a new terminal EXPIRED state
Mandatory signaling enforcement: blocks must signal for the deployment during the enforcement window ([max_activation_height - 2*period, max_activation_height - period)), with vbrequired set in getblocktemplate output (similar to BIP8’s MUST_SIGNAL phase)

Regtest command-line support for max_activation_height, active_duration, and threshold have also been added to aid in testing.

These features may be reused as necessary for future softforks.

Background and Motivation

See the corresponding sections on the dependent PR.

Features

New `BIP9Deployment` fields

max_activation_height (default: INT_MAX = disabled)
active_duration (default: INT_MAX = permanent)

State machine changes

STARTED -> LOCKED_IN forced when height >= max_activation_height - period
ACTIVE -> EXPIRED when height >= activation_height + active_duration (new terminal state)
active_duration must be a multiple of period

Mandatory signaling

Blocks that don’t signal during the mandatory signaling period (max_activation_height - 2*period through max_activation_height - period - 1) are rejected
getblocktemplate sets vbrequired bits during this window

RPC

getdeploymentinfo: new max_activation_height field in bip9 object when set
getdeploymentinfo: new height_end field when ACTIVE with active_duration
status field now includes "expired" as a possible value

Regtest `-vbparams` support

Extended format: deployment:start:end[:min_activation_height[:max_activation_height[:active_duration[:threshold]]]]
Validates mutual exclusion of timeout and max_activation_height
Validates active_duration is a multiple of period

Tests

11 unit tests covering forced lock-in, boundary conditions, EXPIRED transitions, cold cache recovery, parameter validation, and edge cases (zero duration, unaligned duration rejected)
Functional test (feature_bip9_max_activation_height.py): mandatory activation, normal signaling, early activation, permanent vs temporary deployments, custom threshold, and mandatory signaling enforcement (non-signaling block rejected)
Fuzz test updates for active_duration and EXPIRED state

Note: enforcement-level testing (consensus rules activating/deactivating via DeploymentActiveAfter) is in PR 2, which provides a real deployment (REDUCED_DATA) to test against. TESTDUMMY has no consensus enforcement.

Size

~175 lines non-test C++/H. This puts these deployment changes for BIP-110 at about half the size of the deployment changes required for CSV (BIP-68/112/113), which weighed in at 371 lines.

versionbits: add expiry support to versionbit deployments 731adbdad4

versionbits: add max_activation_height for mandatory BIP9 activation 3444808035

chainparams: support regtest vbparams for max_activation_height and active_duration 7227d5ef12

test: add versionbits unit tests for max_activation_height and active_duration 402f257559

chainparams: support regtest vbparams for per-deployment threshold e46a82ae82

versionbits: add mandatory signaling enforcement for max_activation_height and set vbrequired during mandatory signaling d8d9d53f87

test: add functional tests for modified BIP9 deployment features 28650257b6

DrahtBot commented at 6:55 pm on March 26, 2026: contributor

♻️ Automatically closing for now based on heuristics. Please leave a comment, if this was erroneous. Generally, please focus on creating high-quality, original content that demonstrates a clear understanding of the project’s requirements and goals.

📝 Moderators: If this is spam, please replace the title with ., so that the thread does not appear in search results.

DrahtBot closed this on Mar 26, 2026

DrahtBot commented at 6:55 pm on March 26, 2026: contributor

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Reviews

See the guideline for information on the review process. A summary of reviews will appear here.

LLM Linter (✨ experimental)

Possible places where comparison-specific test macros should replace generic comparisons:

[src/test/versionbits_tests.cpp] BOOST_CHECK_THROW(CreateChainParams(args, ChainType::REGTEST), std::runtime_error); -> Replace with BOOST_CHECK_EXCEPTION(...) and assert the specific std::runtime_error reason (e.g., message contains active_duration (200) must be a multiple of period (144)) using HasReason(...) (or an equivalent matcher), since the test can validate the precise failure mode rather than only the exception type.

2026-03-26 18:55:56

dathonohm commented at 6:55 pm on March 26, 2026: none

This is not spam.

bitcoin locked this on Mar 26, 2026

Versionbits extensions for BIP-110 #34929