The power of consensus displayed in decentralization
The introduction of Bitcoin as the world’s first cryptocurrency caught the imagination of the world in many countless ways as to how digital money could really work. Many other proponents came out with their own version of virtual coins and tokens with different purposes and uses. Those who remained loyal to Nakamoto’s brainchild have found it not that too perfect to be reluctant to change, or changes, for that matter.
And so came what was to be called the Bitcoin Improvement Proposal, or BIP, a set standard for those proposing alterations to the Bitcoin protocol, changes to the process, or source of information for the Bitcoin community. BIPs may contain soft fork or hard fork upgrade proposals, peer-to-peer layer changes, or new back-up mnemonic seed frameworks. Yet, not all proposals require a BIP, with simple changes such as a code run or changes in an interface.
The first Bitcoin Improvement Proposal was first introduced by an early crypto developer named Amir Taaki, the widely credited creator of the world’s first alternative implementation of the Bitcoin protocol — Libbitcoin. Taaki believes that if BIPs are used the right way, Bitcoin would be more structured and accountable, benefitting the entire Bitcoin ecosystem.
Taaki’s BIP is known to the Bitcoin community as BIP 0001 submitted on August 19, 2011. The document put forth the standard of how a BIP process should be conducted. Taaki based it on the process used to improve a famed digital programming language called Python, as described in the Python Enhancement Proposal, or PEP 0.
All BIPs were first drafted and then submitted by an individual or several authors. Usually, before it even gets drafted, it was already a topic of discussion on the Internet relay chat channels (IRC), Bitcoin development mailing list, and others. Community feedback is important in drafting the proposal as it undergoes changes. Drafts may be accepted, deferred, rejected, or withdrawn. If BIPs touch on the changes affecting the Bitcoin protocol, it requires a coded reference implementation. Once the BIP achieves a community consensus, only then will it be considered final. The developers will then implement the code of the adopted BIP and users may also opt to download and run the code. BIPs, however, are not binding. While developers get to decide on what code to implement, users, too, will decide for themselves which software and protocol they want to run on their computers. Thus, any legal action that may crop up based on BIPs will not stand in any court of law.
1. Standards Track BIPs
Any proposal that sought changes to the Bitcoin protocol is called a Standard Track BIP, including block data, or altering the process of validating transactions within the ecosystem. It can also cover the attempt to change the interoperable functions between two BIPs. This attempt needs consensus before it becomes operational. BIP 91 can best represent this type.
2. Informational BIPs
This type of BIP focuses on general guidelines, design issues, and other information that does not seek too much attention from the Bitcoin community in general. An example of this would be BIP 32.
3. Process BIPs
This type involves proposals that are seeking to improve changes in the core processes running the Bitcoin ecosystem. It is similar to Standard Track BIPs as they need a consensus vote for a major change to be implemented. BIP 2 comes to mind in this type.
1.Segwit or Segregated Witness
BIP 141 was proposed in 2015 by two developers from the Bitcoin Core project. It proposed to increase the scalability of Bitcoin including solutions to issues of transaction throughput.
The upgrade came into effect through a soft fork that needed the vote of over 95% of Bitcoin miners for a fixed duration of 14 days. SegWit was a scaling solution to allow more transactions within a single block.
James Hilliard submitted this soft fork proposal in 2017 seeking to activate the current SegWit solution with a less than 95% hash power majority.
3.BIP 148 (UASF)
In 2017, the pseudonymous Shaolin Fry thought of BIP 148 as a user-activated soft-fork SegWit solution to scale up Bitcoin’s total Tx capacity. The requirement of BIP148 is 50 plus percent BTCs full node users to be able to upgrade their software. As of now, it has not achieved a 50% consensus vote.
This BIP combines two scaling solutions involving SegWit and a 2MB increase in block size. It proposes to implement SegWit first. Within three months after SegWit, a 2MB block size implementation will follow. After a strong support from the community, it was deemed an attack on the network itself over technicalities that led to its cancellation.
5.The Lightning Network
Joseph Poon and Thaddeus Dryja conceived this BIP in 2015 to make Bitcoin’s Tx framework increase in scalability by allowing instant payments off-chain. Micropayments will be created to allow money transfers without the risk associated with counterparty theft. Multi-signature wallets are utilized to accommodate unlimited transactions without storing the data in the Bitcoin Blockchain. The only data recorded on the Blockchain is the volume of BTC still available on the associated wallet and the contribution percentage of each of the involved parties. The Lightning Network also allows cross-chain payments and the use of smart contracts.
The Bitcoin Improvement Proposal is a classic way of presenting decentralization to the masses by throwing to them the freedom of suggesting and proposing improvements to a current decentralized finance project for the overall benefit of the community. The consensus it requires is an example of how the Bitcoin community works when ideas stem from the ground up. With a brilliant proposal, anybody can earn the right to be heard, supported, and accepted.