BUIP057: Add BIP135 support (BIP9+)
Proposer: Sancho Panza (@SanchoPanza, sanch0panza@protonmail.com)
Sponsor: Andrea Suisani (@sickpig)
Submitted on: 2017-04-14
Status: draft
This BUIP proposes to add client support for BIP135.
In the following the BIP135 specification is reproduced for convenience.
BIP9 introduced a mechanism for using the version bits to signal support
for backwards-compatible changes (soft-forks) using a tally over the
previous 2016 blocks computed at re-targeting intervals. It provided for
a fixed threshold and non-configurable lock-in interval applicable to
all deployments on a chain.
This document describes a generalized signaling scheme which allows each
signaling bit to have its own configurable threshold, window size
(number of blocks over which it is tallied) and a configurable lock-in
period.
It extends the semantics of the signaling bits to cover arbitrary
consensus changes, referred to under the general term ‘forks’. The same
range of version bits is used for signaling.
The states of the BIP9 state machine and its original parameters (name,
bit, starttime, timeout) are retained. Some state transition conditions
are extended by additional parameters (‘threshold’, ‘windowsize’,
‘minlockedblocks’, ‘minlockedtime’) to provide for fine-tuning of
threshold and grace period.
The Bitcoin protocol requires a flexible scheme for finding consensus on
protocol changes, to ensure that it can adapt to the needs of the market
and remain competitive as an electronic payment system.
While BIP9 has served the community well for previous deployments, there
are some shortcomings in its approach:
A generalized revision of the BIP9 specification can address these
issues and satisfy the needs of the market for both soft and hard fork
changes as well as more flexible activation thresholds and upgrade
(grace) periods.
The proposal should allow more freedom of choice in activation
strategies while remaining backward compatible with respect to existing
BIP9-based deployments.
The version bits used by this proposal for signaling deployment of forks
are referred to as ‘signaling bits’ or shortened to ‘bits’ where
unambiguous.
All times in this specification are in seconds since the epoch [1].
Durations / time offsets are in seconds.
The term ‘MTP’ refers to the ‘median time past’ which is calculated as
the median nTime of a block and its 10 predecessors. It is treated as a
monotonic clock defined by a chain, and evaluated on the ancestor of a
block, i.e.
MTP := GetMedianTimePast(block.parent)
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”,
“SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this
document are to be interpreted as described in RFC 2119.
This specification SHALL enable strict backward compatibility with
existing BIP9-based deployments through suitable parameter
configuration. Any part of the specification preventing full backward
compatibility SHALL be considered as erroneous and amended.
As before, a set of configuration parameters SHALL exist for the version
bits for each chain supported by an implementation. This permits each
bit to be configured independently for each chain (mainnet, testnet,
etc.)
The signaling bits SHALL comprise the 29 least significant bits of the
nVersion block header field. nVersion is a 32-bit field which is treated
as a little-endian integer.
Signaling bits SHALL be assigned numbers from 0…28 ranging from the
least significant (bit 0) to the most significant (bit 28) in the range.
The top 3 bits of nVersion MUST be set to 001 , yielding a range of
possible nVersion values between [0x20000000…0x3FFFFFFF], inclusive.
If a block’s nVersion does not have its top 3 bits set to 001, all its
signaling bits MUST be treated as if they are 0 (see also: ‘Tallying’
section below).
With each block and fork, we associate a deployment state. The possible
states are:
In accordance with BIP9, a block’s state SHALL never depend on its own
nVersion; only on that of its ancestors.
Each fork deployment is specified by the following per-chain parameters:
If a block’s nVersion does not have its top 3 bits set to 001, all its
signaling bits MUST be treated as if they are ‘0’.
A signaling bit value of ‘1’ SHALL indicate support of a fork and SHALL
count towards its tally on a chain.
A signaling bit value of ‘0’ SHALL indicate absence of support of a fork
and SHALL NOT count towards its tally on a chain.
The signaling bits SHALL be tallied whenever the head of the active
chain changes (including after reorganizations).
The following diagram illustrates the generalized state machine:
NOTES:
The genesis block of any chain SHALL have the state DEFINED for each
deployment.
A given deployment SHALL remain in the DEFINED state until it either
passes the starttime (and becomes STARTED) or the timeout time (and
becomes FAILED).
Once a deployment has STARTED, the signal for that deployment SHALL be
tallied over the the past windowsize blocks whenever a new block is
received on that chain.
A transition from the STARTED state to the LOCKED_IN state SHALL only
occur when all of these are true:
A similar height synchronization precondition SHALL exist for the
transition from LOCKED_IN to ACTIVE. These synchronization conditions
are expressed by the “mod(height, windowsize) = 0” clauses in the
diagram, and have been been added so that backward compatibility with
BIP9’s use of the 2016-block re-targeting periods can be configured for
existing deployments (see above ‘Optional full backward compatibility’
section).
A transition from LOCKED_IN to ACTIVE state SHALL only occur if the
height synchronization criterion is met and two configurable ‘grace
period’ conditions are fulfilled:
NOTE: If minlockedtime and minlockedblocks are both set to 0, then the
fork will proceed directly to ACTIVE state once the chain height reaches
a multiple of the windowsize.
The ACTIVE and FAILED states are terminal; a deployment stays in these
states once they are reached.
Deployment states are maintained along block chain branches. They need
re-computation when a reorganization happens.
New consensus rules deployed by a fork SHALL be enforced for each block
that has ACTIVE state.
An implementation SHOULD notify the operator when a deployment
transitions to STARTED, LOCKED_IN, ACTIVE or FAILED states.
It is RECOMMENDED that an implementation provide finer-grained
notifications to the operator which allow him/her to track the measured
support level for defined deployments.
An implementation SHOULD warn the operator if the configured (emitted)
nVersion has been overridden to contain bits set to ‘1’ in contravention
of the above non-signaling recommendations for DEFINED forks.
It is RECOMMENDED that an implementation warn the operator if no signal
has been received for a given deployment during a full windowsize period
after the deployment has STARTED. This could indicate that something may
be wrong with the operator’s configuration that is causing them not to
receive the signal correctly.
For undefined signals, it is RECOMMENDED that implementation track these
and alert their operators with supportive upgrade notifications, e.g.
Since parameters of these deployments are unknown, it is RECOMMENDED
that implementations allow the user to configure the emission of such
notifications (e.g. suitable N and M parameters in the messages above,
e.g. a best-guess window of 100 blocks).
The getblocktemplate features introduced in BIP9 remain in effect
unmodified.
The timeout into FAILED state allows eventual reuse of bits if a fork
was not successfully activated.
A fallow period at the conclusion of a fork attempt allows some
detection of buggy clients, and allows time for warnings and software
upgrades for successful forks. The duration of a fallow period is not
specified by this proposal, although a conventional fallow period of 3
months is RECOMMENDED.
Due to the constraints set by BIP 34, BIP 66 and BIP 65, there are only
0x7FFFFFFB possible nVersion values available. This limits to at most 30
independent deployments. By restricting the top 3 bits to 001 we we are
left with 29 out of those for the purposes of this proposal, and support
two future upgrades for different mechanisms (top bits 010 and 011).
The following guidelines are suggested for selecting the parameters for
a fork:
NOTE: If minlockedtime and minlockedblocks are both set to 0, then the
fork will proceed to ACTIVE state when the chain height reaches a
multiple of the windowsize.
A later deployment using the same bit is possible as long as the
starttime is after the previous fork’s timeout or activation, but it is
discouraged until necessary, and even then recommended to have a pause
in between to detect buggy software.
An implementation SHOULD signal ‘0’ on a bit if one of the following
holds true:
An implementation SHOULD enable the operator to choose (override)
whether to signal ‘0’ or ‘1’ on a bit, once its deployment has at least
reached the STARTED state.
An implementation SHOULD warn the operator if the configured (emitted)
nVersion has been overridden to contain bits set to ‘1’ in contravention
of the above non-signaling recommendations.
A supporting miner SHOULD signal ‘1’ on a bit for which the deployment
is LOCKED_IN state so that uptake is visible. However, this has no
effect on consensus rules. Once LOCKED_IN, a deployment proceeds to
ACTIVE solely based on the configured grace period parameters (see ‘Fork
deployment parameters’ above).
A miner SHOULD signal ‘0’ on a bit if they wish to suspend signaling of
support for a fork that is DEFINED in their software.
It is NOT RECOMMENDED to signal ‘1’ for bits where the meaning is
undefined (i.e. bits which are unclaimed by proposals).
This section lists parameter values which can be used to effect
compatibility with the existing BIP9 versionbits state machine.
The following table describes mainnet compatibility options (95%, 2016
blocks):
| Parameter |
| name |
| bit |
| starttime |
| timeout |
| windowsize |
| threshold |
| minlockedblocks |
| minlockedtime |
The following table describes testnet compatibility options (75%, 2016
blocks):
| Parameter |
| name |
| bit |
| starttime |
| timeout |
| windowsize |
| threshold |
| minlockedblocks |
| minlockedtime |
As this BIP is not itself consensus-relevant (Information like BIP9), it
can be rolled out without the use of a BIP9 fork bit.
Backward compatibility through judicious fork configuration parameters
should ensure that it does not interfere with existing known
deployments.
By way of design it does not interfere with unknown (undefined)
deployments.
Working reference implementations, including tests, can be found in
these Pull Requests:
Existing unit tests and regression tests have been left active to
demonstrate backward compatibility of the default settings with BIP9.
[1]
http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap04.html#tag_21_04_16
[2] List of existing BIP9 deployment
proposals
This BIP is dual-licensed under the Creative Commons CC0 1.0 Universal
and GNU All-Permissive licenses.