--- title: "Bitcoin Improvement Proposal (BIP): Process and Deployed BIP List" url: "https://bip39-phrase.com/bitcoin-improvement-proposal/" language: "en" published: "2025-11-06T00:00:00+00:00" updated: "2026-10-19T00:00:00+00:00" --- [ BIP Standards ](/topics/bip-standards/) Published November 6, 2025 Updated October 19, 2026 # Bitcoin Improvement Proposal (BIP): Process and Deployed BIP List ![Bitcoin Improvement Proposal (BIP): Process and Deployed BIP List](/wp-content/uploads/2025/11/Bitcoin-Improvement-Proposal-BIP_-What-It-Is-Full-List-hero.webp) A Bitcoin Improvement Proposal (BIP) is a design document that proposes a new feature, standard or process for Bitcoin and records the reasoning behind it. BIPs range from consensus rules, such as Taproot, to wallet formats, such as the [BIP39 seed phrase](/bip39-the-foundation-of-crypto-wallet-security/). They are published in the [official BIPs repository](https://github.com/bitcoin/bips) on GitHub, where volunteer editors assign numbers and record each proposal’s status. - **Who writes them:** anyone. [BIP 3](https://github.com/bitcoin/bips/blob/master/bip-0003.md), the current process document, asks authors to test the idea on the Bitcoin Development Mailing List first. - **Who numbers them:** only the BIP editors, once a draft has drawn real discussion. - **Statuses:** Draft, Complete, Deployed or Closed. - **How many:** more than 200 numbered BIPs, 78 of them Deployed as of October 2026; all 78 are listed below. - **What a BIP is not:** a decision. No formal body governs Bitcoin development or decides whether a BIP is adopted; software projects and their users do. ## Where Do BIPs Come From? The BIP framework, originally introduced in 2011 by developer Amir Taaki in [BIP 1](https://github.com/bitcoin/bips/blob/master/bip-0001.mediawiki) and adapted from Python’s PEP process, 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 and refined through collaboration, while volunteer editors check that it is on-topic, complete and properly formatted. The editors do not judge whether a proposal is likely to be adopted. ## What Statuses Can a BIP Have? The rules for this process are themselves a BIP. [BIP 3](https://github.com/bitcoin/bips/blob/master/bip-0003.md), which replaced [BIP 2](https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki) from 2016, gives every proposal one of four statuses: - **Draft.** Open for discussion and still changing. - **Complete.** Its authors have finished the work and recommend adoption. - **Deployed.** Settled and in active use; under BIP 3 this replaced the older Final and Active statuses. - **Closed.** Of historical interest only: abandoned, replaced or no longer in use. A status describes the document, not the network. A consensus change such as Taproot takes effect only after node software implements it and an activation succeeds, whatever its BIP says. ## What Types of BIPs Are There? BIP 3 defines three types of BIPs, each fulfilling a distinct function in the network’s ongoing development. ### Specification BIPs Specification BIPs, called Standards Track before BIP 3, describe changes to the protocol or features that affect how implementations work together, such as consensus rules, the peer-to-peer protocol or wallet formats. They can be implemented and checked for compliance, and they reach Complete only once they include or point to a reference implementation and test vectors. BIP 39, the seed phrase standard, and BIP 44 are examples. ### Informational BIPs Informational BIPs describe a design issue or give guidelines and other information to the Bitcoin community. BIP 32, the standard for HD wallets, and BIP 85 are examples. ### Process BIPs Process BIPs describe a process around Bitcoin or propose a change to one, such as the BIP process itself. ## List of Deployed Bitcoin Improvement Proposals As of October 2026, the official repository marks 78 BIPs as Deployed, and all of them are below, with BIP 380 to 387 sharing one entry. BIP 343 is included for context: its status is Closed. Each heading links to the BIP’s full text. ### [BIP 3 – Updated BIP Process](https://github.com/bitcoin/bips/blob/master/bip-0003.md) Replaced BIP 2 with the current process: the Draft, Complete, Deployed and Closed statuses and the Specification, Informational and Process types. ### [BIP 9 – Version bits with timeout and delay](https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki) Introduced a mechanism to activate protocol changes via version bits with predefined timeouts. ### [BIP 11 – M-of-N Standard Transactions](https://github.com/bitcoin/bips/blob/master/bip-0011.mediawiki) Established a standard format for multisignature transactions using multiple private keys. ### [BIP 13 – Address Format for Pay-to-Script-Hash (P2SH)](https://github.com/bitcoin/bips/blob/master/bip-0013.mediawiki) Defined a new address type for complex transaction scripts. ### [BIP 14 – Protocol Version and User Agent](https://github.com/bitcoin/bips/blob/master/bip-0014.mediawiki) Standardized how Bitcoin nodes communicate their protocol version. ### [BIP 16 – Pay to Script Hash (Soft Fork)](https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki) Allowed more flexible and secure transaction types through script hashing. ### [BIP 22 – getblocktemplate – Fundamentals](https://github.com/bitcoin/bips/blob/master/bip-0022.mediawiki) Created the foundational mining template system for block generation. ### [BIP 23 – getblocktemplate – Pooled Mining](https://github.com/bitcoin/bips/blob/master/bip-0023.mediawiki) Extended the mining template protocol for pool operations. ### [BIP 30 – Duplicate Transactions](https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki) Prevented duplicate transaction IDs from appearing in the blockchain. ### [BIP 31 – Pong Message](https://github.com/bitcoin/bips/blob/master/bip-0031.mediawiki) Added a “pong” message to improve peer-to-peer communication reliability. ### [BIP 32 – Hierarchical Deterministic Wallets](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) Introduced a structured method for generating wallets from a single seed; see [how BIP 32 derives a tree of keys](/bip-32/). ### [BIP 34 – Block v2, Height in Coinbase](https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki) Required miners to include block height in the coinbase transaction. ### [BIP 35 – Mempool Message](https://github.com/bitcoin/bips/blob/master/bip-0035.mediawiki) Enabled nodes to query each other’s unconfirmed transactions ([mempool](/bitcoin-mempool/)). ### [BIP 37 – Connection Bloom Filtering](https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki) Allowed lightweight clients to filter and receive relevant transactions only. ### [BIP 38 – Passphrase-Protected Private Key](https://github.com/bitcoin/bips/blob/master/bip-0038.mediawiki) Encrypts a single private key with a passphrase into a 58-character string that starts with 6P; see [how BIP38 keys work](/bip38/). ### [BIP 39 – Mnemonic Code for Generating Deterministic Keys](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki) Introduced mnemonic seed phrases for wallet creation and recovery; see [what BIP39 is and how wallets use it](/bip39-the-foundation-of-crypto-wallet-security/). ### [BIP 42 – A Finite Monetary Supply for Bitcoin](https://github.com/bitcoin/bips/blob/master/bip-0042.mediawiki) A tongue-in-cheek BIP dated April 1, 2014 that fixed a flaw in the subsidy code: it would have restarted the block reward after 64 halvings. The fix keeps Bitcoin’s supply finite. ### [BIP 43 – Purpose Field for Deterministic Wallets](https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki) Defined a structure to separate different wallet types by purpose. ### [BIP 44 – Multi-Account Hierarchy for Deterministic Wallets](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) Specified a multi-account derivation path for HD wallets; see [the BIP 44 path, level by level](/bip-44-multi-account-hierarchy-for-deterministic-wallets/). ### [BIP 47 – Reusable Payment Codes for HD Wallets](https://github.com/bitcoin/bips/blob/master/bip-0047.mediawiki) Introduced reusable payment codes for better privacy in wallets. ### [BIP 48 – Multi-Script Hierarchy for Multi-Sig Wallets](https://github.com/bitcoin/bips/blob/master/bip-0048.mediawiki) Defined hierarchical key derivation for [multisignature wallets](/multisig-work-for-bitcoin/). ### [BIP 49 – Derivation Scheme for P2WPKH-in-P2SH](https://github.com/bitcoin/bips/blob/master/bip-0049.mediawiki) Standardized HD derivation for nested SegWit accounts. ### [BIP 50 – March 2013 Chain Fork Post-Mortem](https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki) Documented analysis of the 2013 Bitcoin chain split incident. ### [BIP 61 – Reject P2P Message](https://github.com/bitcoin/bips/blob/master/bip-0061.mediawiki) Allowed peers to send rejection messages when invalid transactions are received. ### [BIP 65 – OP\_CHECKLOCKTIMEVERIFY (Soft Fork)](https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki) Enabled time-locked transactions to improve scripting flexibility. ### [BIP 66 – Strict DER Signatures](https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki) Enforced strict DER encoding for digital signatures to enhance validation security. ### [BIP 68 – Relative Lock-Time](https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki) Introduced transaction delays based on sequence numbers for better time control. ### [BIP 70 – Payment Protocol](https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki) Defined a secure communication layer between wallets and payment processors. ### [BIP 71 – Payment Protocol MIME Types](https://github.com/bitcoin/bips/blob/master/bip-0071.mediawiki) Established MIME types for consistent payment protocol data exchange. ### [BIP 72 – Bitcoin URI Extensions](https://github.com/bitcoin/bips/blob/master/bip-0072.mediawiki) Expanded the URI format to support payment protocol integration. ### [BIP 73 – Accept Header for Payment Requests](https://github.com/bitcoin/bips/blob/master/bip-0073.mediawiki) Improved wallet-server interaction in payment request handling. ### [BIP 75 – Out of Band Address Exchange using Payment Protocol Encryption](https://github.com/bitcoin/bips/blob/master/bip-0075.mediawiki) Extended the BIP 70 payment protocol so that the sender can sign a payment request and the reply is encrypted end to end. ### [BIP 78 – A Simple Payjoin Proposal](https://github.com/bitcoin/bips/blob/master/bip-0078.mediawiki) Lets the sender and the receiver build a payment together (a payjoin), which breaks the common assumption that all inputs of a transaction belong to one party. ### [BIP 84 – Derivation Scheme for P2WPKH Accounts](https://github.com/bitcoin/bips/blob/master/bip-0084.mediawiki) Standardized native SegWit (Bech32) derivation for wallets; our guide to [derivation paths](/derivation-path/) compares it with BIP 44, 49 and 86. ### [BIP 85 – Deterministic Entropy from BIP32 Keychains](https://github.com/bitcoin/bips/blob/master/bip-0085.mediawiki) Enabled generation of [independent seeds from a single HD wallet](/bip85/). ### [BIP 86 – Key Derivation for Single Key Taproot Outputs](https://github.com/bitcoin/bips/blob/master/bip-0086.mediawiki) Defined derivation rules for Taproot addresses. ### [BIP 89 – Chain Code Delegation](https://github.com/bitcoin/bips/blob/master/bip-0089.mediawiki) Lets a multisig participant co-sign without holding the BIP 32 chain code, so a collaborative custodian can sign without learning the wallet’s other addresses or its balance. ### [BIP 90 – Buried Deployments](https://github.com/bitcoin/bips/blob/master/bip-0090.mediawiki) Simplified activation logic for past consensus changes. ### [BIP 91 – Reduced Threshold SegWit MASF](https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki) Lowered the activation threshold for SegWit soft fork. ### [BIP 94 – Testnet 4](https://github.com/bitcoin/bips/blob/master/bip-0094.mediawiki) Introduced the fourth iteration of Bitcoin’s public test network. ### [BIP 111 – NODE\_BLOOM Service Bit](https://github.com/bitcoin/bips/blob/master/bip-0111.mediawiki) Added a service bit indicating support for Bloom filters. ### [BIP 112 – CHECKSEQUENCEVERIFY](https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki) Enforced relative lock-time in transaction validation. ### [BIP 113 – Median Time-Past](https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki) Standardized block timestamp usage for time-based rules. ### [BIP 123 – BIP Classification](https://github.com/bitcoin/bips/blob/master/bip-0123.mediawiki) Sorts BIPs into layers, such as consensus, peer services, API/RPC and applications, the values of the Layer field in BIP headers. ### [BIP 125 – Opt-in Replace-by-Fee (RBF)](https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki) Allowed users to increase transaction fees by rebroadcasting modified transactions. ### [BIP 130 – sendheaders Message](https://github.com/bitcoin/bips/blob/master/bip-0130.mediawiki) Improved block propagation efficiency through header announcements. ### [BIP 133 – feefilter Message](https://github.com/bitcoin/bips/blob/master/bip-0133.mediawiki) Allowed nodes to filter transactions by fee rate. ### [BIP 137 – Signatures of Messages Using Private Keys](https://github.com/bitcoin/bips/blob/master/bip-0137.mediawiki) Standardized the format for message signatures using Bitcoin keys. ### [BIP 141 – Segregated Witness (Consensus Layer)](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki) Increased block capacity and fixed transaction malleability. ### [BIP 143 – Transaction Signature Verification for SegWit](https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki) Defined new signature hashing rules for SegWit transactions. ### [BIP 144 – Segregated Witness (Peer Services)](https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki) Upgraded network messaging for SegWit support. ### [BIP 145 – GetBlockTemplate Updates for SegWit](https://github.com/bitcoin/bips/blob/master/bip-0145.mediawiki) Extended mining templates for SegWit-enabled blocks. ### [BIP 147 – Dummy Stack Element Malleability](https://github.com/bitcoin/bips/blob/master/bip-0147.mediawiki) Fixed a minor malleability issue in transaction scripts. ### [BIP 148 – Mandatory SegWit Activation](https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki) A user-activated soft fork: from August 1, 2017, nodes enforcing it rejected blocks that did not signal for SegWit. ### [BIP 152 – Compact Block Relay](https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki) Reduced bandwidth usage by sending compact block data between peers. ### [BIP 155 – addrv2 Message](https://github.com/bitcoin/bips/blob/master/bip-0155.mediawiki) Introduced the addrv2 message for longer node addresses, such as Tor v3 onion and I2P addresses, which do not fit the old 128-bit format. ### [BIP 157 – Client-Side Block Filtering](https://github.com/bitcoin/bips/blob/master/bip-0157.mediawiki) Enabled light clients to verify transactions privately; see [how client-side block filtering works](/bip-157-client-side-block-filtering/). ### [BIP 158 – Compact Block Filters for Light Clients](https://github.com/bitcoin/bips/blob/master/bip-0158.mediawiki) Defined efficient block filters for SPV wallets. ### [BIP 159 – NODE\_NETWORK\_LIMITED Service Bit](https://github.com/bitcoin/bips/blob/master/bip-0159.mediawiki) Indicated limited node network capabilities. ### [BIP 173 – Bech32 Address Format](https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki) Introduced an error-resistant, SegWit-compatible address format. ### [BIP 174 – Partially Signed Bitcoin Transactions (PSBT)](https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki) Established a common format for unsigned or partially signed transactions. ### [BIP 324 – Version 2 P2P Encrypted Transport Protocol](https://github.com/bitcoin/bips/blob/master/bip-0324.mediawiki) Added encryption to peer-to-peer communication. ### [BIP 327 – MuSig2 for Multi-Signatures](https://github.com/bitcoin/bips/blob/master/bip-0327.mediawiki) Improved multisignature efficiency and privacy through MuSig2. ### [BIP 339 – WTXID-Based Transaction Relay](https://github.com/bitcoin/bips/blob/master/bip-0339.mediawiki) Optimized transaction relay using witness transaction IDs. ### [BIP 340 – Schnorr Signatures for secp256k1](https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki) Implemented efficient and compact signature algorithms. ### [BIP 341 – Taproot: SegWit Version 1 Spending Rules](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki) Introduced Taproot, enhancing privacy and flexibility. ### [BIP 342 – Validation of Taproot Scripts](https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki) Defined how Taproot scripts are interpreted and validated. ### [BIP 343 – Mandatory Activation of Taproot](https://github.com/bitcoin/bips/blob/master/bip-0343.mediawiki) Proposed a mandatory (LOT=true) activation of Taproot as a fallback. Taproot activated through the Speedy Trial deployment instead, and BIP 343 is now Closed. ### [BIP 350 – Bech32m Format for v1+ Witness Addresses](https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki) Introduced an updated Bech32m address format for Taproot. ### [BIP 370 – PSBT Version 2](https://github.com/bitcoin/bips/blob/master/bip-0370.mediawiki) Refined the PSBT structure for improved interoperability. ### [BIP 371 – Taproot Fields for PSBT](https://github.com/bitcoin/bips/blob/master/bip-0371.mediawiki) Added Taproot-related fields to the PSBT format. ### [BIP 380–387 – Output Script Descriptors Series](https://github.com/bitcoin/bips/blob/master/bip-0380.mediawiki) Standardized different types of script descriptors for wallet operations. ## How Does a BIP Move From Idea to Deployed? BIP 3 describes the path a proposal takes: 1. **Ideation.** The authors check whether the idea has been discussed before and post it in a dedicated thread on the [Bitcoin Development Mailing List](https://groups.google.com/g/bitcoindev) before writing a full draft. 2. **Draft.** They open a pull request to the BIPs repository. Editors check that it is on-topic, properly formatted and specified in enough detail, and they assign a number once it has drawn real discussion; until then, it has no number. 3. **Complete.** The authors finish their work and recommend the BIP for adoption. A Specification BIP must first come with a reference implementation and test vectors. 4. **Deployed.** Anyone can request this status with evidence that the BIP is in active use, such as support in established mainnet software or a soft fork’s activation criteria being met. 5. **Closed.** A BIP that is abandoned, replaced or no longer used stays in the repository for its historical interest, with the reason recorded in its changelog. 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. A number can be contested, too. The soft fork first known as [BIP-444](/bip-444-reduced-data-temporary-softfork/) was formally numbered BIP 110 only once an editor announced the assignment in its pull request, as BIP 3 requires. ## How Are Consensus Changes Activated? A BIP that changes consensus rules is only a description until node software implements it and the network enforces it. Soft forks have usually been activated by miners signaling readiness in their blocks, a method [BIP 9](https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki) standardized with a threshold of 1,916 of the 2,016 blocks in a retarget period (95%). The history shows the variations: - **SegWit (2017).** The BIP 9 deployment stayed below 95% for months. BIP 91 let miners enforce SegWit signaling with an 80% threshold, and [BIP 148](https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki), a user-activated soft fork, had its nodes reject non-signaling blocks from August 1, 2017\. SegWit activated at block 481,824 later that August. - **Taproot (2021).** A short “Speedy Trial” deployment with a 90% threshold succeeded, and [BIP 341](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki) records the activation at block 709,632\. The mandatory fallback, BIP 343, was never needed. - **BIP 110 (2026).** The temporary soft fork to limit data in transactions used a 55% threshold and mandatory signaling. The nodes enforcing it split off onto a chain whose block production stalled in August 2026, and the proposal is now Closed. Because the system runs on consensus, no BIP can force an upgrade: each node operator decides which rules to run, and [miners](/how-bitcoin-mining-works/) whose blocks break the rules a node enforces find those blocks rejected by it. All BIPs, including closed ones, are public in the [official repository](https://github.com/bitcoin/bips), allowing anyone to explore the development of Bitcoin and study how its architecture has evolved through collaboration and open review. ## Does Every Bitcoin Change Need a BIP? No. BIP 3 says minor improvements and matters that concern a single project usually do not need standardization and should go to that project directly. BIPs are for ideas that interest the wider community or affect several pieces of software: consensus rules, the peer-to-peer protocol and shared formats such as seed phrases, [derivation paths](/derivation-path/) and partially signed transactions. Relay policy, the rules a node applies to unconfirmed transactions, usually changes through a node project’s own review; Bitcoin Core’s 30.0 change to OP\_RETURN limits, which set off the BIP 110 debate, is an example. The reverse also holds: a BIP does not define what Bitcoin is. Each one is its authors’ recommendation, and adoption happens when wallets, nodes and their users choose to implement it. Projects document what they support; Bitcoin Core keeps a [list of the BIPs it implements](https://github.com/bitcoin/bitcoin/blob/master/doc/bips.md), with the version that added each one. ## Frequently Asked Questions ### Who approves a BIP? Nobody, in a formal sense. Editors check that a proposal is on-topic, complete and properly formatted, assign numbers and update statuses, but they do not decide whether it is adopted. Adoption depends on the software projects that implement a BIP and the people who run that software. ### Which BIPs matter for seed phrases and wallets? BIP 39 turns entropy into the words you back up, [BIP 32](/bip-32/) derives keys from the seed, [BIP 44](/bip-44-multi-account-hierarchy-for-deterministic-wallets/), BIP 49, BIP 84 and BIP 86 fix the paths for each address type, and [BIP 85](/bip85/) derives child seeds. Our comparison of [BIP39, BIP32 and BIP44](/crypto-seed-standards-bip39-vs-bip32-vs-bip44/) shows how the first three fit together. ### What is the difference between a BIP and a SLIP? SLIPs are SatoshiLabs Improvement Proposals, published by the company behind Trezor for standards outside the BIP repository, such as the SLIP-44 registry of coin types and SLIP-39 Shamir backups; see [SLIP-39 vs BIP39](/slip39-vs-bip39/). ### Can a BIP be withdrawn? It can be marked Closed, but it is not deleted: under BIP 3 it stays in the repository, with the reason for the change recorded in its changelog. **Explore the BIP series:** [BIP-32: Hierarchical Deterministic Wallets](/bip-32/) · [BIP-39: The Seed Phrase Standard](/bip39-the-foundation-of-crypto-wallet-security/) · [BIP-44: Multi-Account Hierarchy](/bip-44-multi-account-hierarchy-for-deterministic-wallets/) · [BIP-110 (BIP-444): Reduced Data Temporary Softfork](/bip-444-reduced-data-temporary-softfork/) · [BIP-157: Client-Side Block Filtering](/bip-157-client-side-block-filtering/) · [BIP39 vs BIP32 vs BIP44 compared](/crypto-seed-standards-bip39-vs-bip32-vs-bip44/) [ Back to Blog ](/blog/)