Timechain Wiki

Bitcoin Improvement Proposals

9 min read

Bitcoin Improvement Proposals (BIPs) are the formal mechanism for proposing, discussing, and documenting protocol-change candidates and adjacent specifications. The framework was established by Amir Taaki in 2011 (BIP1) and refined by Luke Dashjr in 2016 (BIP2); the canonical repository at github.com/bitcoin/bips holds over 400 numbered BIPs as of 2026, spanning Standards Track (consensus, peer-services, applications), Informational, and Process categories. Each BIP moves through Draft, Proposed, and Final statuses, with Active, Replaced, Withdrawn, or Rejected as terminal states. The process is deliberately friction-heavy: community engagement, multi-year discussion, and substantive review precede Final status, which constrains the rate of protocol change. The framework is non-exclusive — protocol discussion also happens on mailing lists, IRC, GitHub issues, and at conferences. Crucially, BIPs document proposals and consensus; they do not have authority to mandate adoption.

Why this note matters

The BIP framework is the closest thing Bitcoin has to formal protocol-change procedure. Understanding what a BIP is — and crucially, what it is not — is the precondition for engaging the broader Bitcoin governance landscape. The BIP framework operates as a documentation-and-discussion infrastructure rather than as an authoritative-decision-making body; this distinction shapes how protocol changes actually proceed.

The BIP framework also illuminates Bitcoin’s specific governance pattern. The deliberate-friction-as-feature framing, the multi-actor consensus requirements, and the non-exclusive nature of protocol discussion all reflect the broader institutional-anthropological structure of Bitcoin governance treated in Governance without governance.

The BIP framework structure

The BIP framework is defined principally by BIP1 (original Bitcoin Improvement Proposal Purpose and Guidelines, Amir Taaki, 2011) and BIP2 (Improvement Proposal Process, Luke Dashjr, 2016, which superseded much of BIP1’s process detail).

BIP categorization. Three BIP categories:

  • Standards Track BIPs — propose changes to the Bitcoin protocol, peer-to-peer network protocol, transaction validation rules, or other protocol-level specifications. Subcategories include Consensus (changes to consensus rules), Peer Services (changes to network protocol), Applications (changes to application-layer specifications like wallet formats), and API/RPC (changes to interfaces). Consensus-level BIPs require soft-fork or hard-fork activation; lower-level Standards Track BIPs require widespread implementation but not necessarily consensus-level activation.
  • Informational BIPs — provide general guidelines, information for the Bitcoin community, or describe design issues. Do not propose specific changes; serve documentation purposes.
  • Process BIPs — describe a process or procedure or propose a change to a process. BIP1, BIP2, and several governance-related BIPs are Process category.

BIP lifecycle. Multiple statuses:

  • Draft. Initial submission; under active development; may undergo substantial revision.
  • Proposed. Ready for community engagement; the author considers it sufficiently mature for broader discussion.
  • Final. Widely adopted or activated on the network. For consensus BIPs, this typically means soft-fork or hard-fork activation has occurred and the change is part of consensus rules.
  • Active. Used for some Process BIPs that are continuously in force.
  • Replaced. Superseded by a later BIP.
  • Withdrawn. Author has withdrawn the proposal.
  • Rejected. The community has decided not to adopt the proposal.

BIP numbering. BIPs are numbered sequentially. The BIP editor (Luke Dashjr until 2024; subsequent rotation) assigns numbers and manages the repository. The number assignment is administrative; it does not imply approval.

BIP authorship. Anyone can author a BIP; submission requires following the format and submission process. The BIP editor manages the repository but does not have authority over content.

Notable BIPs

The BIP corpus is large; specific BIPs that have been particularly load-bearing for Bitcoin’s evolution:

Foundational specifications:

  • BIP32 — Hierarchical Deterministic Wallets (Pieter Wuille). The HD wallet derivation scheme that almost all modern wallets use.
  • BIP39 — Mnemonic code for generating deterministic keys. The 12/24-word seed phrase standard.
  • BIP44 — Multi-Account Hierarchy for Deterministic Wallets. The derivation-path-and-account convention.
  • BIP49 — Derivation scheme for P2WPKH-nested-in-P2SH addresses.
  • BIP84 — Derivation scheme for P2WPKH (native SegWit) addresses.
  • BIP86 — Derivation scheme for single-key P2TR (Taproot) addresses.

Major protocol upgrades:

  • BIP16 — Pay-to-script-hash (P2SH). Activated 2012 via miner signaling.
  • BIP141 + BIP143 + BIP144 — Segregated Witness (SegWit). Activated 2017 after Block Size Wars and BIP148 UASF coordination.
  • BIP173 — Bech32 address format. Activated alongside SegWit.
  • BIP340 + BIP341 + BIP342 — Schnorr signatures + Taproot. Activated 2021 via Speedy Trial.
  • BIP118 — SIGHASH_ANYPREVOUT (renamed from SIGHASH_NOINPUT). Proposed; not activated; relevant for eltoo and related proposals.
  • BIP119 — OP_CHECKTEMPLATEVERIFY. Proposed; contested; see OP_CAT and the covenants programmability debate.
  • BIP300 — Drivechains. Proposed; contested; see BIP-300 and the Drivechains debate.

Process and governance:

  • BIP1 — original Bitcoin Improvement Proposal framework (Amir Taaki, 2011).
  • BIP2 — Improvement Proposal Process (Luke Dashjr, 2016).
  • BIP8 — Activation by Block Height for Soft Forks.
  • BIP9 — Version bits with timeout and delay (the original modern soft-fork activation mechanism).
  • BIP148 — Mandatory activation of SegWit deployment (the user-activated soft fork mechanism).
  • BIP91 — Reduced threshold SegWit MASF (the activation mechanism actually used for SegWit).

Adjacent specifications:

  • BIP125 — Replace-by-Fee (Peter Todd). RBF policy specification.
  • BIP174 — Partially Signed Bitcoin Transaction format (PSBT). The wallet-interoperability format.
  • BIP380-386 — Output Script Descriptors. The descriptor framework for wallet UTXO specification.

The BIP corpus continues to grow. New BIPs are submitted continuously; the rate of activation has been slower than the rate of proposal.

The BIP discussion process

BIP discussion happens in multiple venues:

The bitcoindev mailing list (formerly Bitcoin-dev@lists.linuxfoundation.org; transitioned to bitcoindev@googlegroups.com after Linux Foundation deplatforming, then to bitcoin-core-dev IRC channel discussions, and various github issue threads). The primary technical-discussion venue.

The BIP repository pull requests (github.com/bitcoin/bips/pulls). The formal proposal-and-revision venue.

IRC channels (libera.chat bitcoin-core-dev, bitcoin-wizards, and topic-specific channels). Real-time technical discussion.

Conferences and meetups (Bitcoin Magazine’s various events, Adopting Bitcoin, BTC Prague, MIT Bitcoin Expo, etc.). Discussion and developer-coordination.

Bitcoin Optech newsletter (see Bitcoin Optech). Weekly summaries of technical developments and BIP-related discussion.

Github issues on the Bitcoin Core repository (github.com/bitcoin/bitcoin/issues). Code-implementation-level discussion.

The non-exclusive nature. Protocol-change discussion is not exclusively conducted through BIPs. Many significant protocol-relevant discussions happen in mailing-list threads and conference presentations before BIPs are formally submitted; the BIP framework documents the proposed change but doesn’t initiate the discussion process.

The deliberate-friction-as-feature framing

BIPs are deliberately difficult to advance:

  • Multi-year discussion periods are common. Taproot’s BIP341 had multi-year discussion before activation. OP_CAT proposals have been under discussion for nearly a decade without consensus resolution.
  • Multiple-reviewer consensus is expected. A BIP author cannot simply self-merge; review and pushback from other developers shape the proposal’s evolution.
  • Conservative defaults dominate. Changes that materially alter the protocol face higher scrutiny than changes that are clearly backwards-compatible and operationally simple.
  • Activation requires broader consensus. Reaching BIP Final status for a consensus change requires coordinated activation across miners, exchanges, wallets, and node operators.

The framing rationale. Bitcoin’s design philosophy treats slow, deliberate evolution as a feature rather than a bug. Rapid protocol evolution would create implementation-complexity risk, consensus-bug risk, and capture risk (rapidly-changing protocols are easier for specific actors to capture). The deliberate-friction-as-feature framing accepts the cost of slow evolution to preserve these properties.

The friction’s specific consequences. Some legitimate proposals have stalled for years (BIP118 ANYPREVOUT; various covenant proposals). Some controversial proposals continue to be debated for years (BIP119 OP_CTV; BIP300 Drivechains). The pattern is friction-heavy by design.

Counter-arguments and tensions

The slow-evolution critique. Critics argue that Bitcoin’s BIP process is too slow — that legitimate improvements stall for years while the protocol stagnates. The covenant-soft-fork debates (OP_CTV, OP_CAT, ANYPREVOUT) have been particularly contested examples. Defenders argue that slow evolution is the design choice and that fast-evolving protocols (Ethereum) have suffered from the alternative.

The consensus-bug risk. Multi-implementation consensus is structurally fragile. A consensus-level bug in Bitcoin Core that other implementations followed would be a major incident; a consensus-level bug that only one implementation had (and others rejected) would produce a chain split. The BIP framework manages this risk through review-and-coordination but cannot eliminate it.

The capture-resistance vs evolution-stagnation tradeoff. Bitcoin’s governance is structurally capture-resistant (no centralized authority to capture), but the same properties slow evolution. Critics argue this tradeoff has been overweighted toward capture-resistance; defenders argue Bitcoin’s existence-and-survival validates the design choice.

The non-exclusivity question. BIPs are documentation rather than authoritative procedure. This means protocol-change-discussion happens in many venues, with various levels of formality. Critics argue this makes governance opaque; defenders argue it allows organic discussion rather than imposed procedure.

The github-and-mailing-list-dependency. BIPs depend on github (Microsoft-owned), the bitcoindev mailing list (transitioned platforms), and various other centralized communication infrastructure. The dependency creates structural vulnerabilities; alternative-infrastructure efforts (delvingbitcoin.org; various others) have emerged but are not yet fully redundant.

Substantive analytical critique of the protocol-evolution pattern lives in Protocol-evolution constraints (Criticisms).

Open questions for further development

  • Will the post-2024 governance landscape evolve toward more-friction or less-friction protocol change? Multiple covenant proposals and the AT/ANYPREVOUT family are active discussion; whether any will achieve activation soon is uncertain.
  • How does the BIP repository scale as proposals accumulate? Navigation and curation of the corpus is an ongoing challenge.
  • What is the long-run trajectory of the BIP editor role? The editor manages administrative aspects; the role’s institutional structure has been informal.
  • How does the BIP framework interact with alternative implementations? Multi-implementation review is technically required for some BIPs; the operational implementation has been uneven.
  • What is the appropriate relationship between bitcoindev mailing list and BIP framework? Discussion happens on the mailing list before BIPs are submitted; the relationship has been informal.

Canonical sources for this note

  • BIP repository: github.com/bitcoin/bips — the canonical BIP record; bips.dev provides a rendered, browsable index of the same repository (surfaced as the BIP reference in the Educational websites and online resources §16 sub-MOC)
  • BIP1 and BIP2 — the foundational framework documents
  • bitcoindev mailing list archives — historical discussion
  • Bitcoin Optech newsletter (bitcoinops.org) — weekly summaries of BIP-related developments
  • Mastering Bitcoin - Andreas Antonopoulos — chapters on BIPs and protocol evolution

Graph View

Backlinks