A Bitcoin Improvement Proposal, or BIP, is a document describing an idea, standard, process, or other relevant information. The BIP process explicitly distinguishes publication from community agreement or deployment. A proposal can be published without being adopted. BIP 3.
Four questions to keep separate
When reading about an upgrade, ask:
- Has someone described a proposal?
- Has software implemented it?
- Which participants are running that software?
- If it changes consensus, when and under what conditions are its rules enforced?
The BIPs repository is an archive and publication process, not a committee with authority to activate arbitrary changes across the network. Not all BIPs concern consensus: wallet formats and other interoperability standards also belong there. The purpose of the process.
Soft forks and hard forks
A soft fork tightens the set of permitted blocks: blocks following the new constraints can still satisfy the old rules. Older nodes do not thereby learn to verify every new constraint.
A hard fork can allow blocks that old rules reject. Continuing on such a branch requires changing the rules used for validation. A lasting split is a possible outcome of disagreement, not a required outcome of every upgrade. Consensus-rule changes.
These terms describe rule compatibility. A temporary fork caused by competing block discoveries is a different situation from deliberately changing the rules.
A deployed example and a policy distinction
SegWit’s BIP 141 describes additional witness rules and compatibility behavior. Its specification should be read alongside the separate evidence for its 2017 activation. The SegWit design.
Mempool policy is another layer. It determines which unconfirmed transactions a node accepts or relays, and is not identical to the rules for accepting a block. Bitcoin Core’s replacement documentation is a version-specific policy example. Replacement policy.
For a historical case where software behavior diverged unexpectedly, read the March 2013 chain split.