As the first decentralized currency, Bitcoin is designed as open-source software. Therefore, the actual Bitcoin program can be updated and changed. Anyone can propose changes or new ideas as long as they are generally agreed upon by the Bitcoin developer community. However, to propose these changes, a mutually agreed standard is needed, this standard is called the Bitcoin Improvement Proposal (BIP). How does BIP work and what are some examples of BIP that have been implemented? We will discuss this further in this article.
Before the Bitcoin software is updated, the developer must first submit a Bitcoin Improvement Proposal (BIP). This proposal is a formal method for changing, improving, or improving the Bitcoin protocol.
As part of the software, Bitcoin needs to be improved over time such as bugs that need to be fixed, algorithms can be made more efficient, code simplified, maintain compatibility with other software and add new features.
The BIP process takes place without a central leader. The BIP process allows bitcoin to remain transparent and maintain its reputation as a secure and decentralized open network.
The BIP process was first developed and introduced 2 years after bitcoin was launched, by early Bitcoin developer Amir Taaki. The BIP process is heavily based on the Python programming language improvement process which is also described in Python Enhancement Proposal 0 (PEP 0). Amir Taaki handed over the first BIP (BIP 001) On 19 August 2011.
The bitcoin program is open, if you donβt believe it, just take a look at this Bitcoin Github. Because bitcoin is open, there is actually no limit to making a BIP. Anyone can make a BIP without any discrimination.
The BIP process from draft to active is part of Bitcoin Core.
Typically, a BIP is initiated as an informal proposal via a Bitcoin mailing list network or other types of communication channels, such as IRC or Slack. Developers can email their ideas to the mailing list, and anyone interested will respond to the BIP.
Some ideas remain at this stage of discussion for years because they will inevitably have pros and cons, or may still require adjustment. In some cases, BIP mostly hangs because the community is not ready for the proposed changes.
Once the proposal is adjusted, and all the pros and cons have been evaluated, the BIP can be submitted to the BIP list, assigned a BIP number, and published to the Bitcoin Core GitHub repository from BIP.
At this point, the BIP has been officially created, but not necessarily approved or implemented in Bitcoin Core. Anyone can then review the BIP and provide feedback as it is being worked on and, occasionally, will be tested on the testnet first.
Each BIP begins as a draft submitted by one or more authors who have ideas for improvements to the Bitcoin protocol. The draft was submitted to BIP GitHub and was worked on openly for everyone to see. BIP can be changed and improved by the author based on community input and feedback during the testing period.
In the case of a Bitcoin protocol change, it is also necessary to implement a reference in the code. If the proposal reaches consensus by all parts of the bitcoin network (miners, users, and nodes) then the changes will be considered final.
Adoption occurs when a developer applies the codes that reflect the BIP to one of the node software clients, and the user chooses to download and run this code.
Or, if there is any opposition from the majority of the users then, the BIP may be withdrawn or rejected, and the proposal process can be started all over again.
No, BIP is non-binding as all software changes to bitcoin are done as a soft fork, (Also read: What is a fork?) which makes it backward compatible. Once the BIP is executed, itβs then up to those who agreed to the update to run the new program with the changes on their nodes. Everyone can decide which software they run on their computer and even which software and protocols they consider βBitcoin.β
Nodes that recognize the new change will then process the command, whereas nodes that are not running the new client can choose to ignore the command.
You can view all BIPs that have been authorized and BIPs that have been submitted via the following Github link. Here are some examples of BIPs that have been implemented that you may be familiar with:
Share