Since its creation in 2009, Bitcoin has grown into a global digital ecosystem supported by an open community of users, miners, and developers. Unlike centralized financial systems, it operates on a transparent, code-based foundation that allows the network to upgrade and adapt without a single governing authority.
One of the key instruments that makes such evolution possible is the Bitcoin Improvement Proposal (BIP) — a formal framework that organizes how potential protocol changes are introduced, analyzed, and eventually integrated into the Bitcoin software.
What Are Bitcoin Improvement Proposals?
The BIP framework, originally introduced in 2011 by developer Amir Taaki, set a common standard for submitting and reviewing new technical concepts intended to refine Bitcoin's architecture. Each proposal acts as a detailed document describing a feature, optimization, or process connected to the network. It also creates an open communication space where contributors and community members can exchange feedback and review proposed improvements transparently before their implementation.
This mechanism is essential to maintaining Bitcoin's decentralized governance model. Since the network has no central authority, protocol evolution depends entirely on community consensus. Any participant — regardless of technical background or reputation — may draft a proposal for review. Once introduced, it is discussed publicly, refined through collaboration, and evaluated by volunteer editors who decide whether it should advance further.
Every proposal begins as a draft and may pass through multiple review stages. After broad agreement is reached, it can progress through the sequence of statuses such as "draft," "accepted," "implemented," or sometimes "rejected." Once the changes are merged into the official software, they become a formal part of the Bitcoin protocol.
Types of BIPs
BIPs are generally divided into three overarching groups, each fulfilling a distinct function in the network's ongoing development.
Standard BIPs
Standard BIPs focus on direct modifications that shape Bitcoin's operational logic or improve interaction between nodes on the network.
Informational BIPs
Informational BIPs provide technical insights, background context, and community guidance while leaving the protocol itself unchanged.
Process-Oriented BIPs
Process-oriented BIPs describe internal coordination rules, project management practices, and the organizational flow of the BIP framework.
Complete List of Final Bitcoin Improvement Proposals
BIP 9 – Version bits with timeout and delay
Introduced a mechanism to activate protocol changes via version bits with predefined timeouts.
BIP 11 – M-of-N Standard Transactions
Established a standard format for multisignature transactions using multiple private keys.
BIP 13 – Address Format for Pay-to-Script-Hash (P2SH)
Defined a new address type for complex transaction scripts.
BIP 14 – Protocol Version and User Agent
Standardized how Bitcoin nodes communicate their protocol version.
BIP 16 – Pay to Script Hash (Soft Fork)
Allowed more flexible and secure transaction types through script hashing.
BIP 22 – getblocktemplate – Fundamentals
Created the foundational mining template system for block generation.
BIP 23 – getblocktemplate – Pooled Mining
Extended the mining template protocol for pool operations.
BIP 30 – Duplicate Transactions
Prevented duplicate transaction IDs from appearing in the blockchain.
BIP 31 – Pong Message
Added a "pong" message to improve peer-to-peer communication reliability.
BIP 32 – Hierarchical Deterministic Wallets
Introduced a structured method for generating wallets from a single seed.
BIP 34 – Block v2, Height in Coinbase
Required miners to include block height in the coinbase transaction.
BIP 35 – Mempool Message
Enabled nodes to query each other's unconfirmed transactions (mempool).
BIP 37 – Connection Bloom Filtering
Allowed lightweight clients to filter and receive relevant transactions only.
BIP 39 – Mnemonic Code for Generating Deterministic Keys
Introduced mnemonic seed phrases for wallet creation and recovery.
BIP 42 – A Finite Monetary Supply for Bitcoin
Fixed Bitcoin's total coin supply at 21 million.
BIP 43 – Purpose Field for Deterministic Wallets
Defined a structure to separate different wallet types by purpose.
BIP 44 – Multi-Account Hierarchy for Deterministic Wallets
Specified a multi-account derivation path for HD wallets.
BIP 47 – Reusable Payment Codes for HD Wallets
Introduced reusable payment codes for better privacy in wallets.
BIP 48 – Multi-Script Hierarchy for Multi-Sig Wallets
Defined hierarchical key derivation for multisignature wallets.
BIP 49 – Derivation Scheme for P2WPKH-in-P2SH
Standardized HD derivation for nested SegWit accounts.
BIP 50 – March 2013 Chain Fork Post-Mortem
Documented analysis of the 2013 Bitcoin chain split incident.
BIP 61 – Reject P2P Message
Allowed peers to send rejection messages when invalid transactions are received.
BIP 65 – OP_CHECKLOCKTIMEVERIFY (Soft Fork)
Enabled time-locked transactions to improve scripting flexibility.
BIP 66 – Strict DER Signatures
Enforced strict DER encoding for digital signatures to enhance validation security.
BIP 68 – Relative Lock-Time
Introduced transaction delays based on sequence numbers for better time control.
BIP 70 – Payment Protocol
Defined a secure communication layer between wallets and payment processors.
BIP 71 – Payment Protocol MIME Types
Established MIME types for consistent payment protocol data exchange.
BIP 72 – Bitcoin URI Extensions
Expanded the URI format to support payment protocol integration.
BIP 73 – Accept Header for Payment Requests
Improved wallet-server interaction in payment request handling.
BIP 84 – Derivation Scheme for P2WPKH Accounts
Standardized native SegWit (Bech32) derivation for wallets.
BIP 85 – Deterministic Entropy from BIP32 Keychains
Enabled generation of independent seeds from a single HD wallet.
BIP 86 – Key Derivation for Single Key Taproot Outputs
Defined derivation rules for Taproot addresses.
BIP 90 – Buried Deployments
Simplified activation logic for past consensus changes.
BIP 91 – Reduced Threshold SegWit MASF
Lowered the activation threshold for SegWit soft fork.
BIP 94 – Testnet 4
Introduced the fourth iteration of Bitcoin's public test network.
BIP 111 – NODE_BLOOM Service Bit
Added a service bit indicating support for Bloom filters.
BIP 112 – CHECKSEQUENCEVERIFY
Enforced relative lock-time in transaction validation.
BIP 113 – Median Time-Past
Standardized block timestamp usage for time-based rules.
BIP 125 – Opt-in Replace-by-Fee (RBF)
Allowed users to increase transaction fees by rebroadcasting modified transactions.
BIP 130 – sendheaders Message
Improved block propagation efficiency through header announcements.
BIP 133 – feefilter Message
Allowed nodes to filter transactions by fee rate.
BIP 137 – Signatures of Messages Using Private Keys
Standardized the format for message signatures using Bitcoin keys.
BIP 141 – Segregated Witness (Consensus Layer)
Increased block capacity and fixed transaction malleability.
BIP 143 – Transaction Signature Verification for SegWit
Defined new signature hashing rules for SegWit transactions.
BIP 144 – Segregated Witness (Peer Services)
Upgraded network messaging for SegWit support.
BIP 145 – GetBlockTemplate Updates for SegWit
Extended mining templates for SegWit-enabled blocks.
BIP 147 – Dummy Stack Element Malleability
Fixed a minor malleability issue in transaction scripts.
BIP 148 – Mandatory SegWit Activation
Enforced SegWit adoption across the network.
BIP 152 – Compact Block Relay
Reduced bandwidth usage by sending compact block data between peers.
BIP 155 – addrv2 Message
Introduced extended address support (IPv6 and Tor v3) for node communication.
BIP 157 – Client-Side Block Filtering
Enabled light clients to verify transactions privately.
BIP 158 – Compact Block Filters for Light Clients
Defined efficient block filters for SPV wallets.
BIP 159 – NODE_NETWORK_LIMITED Service Bit
Indicated limited node network capabilities.
BIP 173 – Bech32 Address Format
Introduced an error-resistant, SegWit-compatible address format.
BIP 174 – Partially Signed Bitcoin Transactions (PSBT)
Established a common format for unsigned or partially signed transactions.
BIP 324 – Version 2 P2P Encrypted Transport Protocol
Added encryption to peer-to-peer communication.
BIP 327 – MuSig2 for Multi-Signatures
Improved multisignature efficiency and privacy through MuSig2.
BIP 339 – WTXID-Based Transaction Relay
Optimized transaction relay using witness transaction IDs.
BIP 340 – Schnorr Signatures for secp256k1
Implemented efficient and compact signature algorithms.
BIP 341 – Taproot: SegWit Version 1 Spending Rules
Introduced Taproot, enhancing privacy and flexibility.
BIP 342 – Validation of Taproot Scripts
Defined how Taproot scripts are interpreted and validated.
BIP 343 – Mandatory Activation of Taproot
Enforced Taproot activation across the Bitcoin network.
BIP 350 – Bech32m Format for v1+ Witness Addresses
Introduced an updated Bech32m address format for Taproot.
BIP 370 – PSBT Version 2
Refined the PSBT structure for improved interoperability.
BIP 371 – Taproot Fields for PSBT
Added Taproot-related fields to the PSBT format.
BIP 380–387 – Output Script Descriptors Series
Standardized different types of script descriptors for wallet operations.
The BIP Review Process
Before a proposal becomes active, it passes through formal review stages — "draft," "proposed," "accepted," "final," "rejected," or "replaced." This organized workflow allows participants to track a BIP's progress and understand its adoption status.
Not all BIPs carry the same impact. Some involve minor technical adjustments, while others transform Bitcoin's structure at a fundamental level. Landmark proposals like SegWit (Segregated Witness) and Taproot improved scalability, transaction throughput, and privacy, showing how BIPs drive innovation while maintaining security and decentralization.
Implementation and Activation
Implementation begins once developers integrate the new rules into the client software. Users and miners then decide whether to support the change by running updated versions of Bitcoin nodes. Because the system functions on consensus, upgrades activate only when a majority adopts them — ensuring that participation remains voluntary and community-approved.
Each proposal receives a unique identifier assigned by a BIP editor, who maintains order and documentation. Some numerical ranges may be reserved for related subjects or technologies. While editors coordinate submissions, final acceptance always depends on network consensus.
It's important to note that not every software change requires a formal BIP — smaller modifications that don't influence consensus or communication can be implemented directly. However, any change affecting the protocol's core behavior must pass through the BIP procedure to keep the process transparent and consistent across the global developer base.
All accepted and historical BIPs are publicly available, allowing anyone to explore the development of Bitcoin and study how its architecture has evolved through collaboration and open review.
The Significance of BIPs in Bitcoin's Philosophy
Beyond its technical purpose, the BIP process reflects Bitcoin's founding ideals: openness, collaboration, and decentralization. It empowers anyone to influence the network's direction while ensuring that each modification undergoes detailed community evaluation. This bottom-up structure prevents centralized control and protects Bitcoin's independence as a global financial system.
Ultimately, Bitcoin Improvement Proposals serve as the foundation of the cryptocurrency's progress. They guarantee that development remains transparent, secure, and aligned with the community's goals. Through BIPs, Bitcoin evolves steadily — adopting innovations that enhance speed, privacy, and efficiency — without ever compromising the decentralized philosophy that defines it.
By exploring the full catalog of BIPs, anyone can follow Bitcoin's historical progression, understand the motivation behind each change, and see how collective decision-making continues to shape the world's first and most resilient digital currency.
