BIP 8 — Bitcoin Improvement Proposal Explained
As a software proposal, Bitcoin is flexible enough to change during various improvement processes. Since it is supported by several groups of software developers, it is important to implement changes to all wallets at the same time. This issue is partially solved with the help of a special GitHub page where developers can explain all proposed changes.
Most of the proposed changes are presented in the form of so-called BIPs (Bitcoin Improvement Proposals). Earlier, we learned what the BIP is, compared two types of proposals — BIP 1 and BIP 2, and gave a detailed description of the update process in the Bitcoin network.
As you know, each proposed network improvement has its own purpose. Most often it is space saving. Each block has a specific size and average creation time. Assuming these parameters are stable, it is critical to rationally use every bit. Another important point is soft forks and their consequences. That is exactly what BIP 8 is about.
The Main Idea Of BIP 8
In the previous article, we discussed the concept of the BIP 9 proposal. BIP 8 is its alternative solution. It replaces activation based on time with a block height parameter. These two parameters are similar in a way, still they have differences too. Taking into account the fact that time can be configured differently, it turns out that the block height gives more accuracy. Thus using it brings more clarification to the system.
Another distinctive feature of BIP 8 is the activation mechanism. BIP 9 requires that the majority of network members agree on a new soft fork implementation. This process may take some time, or the application may be rejected if a part of the community decides so. It is more reliable to substitute this approach with economy-based activation. In this case, the majority of full nodes simply start generating and accepting new blocks at a certain block height. Thus, there will be no option for the minority to avoid soft forks.
One year is recommended as a time delay before activation in BIP 8.
Soft Fork Deployment
Deployment of soft fork is described as a set of necessary parameters. They are:
- For clear and unambiguous fork definition, a fork must have a unique name. Since the majority of forks are described in corresponding BIPs, it is logical to use the name “bipN” in this field.
- The second parameter simply determines a bit responsible for implementing a particular change. As described in BIP 9, these bits are used as long as they are needed. After some time, they are abandoned and later reused.
- A block height is used as a third parameter. This is the block number explained earlier which is responsible for fork initiation time.
- The last parameter called “timeoutheight” specifies the block number when the state “LOCKED_IN” is to be reached. This state can be reached in two ways. The first one is when a set up threshold of new blocks corresponding to the update is exceeded. The second way is defined by this parameter.
Speaking of states, it will be interesting to consider them all.
- When a proposal is explained and prepared for implementation it is in the “DEFINED” state. This means that there is an explanation to the proposal, and anyone can read it.
- After the activation block height is reached and new blocks are generated by miners, the “STARTED” state is valid for proposal.
- After new blocks are generated, their correspondence is defined by a special bit. This bit can be checked easily. As soon as blocks with this bit reach special threshold (95% for mainnet as of 2016) and the retarget procedure is performed, the “LOCKED_IN” state is activated.
- The last valid state called “ACTIVE” is reached after one retarget period in the “LOCKED_IN” state.
- If there are any problems with introducing a proposal, and the proportion of blocks is not enough, then the “FAILED” state is reached.
Using BIP 8 as an example, we can see that there may be several implementations of the same idea in the Bitcoin environment. This is one of the best advantages of Bitcoin. Each participant can propose adequate and reasonable ideas or even improve proposals of other members. This is how a real open source project should work.