As the name seems to clearly suggest, a Bitcoin Improvement Proposal (BIP) is a standard that has been devised to help in the alteration of BTCs core protocol. However, in a few notable cases BIPs have even served as a source for crucial information for the Bitcoin community at large.
From a more technical standpoint, we can see that the aforementioned proposals seek to facilitate certain consensus-based critical changes (such as soft and hard forks) as well as usher in other modifications related to Bitcoin’s peer-to-peer layer and seed framework. With that being said, it needs to be made abundantly clear that not every change made via a Bitcoin software implementation has a direct effect on the core BTC protocol. In this regard, we can see that certain changes that are routinely put forth by independent developers do not require a BIP to be accepted by the community at large.
When looking at the back story of how the first Bitcoin Improvement Proposal (BIP) came to be, we can see that the first such proposal was introduced by an early crypto dev named Amir Taaki, who is widely credited as being the creator of the world’s first alternative implementation of the Bitcoin protocol — Libbitcoin.
According to a blog released by Taaki around a decade back, he made it abundantly clear that BIPs, if used correctly, has the potential to greatly benefit the overall development of Bitcoin (by making the cryptocurrency’s native ecosystem more structured and accountable.)
Not only that, as per data available online, we can see that Taaki submitted the first BIP (referred to as BIP 0001) to the Bitcoin community sometime during mid-2011. The document essentially highlighted how the entire process surrounding BIPs should be conducted and was largely inspired by the process that is currently used to improve the nitty-gritty associated with a famous digital programming language called Python (as described in PEP0).
How are BIPs vetted?
As with any proposal, a BIP starts off as a basic draft that is submitted by one or more authors. Also, prior to its submission, a BIP is discussed at length informally across a host of BTC-oriented mailing lists, Internet Relay Chat (IRC) channels, etc. Also, during its lifetime as a draft, a BIP can be modified and changed by its authors (based on community feedback) any number of times.
Also, in the case of a Bitcoin protocol change, a code-based reference implementation is necessary. Lastly, it goes without saying that a proposal is only considered final if it reaches community consensus.
Key topics worth exploring
As the name sort of alludes to, a BIP number can be thought of as a catalog code that is assigned to a proposal as per the wishes of the designated BIP editor after the draft has fulfilled a majority of the criteria (such as formatting) set forth by the global BTC community.
The BIP editor reserves a number of special rights:
When it comes to improvement proposals, the appointed BIP editor has the power to reserve certain groups of numbers for proposals that share a common link.
BIPs are non-binding:
A core aspect of BIPs worth pointing out is that they are not binding and thus legal action based on them cannot be upheld in a court of law.
What are the different types of BIPs that exist today?
In all, there exist a total of three major types of Bitcoin Improvement Proposals — namely Standards Track BIPs; Informational BIPs and Process BIPs. In this section, we will describe each of these concepts in brief:
(i) Standards Track BIPs:
These are proposals that seek to make changes to the BTC network protocol, block data or even the way in which the ecosystem validates its native transactions. Additionally, Standards Track BIPs also look to change the interoperability of two versions of BIPs and require community consensus to come into effect. A perfect illustration of such a proposal is BIP 91.
(ii) Informational BIPs:
As the name suggests, Informational BIPs are aimed at highlighting various design issues, general guidelines, and other similar data that does not have to be taken seriously by the community at large. BIP 32 is a direct representation of such a proposal.
(iii) Process BIPs:
These kinds of improvement proposals seek to implement a change in the core processes underlying the Bitcoin ecosystem. In their most basic sense, Process BIPs can somewhat be compared to Standards Track BIPs since they entail major changes that need to be vetted through a consensus vote. An example that perfectly fits into this category is BIP 2.
BIP Life Cycle
Depending upon the kind of BIP that needs to be passed, it may or may not require community consensus. However, before things reach such a stage, the submitted proposal has to go through a number of phases such as:
- Community Acceptance
- Acceptance/Rejections or Amendments.
Famous BIP Examples
1. BIP 141
BIP 141 (better known as SegWit or Segregated Witness) was a proposal that was introduced all the way back in 2015 by a couple of developers who at the time were working on the Bitcoin Core project. As many of our readers may already be aware of, BIP 141 seeks to increase BTCs native network scalability as well as solve many of the issues related to the currency’s transaction throughput. Additionally, it should be pointed out that the proposal was brought into effect via a soft fork which required over 95% of the network’s miners to signal for the upgrade over a fixed period of 14 days.
In layman’s terms, one can think of Segregated Witness (aka SegWit) as being a blockchain scaling solution that allows for more transactions to take place within a single BTC block.
2. BIP 91
Quite similar to BIP 141, BIP 91 was also a soft fork proposal that was brought forth by Bitmain’s James Hilliard back in mid-2017. The goal of BIP 91 was to activate the existing SegWit solution (i.e. BIP 141) with a hash power majority of less than 95%.
3. BIP 148
BIP 148 is a user-activated soft-fork SegWit solution that was introduced during the first quarter of 2017 by an individual who goes by the pseudonym ‘Shaolin Fry’. Simply put, the proposal provides the global crypto community with a unique way in which to scale up Bitcoin’s total Tx capacity. Additionally, it bears mentioning that at the time of its deployment, BIP 148 required 50+% BTCs full node users to upgrade their software.
4. Lightning Network
The BIP associated with the Lightning Network was conceived back in 2015 by Joseph Poon and Thaddeus Dryja. The protocol makes BTC’s tx framework more scalable by allowing for instant payments to take place off-chain. This is primarily achieved through the creation of micropayment channels that allow for money transfers to go through without the risk of any counterparty thefts.
From a technical standpoint, we can see that the utility of LN is made possible through the introduction of multi-signature wallets that allow for an infinite number of transactions to take place without there being any need to store the associated data on the native BTC blockchain. The only data that is recorded onto the blockchain is the total volume of BTC that is available in the associated wallet as well as the contribution percentages of the involved parties.
Lastly, in addition to enabling instant transactions, the Lightning Network also helps in the enabling of cross-chain payments as well as smart contract utilization.
Merkelized Abstract Syntax Trees (or MAST as they are commonly known as) is a cryptographic tool that allows for complicated data sets to be merged into BTC tx’s in a highly streamlined manner. This allows for the total amount of data to be added to the blockchain to be greatly reduced. Technically, we can see that M.A.S.T. is an amalgamation of two separate tools — namely Merkle Trees and Abstract Syntax Trees. For those of our readers who may not be aware, Merkle trees can be thought of as algorithmic structures that allow for data to be recorded without the need for it to be downloaded. Similarly, Abstract Syntax Trees allow for complex data sets to be added to a blockchain while bringing down the total amount of data (that has been recognized as being part of a particular transaction) associated with the tx.
In this regard, there are three BIPs that seek to implement M.A.S.T. into the Bitcoin network. These include:
This proposal was submitted by BTC Core dev Johnson Lau with the aim of increasing Bitcoin’s native security levels by introducing a new merkelized script into the currency’s ecosystem. Additionally, BIP 114 seeks to greatly reduce the need for large amounts of transaction data while maintaining user privacy at all times.
BIP 116 was proposed by Bitcoin Core developer Mark Friedenbach as a means of allowing native BTC data to be confirmed without there being any need of disclosing the entire data set associated with the tx.
Also referred to as Tail Call Semantics, BIP 117 is a proposal which when used in conjunction with BIP 116 aims to generalize the core concepts underlying M.A.S.T. while providing full support for native SegWit addresses.
The deployment of M.A.S.T allows for a number of benefits such as:
- Enhanced privacy
- Faster transaction speeds
- Inclusion of complex data (example: smart contracts)
- Increased scalability as well as overall tx volume.
6. Confidential Transactions
As the name clearly suggests, the BIP concerned with Confidential Transactions seeks to usher in a new level of privacy for the data contained within the Bitcoin network. The proposal was submitted by a well-respected blockchain developer by the name of Gregory Maxwell. It will allow bitcoin users to gain access to a host of privacy-related benefits — much like what other privacy-centric coins such as Monero (XMR) and Zcash (ZEC) currently offer their users.
Dandelion is an important BIP that seeks to redesign BTCs core network stack so as to make the premier cryptocurrency more anonymous as well as reduce many of the vulnerabilities that are currently associated with the disclosure of BTCs tx identities. Some of the core benefits of Dandelion include:
- Increased difficulty in confirming the origin of a particular transaction
- Reduced risks of third-party intrusions
- Lowered possibility of miscreants linking BTC Txs with their source IP
8. Numerifides Trust Consensus Protocol
This is another proposal that delineates the creation of a network that is secure, decentralized and features human-readable names. It was submitted by Taylor Hawkins who in a GitHub draft mentioned the following:
“Rather than deriving justice and authority from a system that’s not supposed to look but too often does, I propose a DECENTRALIZED CONSENSUS PROTOCOL that enables a system of decentralized authority on a public piece of data, on an open blockchain and any independent, skeptical user or actor operating the consensus protocol can verify any other actor’s statement of authority in a decentralized, fair and privacy-protective manner.”
Other core facets of this BIP include:
- It allows users to establish their aliases which they wish to transact on the network.
- In order for this proposal to work, users are required to lock up a certain amount of Bitcoin as well as provide a PoW confirmation for the same.
Despite Bitcoin Improvement Proposals receiving a lot of flak over the years, we need to admit that their importance, at least as far as redefining the Bitcoin ecosystem goes, has been nothing short of monumental. And while a large number of people believe that regular BIPs can lead to more forks in the BTC network, we need to bear in mind that these changes can only be implemented through community consensus.
To keep track of BIPs, crypto enthusiasts can either choose to visit technical digital currency/blockchain portals such as GitHub — which is widely considered by many to be the largest repository of all things crypto. Alternatively, people can also follow crypto news related to this space through a number of different websites such as Bitcoinexchangeguide, Coindesk, Cointelegraph, etc.