Bitcoin is a multi-layered system of physical hardware, energy expenditure, database management, and governance, and it’s all managed through code. Code that everyone running a node has to agree on while having programmable money provides us with loads of options. It has to be used sparingly. Shitcoiners have taken the opposite bet and think that changing the code is all that matters, whereas bitcoiners only want code changes if we hit roadblocks and have exhausted all other options.
Yes, the bitcoin code can be changed in theory, but not every proposal will be accepted by the community and run by most nodes. Bitcoin upgrades are not taken lightly, as risking the network’s security for a few nifty features is not an option.
That doesn’t mean bitcoin isn’t updating; not all changes to a Bitcoin software implementation affect the protocol. For example, some changes make the code run more efficiently or change the user interface. When it comes to significant scale protocol upgrades and alterations, these code changes require a BIP.
What is a Bitcoin Improvement Proposal or BIP?
A Bitcoin Improvement Proposal (BIP) is a formal proposal to change or upgrade the bitcoin protocol. As a piece of software, Bitcoin undergoes upgrades such bugs need to be fixed, algorithms can be made more efficient, code can be simplified, compatibility with other software must be maintained, and new features can be added.
In the case of standard software belonging to centralised projects, a manager or lead developer might assign tasks and dictate the changes that need to be merged with the code base post-testing.
Since bitcoin is an open-source, consensus-based system with thousands of nodes running and millions of coin holders, you have to get buy-in from many stakeholders. There is no leader.
The BIP process organises the Bitcoin community without a central leader. The BIP process allows bitcoin to remain transparent and maintain its reputation as an open and decentralised network where the network’s security is paramount to maintaining trust.
Thus, Bitcoin’s development process is intentionally slow and deliberate.
Who created the BIP process?
The BIP process was first developed and introduced 2 years after bitcoin went live, by early Bitcoin developer Amir Taaki, who also created the first alternative implementation of the Bitcoin protocol: Libbitcoin. Taaki believed that the Bitcoin development process would benefit from becoming more structured and maintaining contributions from various sources while offering a place to review and remain accountable for your proposals.
Taaki submitted the first BIP (BIP 0001) on August 19, 2011, which described the BIP process itself. It was heavily based on the process for improving Python, a programming language, described in Python Enhancement Proposal 0 (PEP 0).
How are BIPs created?
Bitcoin is an open system, and anyone can get involved should they have the time, technical knowledge and ideas for improvements. There are no real restrictions to creating a BIP; Anyone can propose a BIP, regardless of credentials or reputation.
While there is a formal structure for submitting a BIP, ideas generated for BIPs are a largely informal process, resulting from meet up discussions, Twitter engagements and forum chats.
Typically, BIPs begin as informal proposals on the Bitcoin email list or some other communication channel, such as IRC or Slack. A developer can email their idea to the email list, and anyone who is interested will respond with feedback.
Some ideas remain at this discussion stage for many years because the idea has conflicting parties who cannot find consensus or the idea requires fine-tuning; finally, in some cases, BIPs hang in limbo because Bitcoin is not yet ready for the proposed changes.
Once a proposal has been fine-tuned, and both pros and cons have been evaluated, it can be submitted to the BIP list and assigned a BIP number and published to the Bitcoin Core GitHub repository of BIPs.
At this point, the BIP is official, but it is not yet approved or implemented. Anyone can then review the BIP and provide feedback on it while it is being worked on and, at times, used on the testnet.
Status of a BIP
A BIP has an inevitable life cycle that depends on its status. If we look at the status of a BIP from creation to either rejection or implementation, a BIP can maintain one of the following statuses.
- Draft. At this point, the BIP is barely in its earliest filing state. At this point, the BIP is incomplete.
- Deferred. The BIP has been postponed because no progress has been made in its development.
- Proposed. It is the proposal accompanied with most of its explanatory elements and presented to the community. At this point, the debate on its application or not within the Bitcoin development ecosystem begins.
- Rejected. If the proposal presented is not well received, there are harmful elements or any other reason that the community uses for its rejection, it will be marked with this status.
- Retired (Withdraw). This status applies to those proposals that have been withdrawn by their authors for reasons that serve their interest.
- Final / Active. To get to this point, the proposal must have gone through community review and consensus. It must have all the necessary spaces and structures for its approval.
- Replaced. This status is given to proposals that have been replaced by better proposals. Generally because the new proposals, solve or further improve the previously presented proposal.
- Obsolete (Obsolete). This change of status is mainly related when the changes introduced by the BIP are no longer relevant. This can be due to different situations, generally because there are new changes that make its application unnecessary.
How are BIPs approved or rejected?
Every BIP starts as a draft submitted by one or several authors who currently have ideas for protocol upgrades. The draft is submitted to the BIP GitHub and worked on openly for all to see. The BIP can be changed and improved by the author(s) based on community feedback and testing feedback.
In the case of Bitcoin protocol changes, it will also require a reference implementation in code. If the proposal reaches community consensus, it will be considered final.
Adoption ultimately happens as developers implement the code that reflects the BIP into one of the node software clients, and users choose to download and run this code.
Alternatively, If legitimate arguments are raised by a significant portion of users, the BIP will likely be withdrawn or rejected, and the proposal process must be abandoned or restarted.
What do BIP numbers mean?
A BIP number gets assigned by the BIP editor. The current BIP editor is Bitcoin Core contributor and Bitcoin Knots maintainer Luke-Jr. Once a draft of a BIP meets some minimal criteria, it will be assigned a number.
The BIP submission must comply with some formatting requirements, and the proposal must be considered complete. The BIP editor can reserve specific ranges of numbers for recommendations around a common theme. But really, the numbering doesn’t matter.
Is a BIP binding?
No, BIPs are not binding as all software upgrades to bitcoin are conducted as soft forks, making them backwards compatible. Once a BIP is pushed live by a developer, it is up to those who agree with the update to run that new client on their nodes. Everyone decides which software they run on their computer and even which software and protocol they consider to be “Bitcoin.”
Nodes that recognise those new changes will then process those commands, while nodes that don’t run the new client can choose to ignore those commands.
Keep up to date with BIPs
If you’d like to check out the complete list of BIPs and their status, you can find them on GitHub
