The standard format for documents proposing changes to Bitcoin.
Bitcoin has no hierarchical or defined organisational structure. As a result, a generally agreed-upon standard for the introduction of new ideas to Bitcoin was required.
The first BIP was issued in 2011, 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. Before reaching this stage, BIPs go through a drafting or “triaging” process — beginning with a draft which is either proposed, rejected, withdrawn or deferred. 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.