Bitcoin Improvement Proposal (BIP) and voting is part of Bitcoin’s system where anyone in the developer community can make a proposal and miners vote on it. We determine voting power by the hash power a miner has on the network, and proposals fall under three primary categories. We call the infrastructure used for voting Bitcoin Improvement Proposal (BIP).
A Bitcoin Improvement Proposal (BIP) is a design document for introducing features or information to Bitcoin. This is the standard way of communicating ideas since Bitcoin has no formal structure.
The first BIP (BIP 0001) was submitted by Amir Taaki on 2011-08-19 and described what a BIP is.
There are Three Types of BIPs:
Standards Track BIPs
This kind of BIP applies to changes in the network protocol, block, transaction validation method, or anything affecting interoperability (the ability of the system to exchange and make use of information). In order to implement BIPs, we require community consensus.
Design issues, general guidelines, and supporting information. This type of BIP is NOT for proposing new features and does not represent community consensus. These BIPs are purely for informational purposes and may or may not be taken seriously by the Bitcoin community.
Describes or proposes a change in process. These BIPs are in many ways similar to Standards Track BIPs but apply outside the Bitcoin protocol. Process BIPs require community consensus and must be taken seriously by the community.
Depending on the kind of BIP, it may require community consensus. However, even before it reaches the point of needing consensus, there is a framework the BIP must follow once it is submitted. We assign the BIPs various statuses such as drafted, verified, accepted, rejected, or replaced.
Below are two examples of a typical BIP Lifecycle:
Anyone can make and submit a proposal, these proposals make their way through the community, and once one is implemented, it can be voted on by Miners. The Voting will conclude after ‘N’ blocks set by the developer. Miners include a piece of code in their transactions (where new bitcoins are generated) within the specified time set by the developer.
For Example: N = 100.
For 100 blocks, a miner will include its yes or no, number of votes is proportional to the percentage of the hashing power of the network. If you have 20%, you’ll likely be able to vote approx 20 times. Developers make a proposal and miners vote on it. If the majority vote yes, the miners implement the code. Majority in this case is when over 55% of the miners vote for a specific change.
BIPs and this kind of infrastructure for cryptocurrencies in general, has sparked some interesting debates within the community. Some developers fear miners will vote based on vested interest rather than the good of the network.
Additionally there is a growing fear in the community towards the concentration of hashpower (which translates into voting power) as mining pools and big scale mining operations continue to grow. This system is still relatively new, so it will be interesting to see how BIPs progress and ultimately how they affect the development of other cryptos as a result of its successes and failures.