BIP (Bitcoin Improvement Proposal)

Anna prepares a payment on her computer but wants to sign it with another manufacturer's hardware wallet. Both programs need to understand the information being exchanged. BIP 174 addresses precisely this problem: it describes PSBT, a shared format for passing an unfinished transaction and the information needed to sign it. Developers can follow one document instead of inventing incompatible formats independently. That is one practical reason BIPs exist. [8]

Different numbers represent different kinds of work. BIP39 describes generating recovery words and converting them into a seed, the starting data from which wallet keys can be derived. BIP 141 describes SegWit, a change to transaction-processing rules that took effect through network activation. BIP 174 helps wallets exchange transactions for signing without changing block validity. BIP 50 records the causes and resolution of the March 2013 incident that temporarily split the network. Not every BIP proposes a new Bitcoin rule. [6] [7] [8] [9]

Describing a solution, programming it and using it are separate steps. The description is a specification; the code is an implementation. A wallet might experiment with a draft, while another document may have no software in use at all. Changes to block-validity rules also involve activation, when the relevant software starts enforcing them. Publishing a document does not automatically update your node, the computer that checks network rules. [7] [10]

A number mainly helps you find the right document and join the same discussion. A higher number does not mean a better proposal or a recommended upgrade. A numbered document can remain unfinished or be set aside. When a service advertises support for a BIP, you still need to establish which feature it means and whether its particular software version actually provides it. [2]

Authors first investigate earlier work and discuss the idea on the Bitcoin Development Mailing List, a public email discussion for developers. Feedback may reveal a problem before a long document is written. A sufficiently developed proposal is then submitted to the shared bitcoin/bips repository on GitHub as a pull request—a request to include it. Authors do not choose their own number: an editor assigns it after checking the topic, format and readiness. [1]

BIP Editors look after published documents: they check prior discussion, clarity, formatting and licensing, assign numbers and maintain records. They do not thereby decide which software you should run or which rules your node should accept. A repository entry is no guarantee of safety or community agreement. Actual use depends on individual projects and network participants. [1]

If a headline says a BIP was approved, open the document and establish what actually happened. Was it merely assigned a number, did the authors finish their work, or are people already using it in an application? For a wallet feature, look at its documentation and releases; for a network rule change, also check activation conditions and progress. This separates an interesting proposal from a feature you can already use. [10] [2]

The current procedure is set out in BIP 3, Updated BIP Process, with status Deployed. It replaced BIP 2 and simplified document types and statuses. Older articles may therefore use labels such as Standards Track or Final that do not match today's categories. Refer to the current file and its repository history. The repository publishes and preserves proposals; it is not a voting system for Bitcoin's future. [1] [5]

Specification describes technical rules from which interoperable programs can be built. Before completion, it also requires a working reference implementation, a program demonstrating how to implement the design, and test vectors: sample inputs with expected results. Informational provides information, analysis or guidance. Process governs a way of working, such as publishing BIPs themselves. BIP 3 belongs to that last group; it does not specify a new Bitcoin transaction format. [1]

Draft is work in progress. Complete means the authors have finished their planned work and recommend adoption. Deployed indicates demonstrated active use; for a Process BIP it may reflect the required rough consensus, broad agreement following discussion and resolution of substantive objections rather than a simple vote count. Closed is historical material no longer actively developed, promoted or used. It stays in the archive. Even Deployed does not mean every wallet supports the proposal. [1]

The header records authors, type, status, assignment date, license and discussion links. Requires lists other BIPs needed, Replaces identifies proposals the document aims to supersede, and Proposed-Replacement points to a possible successor. After a document reaches Complete, further changes are recorded in a Changelog with a date and version number. The Version field in the header identifies the current document version. A change incompatible with the existing design should generally get a new BIP, so an unchanged number does not quietly come to mean something else. [1]