Bitcoin Improvement Proposal

BIPs are how bitcoin writes things down. Anyone can submit one, an editor assigns the number, and the repository now holds several hundred of them in states from Draft to Final to Withdrawn. The numbers leak into products you use: the 12 words your wallet generated are BIP39, and the address it derived came from BIP84 or BIP86.

How it works

The BIP process is a filing system rather than a governing body.

It was borrowed from Python. Amir Taaki wrote BIP-1 in 2011, modelled on that project's enhancement proposals, and Luke Dashjr replaced it with BIP-2 in 2016 to tighten the definitions of what each status means and what evidence is needed to advance. The pipeline is unglamorous: float the idea publicly, absorb the criticism, open a pull request against the bitcoin/bips repository, and wait for an editor to check the formatting and hand out a number.

Proposals come in three types. Standards Track documents cover anything affecting how software interoperates, from consensus rules down to address formats. Informational documents record a design or a convention without asking anyone to do anything. Process documents describe the process itself. Each carries a status, moving through Draft and Proposed toward Final or Active, and plenty of them end at Withdrawn, Rejected, or Replaced instead.

What the number does not confer is authority. An assigned BIP is an index entry, not an approval, and there is no body that could approve it anyway. Adoption happens separately and voluntarily: somebody writes the code, reviewers pick it apart, an implementation ships it, and users choose to run that version. A great many changes to Bitcoin Core have no BIP at all, and a great many BIPs have never been implemented by anyone.

Why this matters when you buy bitcoin

BIP numbers appear in wallet menus, and choosing the wrong one is a common way to conclude your coins have disappeared.

The example that catches people is seed phrase recovery. BIP39 standardised the word list, 2048 entries, and the rule for turning 12 or 24 of them into a master key, which is why a phrase written down from one brand can be typed into another. What BIP39 does not standardise is where the wallet looks for your coins. BIP44 derives legacy addresses beginning with 1, BIP49 derives nested SegWit addresses beginning with 3, BIP84 derives native SegWit addresses beginning with bc1q, and BIP86 derives Taproot addresses beginning with bc1p. Restore a phrase into software defaulting to a different path and the balance reads zero while the coins sit untouched under the path you actually used. Write the derivation path on the same card as your backup and the problem never occurs.

Address formats have the same practical edge. Bech32 came from BIP173 and bech32m from BIP350, and support arrived at different times across the industry, which is why some platforms could not send to a bc1p address for a long stretch after Taproot activated. Before a large withdrawal, send a small amount first and confirm the destination format is accepted. Stuck transactions have a number too: fee bumping through replace-by-fee was specified in BIP125, and a wallet that implements it saves you from waiting out a badly timed fee estimate.

Treat the number as a label, not a warranty. BIP70, the payment protocol, was implemented by BitPay and Coinbase and looked like the future of merchant payments; Bitcoin Core deprecated it in version 0.19 and removed it in 0.20, and today nothing uses it. A BIP records that somebody thought carefully. Whether anyone still runs it is a separate question worth asking.

From BIP340 to block 709,632: how a proposal becomes a rule

Taproot is the cleanest illustration of the whole pipeline, because every stage of it is dated.

The design was published as three linked documents, BIP340 for Schnorr signatures, BIP341 for the Taproot output type, and BIP342 for the new script rules, written by Pieter Wuille with Jonas Nick, Tim Ruffing, and Anthony Towns. They were merged into the repository in January 2020 after roughly two years of public discussion. Merging changed nothing about bitcoin: it meant the documents had numbers.

Implementation and review then took most of a year, and the argument about how to activate the rules took several months more, with two competing mechanisms on the table. The compromise, known as Speedy Trial, shipped in Bitcoin Core 0.21.1 in May 2021. Miners signalled readiness through a defined window, lock in was reached on June 12, 2021, and the rules became enforceable at block 709,632 on November 14, 2021. That is roughly 22 months from a numbered document to an enforced rule, and the document did none of the work: node operators running the code did.

Bitcoin Improvement Proposal vs consensus rules

A Bitcoin Improvement Proposal is paperwork; consensus rules are what nodes actually enforce. The two overlap only when a proposal has been implemented and adopted, and the gap in each direction is instructive. BIP70 has a number and enforces nothing anywhere. The 21 million supply cap has no BIP at all, because it predates the process and lives purely in code. When you want to know what bitcoin does, read the software or the rules it enforces; when you want to know what somebody proposed, read the BIP.

Bitcoin Improvement Proposal vs soft fork

A Bitcoin Improvement Proposal is a document; a soft fork is a deployment event that tightens the rules everyone follows. Most BIPs are not forks of any kind: BIP39 never touched the protocol, and neither did the URI scheme in BIP21 that lets a payment link open your wallet. When a soft fork does happen, it usually takes several BIPs to describe it, plus another for the activation mechanism itself, since BIP9 and BIP8 exist only to define how signalling works. Confusing the two leads people to say bitcoin changed when a proposal was published, which is normally years early, and sometimes wrong forever.