What are BIPs and why do they matter to Bitcoin’s future?

What are Bitcoin Improvement Proposals (BIPs)?

Any hard fork that occurs in the Bitcoin network is the result of a proposed change to Bitcoin’s protocol. For the largest part, any changes to Bitcoin, including forks, have their origins in the Bitcoin Improvement Proposal (BIP) process.

The first BIP was proposed and enacted in 2011 by a Bitcoin developer named Amir Taaki and is an outline of the process of how new features are added to Bitcoin. BIP 2 and several other improvement proposals that followed expanded upon the ideas contained in the first BIP. The BIPs process was inspired by Python Enhancement Proposals, which Python developers follow to improve the Python programming language. BIPs on GitHub introduce a certain new code or describe how to deal with a problem in the future.

The BIP process was inspired by Python Enhancement Proposals, which Python developers follow to improve the Python programming language. 

In both cases, these guidelines are a structure for the particular development communities behind a network in a decentralised way. Every developer involved has an equal say in which changes will be executed and which will not. Also, as the process is decentralised no one individual or group leads but every developer and miner decide as a collective, similar to a set of rules for a decentralised autonomous organisation DAO. 

How does the BIP process work?

Overall, there are three types of Bitcoin Improvement Proposals: Standards Track BIPs, Process BIPs and Informational BIPs. For our purposes, we will only discuss Standards Track BIPs, which are the most relevant for the near future of the Bitcoin network since they include rules on the changes to the Bitcoin protocol.  

Each BIP actually originates from an informal discussion amongst Bitcoin developers anywhere that they congregate, including Twitter. At this time, any developer can propose changes to the BIP involved. All proposals are taken seriously and the discussion process is usually iterative, meaning that steps are revisited and improved several times. A draft is drawn up and sent to the Bitcoin developer mailing list for review in the community, where changes can also be proposed.

Actually, each BIP originates in an informal discussion amongst Bitcoin developers anywhere that they congregate, including Twitter. 

Once a BIP draft passes through all of these stages, it is assigned “active status” and implementation work begins. To mitigate against the risk of too much centralisation, a technical BIP usually requires that miners “signal” majority support for the proposed change. If the miners don’t support the proposal, a BIP can be marked as deferred, withdrawn or even outright rejected.

What is signalling and how do miners do it?

After years of discussion in the Bitcoin development community on how to scale Bitcoin, in 2015, Peter Wuille proposed SegWit as a scalability solution. However, miners and full nodes initially managed to prevent SegWit-related BIPs from passing by failing to adequately “signal” their support for these proposals. 

Despite this first rejection, by July 2017, BIP 91 finally passed the scrutiny of Bitcoin developers and was sent onto the mining community. The reason behind the late success was a “rephrased” BIP. Instead of asking miners to accept the change, the proposal was rephrased and proposed that “those who signal BIP 91 do NOT accept blocks from NON-Segwit supporters”. By August 2017, 100% of full nodes had added the required bits to all of the required blocks and SegWit was implemented into Bitcoin’s protocol at block 477,120. 

In the case of Bitcoin, a soft fork only requires a majority of the network’s miners to update their software to the new version, which is where signalling comes in. 

As you may remember from previous articles, soft forks do not require all of a network’s users to update their software. Instead, in the case of Bitcoin, a soft fork only requires a majority of the network’s miners to update their software to the new version, which is where signalling comes in. To “signal” their consent all full nodes need to add a piece of data called a “bit” to a predetermined number of blocks in a row. 

Speedy Trial for Taproot

In order to simplify achieving consensus for changes to Bitcoin, a new proposal called “Speedy Trial” was implemented, reducing the time miners have to express their consent or dissent to three months from the previous period of one year. Once 90% express their consent, the change is locked in before it is activated after another six months. If the 90% locked-in is not achieved, the change is rejected. 

The next major Bitcoin update, Taproot, was based on this new proposal and consensus was reached much faster than any previous upgrade. Taproot improves transaction privacy and security and introduced key aggregation with Schnorr signatures to replace ECDSA. The Taproot update also improves Bitcoin's scalability and further paves the way for the introduction of smart contracts on the Bitcoin blockchain.

The pros and cons of BIPs

Thanks to the framework behind BIPs, all developers and all miners have an equal say throughout the BIPs process. Consequently, BIPs are integral to keeping further development of the Bitcoin network decentralised without leaders or developer groups. This is to ensure that majority interests are represented. 

However, the average Bitcoin holder is not formally included in this process. For this reason, critics of Bitcoin’s leadership have pointed out that the BIPs process is not really decentralised. Networks such as Tezos propose alternative forms of governance aiming to include more users in order to remedy this shortcoming.