BIP 9 — Bitcoin Improvement Explained
The Bitcoin system can be considered as a distributed set of programs contacting each other. These programs are also called wallets. They have different developers responsible for their support and bug fixing. However, each wallet should be updated in order to stay within the Bitcoin environment. Indeed, if a wallet avoids being improved, it may automatically refuse new block formats, which will likely result in an incompatible hard fork.
Another important thing about wallets that work in conjunction is associated with the “version field” of the standard block. This field can be used to indicate rules for a particular block. Depending on this set of rules, wallets may work differently. For example, a part of data in the block can be ignored by wallets that do not accept a new system version. In this case, the wallet works with information received in a usual way. This is a special type of the separation and processing of different data.
General BIP 9 Description
As it is defined in the BIP 9 description, its main purpose is to support changes of blocks with backward compatibility. Such changes in the BIP are referred to as soft forks. Fork parallelisation is envisaged as well. All these changes should be supported using the “version” field in the Bitcoin block. Here the version is suggested to be considered as a bit vector. Each bit corresponds to a specific change. Periodically, these changes and bits should be revised. If a particular change is no longer used, then its bit gets “frozen” for a while. Later it moves to the pool of changes available for use.
Here it is necessary to clarify some terms.
This software feature is very important for distributed systems. It means that newly introduced properties will be accepted by old, non-updated programs. As for Bitcoin, the process is crucial due to various proposals.
Imagine that we have a standard functionality presented in every Bitcoin wallet. It includes mining, data storage, data exchange, and asset management. Now let's take two groups of enthusiasts proposing different functionality. As an example we can propose colored coins and SegWit. Now both of them propose their own wallet improvements. Obviously, they can't force all participants to switch to the new proposals immediately. Those who want to use standard blocks will do this anyway. Thus, making changes in the “version” field and providing backward compatibility allows both parties to use their updated blocks along with standard blocks of the majority. All block types will coexist on blockchain.
This definition may seem confusing, yet it is simple as that. A bit vector is a collection of individual bits that do not affect each other. Speaking of the previous example, we can set an eight-bit string as follows:
Let's say the first bit confirms that non-standard blocks really apply. The second bit is responsible for blocks with “colored coins”, and the third one deals with SegWit blocks. For simplicity, let's assume that they can't be used simultaneously. This gives us the following table:
In this article, we tried to explain the idea of introducing bit-vectors (or bit-lines) into BIP 9. As it may be seen from the proposal itself, there were no opportunities for such improvements in Bitcoin before. Moreover, BIP 9 itself is designed with the compatibility property. We will talk about other BIPs and their development stages in our next articles.