What Is a Bitcoin Improvement Proposal? Bitcoin, as an open-source, decentralized cryptocurrency, has no hierarchical or defined organizational structure. As a result, a generally agreed-upon standard for the introduction of new ideas and development to Bitcoin was required. The first BIP was issued in 2011 by British-Iranian programmer Amir Taaki, 2 years after Bitcoin was created, setting out the format of the BIP itself, and taking inspiration from the system of proposals for changes to the Python language. Every BIP is publicly available on GitHub. Bitcoin Improvement Proposals normally fall into one of three categories: Standards Track, Informational, and Process. Standards Track BIPs relate to changes to the protocol or validation methods. Informational BIPs are for educational purposes, or for raising awareness. Process BIPs relate to proposed process changes outside the Bitcoin protocol. Informational BIPs can be accepted or ignored by the Bitcoin community as it wishes. Standards Track and Process BIPs, however, require community consensus and must be considered. As an open-source project, anyone with the desire or skill can submit a BIP. Before becoming a formal BIP, BIPs go through a drafting or “triaging” process — beginning with a draft sent to the [email protected] mailing list. The proposed BIP will either be proposed, rejected, withdrawn or deferred. If given the go-ahead, it will be published as a draft to the Bitcoin Core GitHub repository of BIPs, where the community can review and work on transparently. The active stage comes next, followed by obsolescence or replacement. Most BIPs begin life through discussions on listservs or other communities. BIPs might relate to critical decisions such as hard and soft forks. For example, BIP 141, also known as SegWit, proposed a soft fork intended to increase network capacity. Fork proposals require a 95% majority among miners. Crucially, BIPs cannot be enforced. Even if community consensus is reached on a change laid out in a BIP, each developer makes their own choice regarding which codebase they use. Further, there is no way or desire to dictate which version of the code is used by individual Bitcoin users. Many changes — such as modifications to the user interface — require no BIP at all. What Is a Bitcoin Improvement Proposal? Bitcoin, as an open-source, decentralized cryptocurrency, has no hierarchical or defined organizational structure. As a result, a generally agreed-upon standard for the introduction of new ideas and development to Bitcoin was required. The first BIP was issued in 2011 by British-Iranian programmer Amir Taaki, 2 years after Bitcoin was created, setting out the format of the BIP itself, and taking inspiration from the system of proposals for changes to the Python language. Every BIP is publicly available on GitHub. Bitcoin Improvement Proposals normally fall into one of three categories: Standards Track, Informational, and Process. Standards Track BIPs relate to changes to the protocol or validation methods. Informational BIPs are for educational purposes, or for raising awareness. Process BIPs relate to proposed process changes outside the Bitcoin protocol. Informational BIPs can be accepted or ignored by the Bitcoin community as it wishes. Standards Track and Process BIPs, however, require community consensus and must be considered. As an open-source project, anyone with the desire or skill can submit a BIP. Before becoming a formal BIP, BIPs go through a drafting or “triaging” process — beginning with a draft sent to the [email protected] mailing list. The proposed BIP will either be proposed, rejected, withdrawn or deferred. If given the go-ahead, it will be published as a draft to the Bitcoin Core GitHub repository of BIPs, where the community can review and work on transparently. The active stage comes next, followed by obsolescence or replacement. Most BIPs begin life through discussions on listservs or other communities. BIPs might relate to critical decisions such as hard and soft forks. For example, BIP 141, also known as SegWit, proposed a soft fork intended to increase network capacity. Fork proposals require a 95% majority among miners. Crucially, BIPs cannot be enforced. Even if community consensus is reached on a change laid out in a BIP, each developer makes their own choice regarding which codebase they use. Further, there is no way or desire to dictate which version of the code is used by individual Bitcoin users. Many changes — such as modifications to the user interface — require no BIP at all.
No Comment! Be the first one.