Bitcoin BIPs.
In this article, we learn about Bitcoin Improvement Proposals, their function, how they are created, and approved, and the different types of BIPs in Bitcoin.
A BIP(Bitcoin Improvement Proposal) is a formal proposal to change the Bitcoin core software in terms of optimizations, debugging, code refactoring, and compatibility just to name a few. Compared to other proprietary software owned and managed by a single centralized entity whereby changes to the software are implemented on the go by the lead developer, BIPs are a way for Bitcoin community members to be able to propose and approve upgrades to the software in a decentralized manner since there is no leadership.
BIPs can consist of small tweaks of code refactoring to large changes which can take a long time for them to be fully implemented. In this article, we will learn about Bitcoin BIPS, parties involved in the submission and approval of BIPs, and describe some past examples of BIPs.
The following are some of the most valuable BIPs in Bitcoin; BIP - 91 - This allowed miners to coordinate activation of the existing SegWit using less than 95% of the hash power. It prevents a coin split by making SegWit and BIP 148 compatible. In general, it makes it easier for Bitcoin to adopt SegWit thereby fixing transaction malleability and also paves way for off-chain implementations such as the lightning network.
BIP - 141 - This BIP was introduced to prevent the malleability of transactions on the blockchain. It also served to increase the capacity of a single Bitcoin block. It did this by splitting a transaction into two segments, removing the unlocking signature('witness') from the original portion, and appending it as a separate entity at the end of a transaction. In this case, while the original data segment was counted normally, the witness was counted as a quarter of its actual size.
BIP - 148 - this BIP enforced the use of the Segregated Witness(SegWit) protocol. It was a soft fork thereby did not cause any chain splits. It required miners to show that they are ready to use a block that had already implemented the SegWit protocol.
These among many others serve as improvements to the Bitcoin protocol.
How BIPs Work.
Bitcoin is just software like any other, the source code can be found here. Just like normal programs, upgrades, code refactoring, debugging, and optimization are processes the Bitcoin software has to undergo. Unlike other proprietary software owned and managed by a centralized entity, Bitcoin is a decentralized, open-source system based on consensus. Decentralization is responsible for the success of Bitcoin, changes to the software are also decentralized, in that, if changes are proposed, community members have to agree on the changes for them to be implemented.
Due to the size of the community, Bitcoin is secure and immutable, this also means that changes to the core software will take time a lot of time to be implemented. A change can range from a small bug fix to a large change in the underlying foundational protocols which can take up to months or years. This is because members/participants have to evaluate and this is a long process. These BIPs and their corresponding discussions can be found on github.
How BIPs are Created.
Anyone can propose an upgrade to the core Bitcoin software. This is because the software is open-source and decentralized. A proposal of course has to be scrutinized and voted for or against by community members. A contributor can informally propose a change to Bitcoin's core by sending emails to an email list or joining an appropriate slack channel. Any member can go through the proposed change and give feedback. Some proposals never get implemented because of various reasons such as the bitcoin community not reaching a consensus or bitcoin itself not being ready for the said changes among other reasons. This is the main reason BIPs take a long time.
After the email or the initial proposal to the community, members discuss it among themselves and have to reach a consensus after which the proposal is officiated by assigning it a BIP number and publishing it to github repository. Note that at this stage, the BIP is just official, it is not yet approved by the members and therefore cannot be implemented.
How BIPs are Approved.
Once a BIP is official and has been published on Bitcoin's GitHub repository, a discussion is opened and community members discuss it openly among themselves. Since a BIP consists of operations dealing with the core Bitcoin code, developers translate the proposal into working code which undergoes a series of tests such as integration tests.
As the discussions are ongoing among community members, different perspectives are heard and valid arguments can be raised why the change should not be implemented. These changes can lead to a BIP being rejected, this means that the proposal process is again restarted. On the other hand, if the discussions lead to a consensus among members the BIP is approved and an activation path is started.
The following is a logical representation of the BIP process from proposal to approval.
Above, the process first starts with a draft. At this stage, the draft can either be deferred and stops there or proceed to the next stage where a consensus takes place. During the consensus phase, participants discuss the BIP among themselves and decide whether it should be rejected or accepted. It can also be withdrawn for various reasons. Once it passes this stage, it is activated. This is where it is implemented to the main blockchain. Here developers will start working on the features if it is a technical issue. A BIP can also be a process BIP or a Consensus BIP. We discuss the different types of BIPs below.
Types of BIPs.
Anyone can propose a BIP, both developers and non-developers, anyone, and as such BIPs can be categorized. A BIP can be a proposed change to the code, consensus rules, interoperability, and guidelines among others. Different BIPs require different activations. In this section, we look at a brief overview of the major types of BIPs and some of their examples.
Consensus BIPs The bitcoin blockchain is governed by a set of rules and protocols that are implemented in C++ code. These protocols are distributed among all valid Bitcoin nodes and are used in the processing of transactions on the blockchain. They are also used to manage edge cases when they occur. This means that all nodes need to come to a consensus and implement the same Bitcoin program. However, there are cases of nodes not agreeing which results in a fork, a fork can be hard or soft as we will learn in later articles. Consensus BIPs are backward compatible meaning that nodes that choose not to upgrade are still valid on the blockchain.
An example of a consensus BIP is the SegWit upgrade(BIP 141)
Standard BIPs These BIPs propose standards for the Bitcoin blockchain rather than changes to the code. Usually, standards come as a result of a consensus BIP, for example in SegWit consensus BIP, a standard BIP(BIP 142) was proposed as a standard for SegWit addresses.
Process BIPs These BIPs are created to streamline Bitcoin development and community discussions. No changes to the code or Bitcoin blockchain itself rather, how processes such as activation should take place. Examples of process BIPs include BIP 1 and 2. These describe the format and lifecycle and activation of future BIPs.
Summary
BIPs are formal proposals that are used to propose changes to the Bitcoin core software and protocols. They are used by the decentralized Bitcoin community to organize and implement changes such as bug fixes, optimizations, code refactoring, etc. BIPs are used to propose changes to the consensus layer of Bitcoin, Bitcoin community standards, and the process involved with Bitcoin's development. BIPs approval consists of a draft which is submitted to a slack chat or an email list, a proposal which involves a plan on the implementation of the proposal, and approval of the proposal by the community members. BIPs ensure transparency and the decentralization of power. This makes sure Bitcoin cannot be controlled by a single centralized source. The code can be written by Bitcoin's developers but all nodes in the network have to approve it.