Bitcoin Improvement Proposals
Bitcoin Improvement Proposal (BIP) is a design document for introducing features or information to Bitcoin. The BIP should provide a concise technical specification of the attribute and a rationale for the feature. 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.
Types of BIPs
There are three major types of BIPs:
- Standards Track BIPs – Such types of BIPs entail making changes to the network protocol, block, or transaction validation method. It also intends to affect the interoperability of the two versions of BIPs or Bitcoin. This type of BIP certainly requires community consensus. An example of this is BIP 91.
- Informational BIPs – Such types of BIPs highlight the design issues, general guidelines, and supporting information. Informational BIPs, as the name suggests, are just for information’s sake and can be taken seriously or ignored by the community. An example of this is BIP 32.
- Process BIPs – These types of BIPs describe or propose a change in the process. They are similar to Standards Track BIPs and require community consensus. They can’t be ignored, but unlike Standards Track BIPs, they intend to be applied outside the Bitcoin protocol. An example of this is BIP 2.
BIP Life Cycle
According to the type of BIP it is, it may require community consensus. But even before this consensus, when any of the above types of BIPs are submitted, they go through various statuses such as – drafted, verified, accepted, and rejected or replaced.
Shown below is a BIP life cycle in which typical paths of the statuses of a BIP are shown:
There were the corrections in terms of protection against DoS-attacks (Denial of service "denial of service"), to the villains was harder to attack the nodes and to prevent the dissemination and verification of transactions. Another recent improvement is the implementation of IP 70 (BIP — Bitcoin Improvement Proposal, proposal to change something in the client or Protocol). This is a more cunning and secure method of payment on the Internet than just sending to the address. In fact, an optional add-on over the current Protocol, which allows you to verify the identity of the seller and pass the user's wallet additional information about the order.
There are more corrections:
|BIP 0001||Fix formatting||Oct 21, 2013|
|BIP 0002||Add obsolete status to process image||May 1, 2017|
|BIP 0008||Amend BIP8 by height||Jul 7, 2017|
|BIP 0009||Update status for segwit related BIPs||Sep 17, 2017|
|bip-0016||Archive Revision as of 19:50, 9 March 2012||Oct 21, 2013|
|bip-0032||Fix formatting||Oct 21, 2013|
|bip-0039||Add Korean wordlist||Aug 10, 2017|
|bip-0042||Include image for BIP42||Apr 2, 2014|
|bip-0047||BIP-0047: Reusable payment codes||Jul 10, 2015|
|bip-0068||Improve title, add encoding diagram and small fixup||Nov 23, 2015|
|bip-0069||add EOF newlines per @luke-jr||Sep 19, 2015|
|bip-0070||Put BIP 75 in the right place in README, and clean up formatting a bit||Mar 17, 2016|
|bip-0073||Fix formatting||Oct 21, 2013|
|bip-0075||- Update identifier comment in paymentrequest.proto||Nov 28, 2016|
|bip-0098||BIP-0098: Fast Merkle Trees||Nov 16, 2017|
|bip-0114||BIP114: MAST proposal v2||Jul 28, 2016|
|bip-0122||Assign BIP 122||Jan 8, 2016|
|bip-0135||Assign BIP 135: Generalized version bits voting||May 7, 2017|
|bip-0144||BIP141: commitment clarification. BIP144: new diagram||Apr 8, 2016|
|bip-0152||header message can also get replied by getdata (CMPCT_BLOCK)||Jun 19, 2016|
|bip-0174||Specify the Partially Signed Bitcoin Transaction format in a BIP||Sep 18, 2017|
|scripts||scripts/buildtable: Support License-Code header||Oct 29, 2017|