Signaling and Activation in Bitcoin
In this article, we look at two major BIPs that allowed miners to coordinate their actions during changing the consensus rules in the Bitcoin protocol.
Table of contents.
- Introduction.
- BIP-34.
- BIP-9.
- Summary.
- References.
Prerequisite
Introduction.
In the previous article, we learned about soft forks also referred to as non-contentious forks, how they are implemented, and some of the issues related to their implementations.
Soft forks allow nodes that refuse to adopt new consensus rules to continue operating on the blockchain. Because of this, the process involved in the activation of a soft fork is through miners who signal readiness. For a soft fork to be activated, the majority of miners must confirm their readiness and willingness to adopt the new rules.
For miners to be able to coordinate their actions, a signaling mechanism is put in place that allows them to show support for the new change to the underlying protocol.
This process in question was brought about by BIP-34 back in 2013 and later replaced in 2016 by BIP-9 both of which dealt with the issue of signaling and activation. We will look at these two BIPs and what they proposed for Bitcoin transactions and blocks.
BIP-34.
The main motivation behind this was to exercise a mechanism whereby the network participants collectively consented to implement upgrades to transactions, blocks, rules, and behaviors. Also, it served to enforce uniqueness in transactions and help with the validation of unconnected blocks. Since it was a soft fork, a node that did not adopt it remained valid although miners were strongly recommended to upgrade, however, if 95% upgraded the rest would be invalidated.
This BIP proposed a change in the consensus rules that required the coinbase field of a transaction to have the block height. Before this, this field could have any data miners could choose to have. For example, in the genesis block by Satoshi Nakamoto, this field had the text "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks."
After this BIP was activated, the miner had to include the block height at the start of the coinbase field and be identified by a version number that was greater than or equal to 2. Now, miners used version number 2 since the previous was 1. Note that nodes/peers that did not abide by this still produce valid blocks that were recognized by nodes that did and vice versa. However, once the BIP was activated, version 1 blocks were invalidated meaning that for a block to be valid it had to have the block height in the coinbase field of a block.
This BIP specified a two-step activation mechanism that was based on a rolling window of 1000 blocks where a miner would signal his/her readiness and consent to construct blocks with version 2. The steps were as follows;
- First, if 75%, that is, 750 of 1000 of the recent blocks are marked with version 2, then version 2 blocks must also contain the block height in the coinbase transaction data field otherwise they are rejected. Here version 1 blocks are still acceptable and therefore don't need to have the block height. In this case, both rules operated and work for both nodes that adopted this change and those that ignored it.
- Secondly, if 95%, that is, 950 of 1000 of the most recent blocks were version 2, version 1 blocks were invalidated. In this case, version 2 blocks remained valid only if they had the block height in the coinbase transaction data field. Here all nodes were forced to comply with the new rule since the majority did and those that failed to comply were invalidated.
After signaling and activation mechanisms were successful the above two-step mechanism was also applied two more times to activate soft forks namely;
- BIP-66 that proposed strict DER encoding of digital signatures. This signaled version 3 blocks and invalidated version 2 blocks.
- BIP-65 that implemented the CHECKLOCKTIMEVERIFY opcode. This signaled version 4 blocks and invalidated version 3 blocks.
After the latter BIP (65), BIP-34 was replaced with BIP-9 which we learn about in the following section.
BIP-9.
The motivation behind this BIP was based on doing soft forks without the need for a predefined flag time stamp instead relied on measuring the miner support indicated by a higher version number in the block headers. It supported a single change being rolled out at once that required coordination between proposals. It prevented permanent rejection of a proposal and as long as a soft fork had not been fully rolled out, no future soft forks could be scheduled.
This BIP came as a replacement for BIP-34 because it faces limitations. These included;
- Changes reduced the available block versions that could be used for future changes.
- Using an integer as a block version number meant that only one soft fork could be activated at a single time. This required proposals to coordinate, prioritize and sequence they're rolling out.
- Since the block version was incremented, BIP-34 did not offer a way to reject a change and propose a new different one. This meant that if old nodes rejected changes, they could mistake signaling for a new change for signaling for a previously rejected change.
BIP-9 overcame these limitations and improved the speed and ease of implementing new changes. It overcame the limitations in the following ways;
- First, it interpreted the block version field as a bit instead of an integer. In this case, 29 bits were available for use to signal readiness on 29 different proposals.
- Also, it also set a maximum time for signaling and activation. In this case, miners did not have to signal forever instead, if a proposal is not activated within the set time, it was rejected and could be submitted using a different bit thus renewing the activation period.
- In addition to the above point, after the time passed, the feature was either activated or rejected meaning the signal bit could be reused for other features without issues.
BIP-9 also counts activation signaling in whole intervals based on the retargeting period(2016) blocks, in that, for every target period, if the sum of blocks signaling for a proposal exceeded 95%, the proposal would be activated one retarget period later.
The following is a state transaction diagram that demonstrated the stages involved in a proposal;
Above, proposals start in the DEFINED state when their parameters are known. For blocks with MTP(Median Time Past), the proposed transactions to STARTED.
If the voting threshold is exceeded within the retarget period(2016) and time has not passed the maximum, the proposal transitions to LOCKED_IN. After the retarget period, the proposal transitions to ACTIVE. On the other hand, if the time passes the max before the voting threshold is reached, the state transitions to FAILED. In this case, the proposal was rejected(REJECTED).
A case on point where this BIP was used was in the implementation of CHECKSEQUENCEVERIFY in 2016 among other BIP implementations such as BIP 68, 112, 113.
Summary.
A soft-fork / non-contentious fork is a forward-compatible change to the existing consensus rules that allow nodes refusing to change to continue their operations on blocks and transactions using the new consensus rules.
A signaling mechanism was put in place that allowed miners to show their support for the new change to the underlying Bitcoin protocol. It allowed miners to be able to coordinate their actions in changing the consensus rules. This mechanism was implemented by BIP-34 back in 2013 and replaced in 2016 by BIP-9.