Bitcoin Improvement Proposals: how ideas become Bitcoin, and why a BIP is not a law

A BIP is a written proposal with a number, so everyone argues about the same text

Bitcoin has no company, no board and no version that is official by decree. What it has instead is a habit: when someone wants to change how it works, they write it down. A Bitcoin Improvement Proposal is that document. BIP 1, BIP 2 and BIP 3 all define it the same way, as “a design document providing information to the Bitcoin community, or describing a new feature for Bitcoin or its processes or environment.” It is expected to state the motivation, give a specification precise enough that someone else could implement it, and address compatibility with what already exists.

The number is the useful part. Once a proposal is BIP 141, every developer, wallet author and forum argument can point at the same text. BIPs are kept in a public repository on GitHub, at bitcoin/bips, where anyone can read the full list, the status of each and the history of every edit.

A BIP is not code. Some come with a reference implementation, and many describe changes that were later written into Bitcoin Core and other software, but the document and the software are different things, and the existence of one does not guarantee the other.

It started with BIP 1 in 2011, written by Amir Taaki

The first BIP is about BIPs. BIP 1, “BIP Purpose and Guidelines,” is dated 19 September 2011 and was written by Amir Taaki, a developer active in the early community. It set out the idea, the three kinds of proposal, and a workflow: float the idea on the bitcoin-dev mailing list first to see whether anyone cares, then submit a draft in the standard format. A BIP editor assigns the number; authors cannot pick their own. BIP 1 named Luke Dashjr as the editor.

Four and a half years later, Dashjr revised the process in BIP 2, dated 3 February 2016. It added a longer list of statuses, a public comments page for each BIP, licensing requirements, and, most usefully, a definition of what counts as a proposal being accepted, which differs by kind of change. In January 2025 a further revision, BIP 3 by the editor known as Murch, simplified the statuses again and dropped the comments system. The repository index now marks BIP 1 and BIP 2 as Closed, and BIP 3 is the process in force.

Three kinds: specification, informational and process

A specification BIP, called Standards Track in BIP 1 and BIP 2, describes a change that affects most Bitcoin software: a network protocol change, a change to what makes a block or transaction valid, or anything that touches interoperability. These are the ones that can become soft forks or hard forks, and they carry the highest bar.

An informational BIP describes a design issue or offers guidelines without proposing a new feature. BIP 2 is explicit that these “do not necessarily represent a Bitcoin community consensus”; they are recommendations that users are free to ignore. A process BIP describes how Bitcoin development itself is done. BIP 1, 2 and 3 are process BIPs, and BIP 3 declares process BIPs to be living documents that may be amended indefinitely.

BIP 2 adds a second axis: where in the system a specification lands. A change to what blocks are valid, a change to how nodes talk to each other, a change to the interface software uses to ask a node questions, and a wallet or application standard are all specifications, but they reach very different numbers of people, and BIP 2 sets a different test of adoption for each.

How a proposal moves: draft, complete, deployed, closed

Under BIP 3, a proposal starts as a Draft once an editor has assigned a number and merged it. When the authors consider it finished, it becomes Complete. When there is evidence that it is actually in use, it becomes Deployed. When it is abandoned, withdrawn or superseded, it is Closed. Those four replace BIP 2’s nine, which included Proposed, Final, Active, Deferred, Rejected, Withdrawn, Replaced and Obsolete.

The editors’ job is narrow on purpose. Under BIP 3 they assign numbers, check formatting and scope, and make strictly editorial corrections. They do not “evaluate whether the proposal is likely to be adopted.” BIP 2 put it another way: the process “can only hope to achieve accuracy in regard to the Status field by striving to reflect the reality of how things actually are, rather than how they should be.” Status is a record of what happened, not a ruling.

The repository README says the same in plain words. Publication “does not indicate that it is a good idea, has community consensus, or that it is about to be adopted.” It means the proposal is on topic and properly written. The number is a bookmark, not a blessing.

Famous BIPs you have probably used without knowing

BIP 16, Pay to Script Hash, by Gavin Andresen and dated January 2012, is why multisignature addresses work in ordinary wallets. BIP 32, Hierarchical Deterministic Wallets, by Pieter Wuille and dated February 2012, lets one secret seed generate an entire tree of keys, so you back up one thing instead of every address. BIP 39, by Marek Palatinus, Pavol Rusnak, Aaron Voisine and Sean Bowe, dated September 2013, turns that seed into the 12 to 24 English words you are told to write down when you set up a wallet. Our article on keys and seed phrases explains what those words actually encode.

BIP 141, Segregated Witness, dated December 2015, and BIP 341, Taproot, are the two consensus changes most people have heard of, and both are explained in their own articles: SegWit and Taproot. BIP 9 defined the version-bits signaling that miners used to coordinate SegWit’s activation. And the numbers keep going: the repository’s index runs past 340.

A BIP is a proposal. Adoption is a choice made by the people running the software

BIP 3 states it flatly: “Individual BIPs do not represent Bitcoin community consensus,” and “BIPs do not define what Bitcoin is.” The repository does not track sentiment or decide adoption. What decides adoption is whether wallet developers implement a standard, whether node operators run software that enforces a rule, and whether miners build blocks that follow it.

BIP 2 wrote down what that looks like for each kind of change. A soft fork counts as accepted when a “clear miner majority expressed by blockchain voting” has adopted it. A hard fork needs “adoption from the entire Bitcoin economy, particularly including those selling desirable goods and services in exchange for bitcoin payments.” A change to how nodes talk to each other needs at least 1 percent of public listening nodes for a month. An interface or application standard needs two independent, compatible implementations. None of those thresholds is a vote that anyone can call; each is a description of the world after people have chosen.

That is why the difference between soft forks and hard forks matters so much, and why the block size war was fought over activation rather than over text. Writing a BIP is easy. Getting the network to run it is the entire problem.

Read a BIP as a proposal with a separate adoption path

Use the number to find the exact document, then check its type, status, motivation and specification. The archive’s editorial process makes proposals discussable and discoverable; it does not give the editors authority to make users adopt them.

The next question depends on the proposal’s scope. A wallet convention needs support from the relevant wallet implementations, while a consensus change needs an activation and enforcement path. Do not infer either from a low BIP number, a merged document, or a familiar author name.