Protocol History
How BIPs work, and what a BIP number does not mean
Protocol referenceSource: BIP 1 and BIP 2, the process documentsThe stages and status values follow BIP 2.
What a BIP is
A BIP is a document that specifies a change to Bitcoin, or to the conventions around it, in enough detail that someone else could implement it. The format is deliberately plain: a header recording the author, the status and the type, followed by the technical specification, the rationale, and a discussion of backward compatibility. The document is versioned in a public repository, so its history and the discussion around it are both visible.
The process was itself defined by a BIP. BIP 1 set out the original procedure, and BIP 2 replaced it with the current one. That is a useful illustration of how the system works: the rules for making proposals are themselves proposals, and they can be revised through the same mechanism. Nothing about the process is fixed by an authority outside the repository.
BIPs are typed. A Standards Track BIP proposes a change to the protocol, the consensus rules, or the network's behaviour. An Informational BIP documents a design issue or a convention without proposing a rule. A Process BIP changes the way decisions are made, as BIP 2 did. The type matters because only Standards Track proposals can become consensus rules, and even then only if the network adopts them.
The stages a proposal passes through
A proposal begins as an idea circulated among developers, usually on the mailing list or in a repository discussion. If it attracts interest, it is written up in the BIP format and submitted to the editors, who check that it is complete and assign it a number. At that point it is a Draft. Being assigned a number means the document exists and is well formed; it does not mean anyone has agreed to it.
A Draft that is actively being worked on and has rough agreement among the people who would implement it may be moved to Proposed. From there it can reach Final, which means the specification is complete and the change has been adopted, or it can be Withdrawn by its author, or Rejected if it is not going to be pursued. There is also Deferred, for proposals that are not being actively worked on but have not been abandoned.
The status values describe the document, not the network. A Final BIP is one whose specification is settled and which has been adopted; a Draft BIP may be implemented in a client without ever being adopted by the network. The repository is a record of what has been proposed and what state each proposal reached, and reading it as a list of Bitcoin's features would be a mistake.
Published is not deployed
The gap between a published proposal and a deployed rule is the part of the process most often misunderstood. A BIP can be complete, reviewed and assigned a number for years without the network enforcing anything it describes. Deployment requires that node software implement the rule, that miners produce blocks satisfying it, and that enough of the network enforce it that blocks violating it are rejected. None of that follows from the document.
The clearest illustration is the number of proposals that have been written and never activated. Covenant proposals, drivechain designs and various scaling approaches have all been specified in detail and remain proposals. Describing any of them as a feature of Bitcoin would be wrong, and the error is easy to make because the documents are technical and complete.
The reverse error is also possible. A change can be deployed without a BIP at all, because the BIP process is a convention rather than a requirement. What the process provides is a record: a place where the reasoning behind a change is written down and can be examined later. That record is valuable precisely because consensus changes are difficult to reverse.
From proposal to rule
For a Standards Track proposal that changes consensus, the last step is activation. The mechanism is usually specified in a separate BIP: BIP 9 defined version-bits signalling, and BIP 8 defined an alternative with a different fallback. The version bits and soft-fork signalling page works through how those mechanisms coordinate adoption.
The deployed changes are catalogued on the major protocol upgrades page, and the distinction between a rule that tightens the valid set and one that loosens it is the subject of the soft forks and hard forks page. Read together, the three pages describe the full path from an idea in a document to a rule the network enforces.
Sources
- BIP 1, BIP Purpose and Guidelines — the original process document.
- BIP 2, BIP Process, revised — the current stages, types and status values.
- Bitcoin BIPs repository, bitcoin/bips — the index of every published proposal and its status.
- BIP 9, Version bits with timeout and delay — the activation mechanism a Standards Track proposal typically names.
Related reading
- Protocol, Transactions & MiningThe supply schedule, transaction mechanics and mining economics behind the price.
- Proof of WorkThe hash puzzle, the target and nonce, and why accumulated work secures the chain.
- Difficulty AdjustmentThe 2,016-block retarget, its caps, and the ten-minute target it defends.
- HashrateWhat hashrate measures, why it is estimated, and how it differs from difficulty.
- Mining PoolsPooled hash rate, share accounting, payout schemes and centralisation.
- Miner RevenueThe block subsidy plus fees, and how the mix changes across subsidy epochs.