Bitcoin BIP Reference Guide: Standards and Proposals
Reference guide to important Bitcoin Improvement Proposals: consensus changes, key management, transaction formats, and network protocols organized by category.
What Are Bitcoin Improvement Proposals?
A Bitcoin Improvement Proposal (BIP) is a design document that introduces new features, processes, or information to the Bitcoin protocol. BIPs serve as the primary mechanism for proposing changes to Bitcoin, from consensus-level soft forks to wallet interoperability standards. The process was formalized in BIP 1 (2011) by Amir Taaki, modeled after Python's PEP system, and most recently overhauled by BIP 3, which took effect in January 2026.
This guide organizes the most important BIPs by category: consensus changes that alter block validation rules, key management standards that enable wallet interoperability, transaction format specifications, and network-level protocols. Each entry includes the BIP number, title, current status, and a technical summary.
Consensus BIPs
Consensus BIPs modify Bitcoin's block validation rules and require network-wide coordination to activate. These are deployed as soft forks, meaning upgraded nodes enforce new rules while non-upgraded nodes continue to accept blocks under the old rules.
| BIP | Title | Status | Description |
|---|---|---|---|
| 34 | Block v2, Height in Coinbase | Deployed | Requires block height in the coinbase transaction scriptSig, preventing coinbase transaction hash collisions between blocks. |
| 66 | Strict DER Signatures | Deployed | Mandates strict DER encoding for all signatures passed to signature-checking opcodes, removing Bitcoin's dependency on OpenSSL's variable parsing behavior. |
| 68 | Relative Lock-Time Using Sequence Numbers | Deployed | Repurposes the transaction nSequence field for consensus-enforced relative timelocks: block-based or time-based (512-second increments). Enables HTLCs used in payment channels. |
| 112 | OP_CHECKSEQUENCEVERIFY | Deployed | Introduces an opcode that restricts script execution based on relative output age. Works with BIP 68 to enable Lightning channels and escrow contracts with automatic timeouts. |
| 113 | Median Time-Past for Lock-Time | Deployed | Uses the median timestamp of the last 11 blocks instead of the current block's timestamp for lock-time evaluation, eliminating miner incentive to manipulate timestamps. |
| 141 | Segregated Witness (Consensus Layer) | Deployed | Separates witness data from transactions, fixing transaction malleability and defining block weight (max 4,000,000 weight units). Activated August 2017. |
| 143 | SegWit v0 Transaction Signing | Deployed | New digest algorithm for SegWit v0 signatures that includes input amounts in signed data (enabling hardware wallet verification) and reduces hashing from O(n²) to O(n). |
| 340 | Schnorr Signatures for secp256k1 | Deployed | Defines 64-byte Schnorr signatures with provable security, non-malleability, and linearity enabling MuSig2 key aggregation and batch verification. |
| 341 | Taproot: SegWit v1 Spending Rules | Deployed | Introduces SegWit v1 outputs with Schnorr-based key aggregation, Merkle tree scripts, and key-path/script-path spending. Activated at block 709,632 (November 2021). |
| 342 | Tapscript Validation | Deployed | Defines scripting rules for Taproot: replaces ECDSA with Schnorr, introduces OP_CHECKSIGADD, and removes legacy script size limits. |
For a deeper look at how BIPs 68, 112, and 113 work together to enable relative timelocks, see our Bitcoin timelocks guide. The Taproot upgrade (BIPs 340, 341, 342) is covered in detail in Taproot and Schnorr signatures explained.
Key Management BIPs
Key management BIPs define how wallets generate, derive, and organize cryptographic keys. These standards ensure that a seed phrase created in one wallet can recover funds in another, forming the foundation of HD wallet interoperability.
| BIP | Title | Status | Derivation Path | Address Type |
|---|---|---|---|---|
| 32 | Hierarchical Deterministic Wallets | Deployed | m / ... (base standard) | All (foundation) |
| 39 | Mnemonic Seed Phrases | Deployed | N/A (seed generation) | All (12-24 word mnemonics) |
| 43 | Purpose Field for HD Wallets | Deployed | m / purpose' / ... | All (namespace standard) |
| 44 | Multi-Account HD Hierarchy | Deployed | m / 44' / 0' / acct' / chg / idx | Legacy P2PKH (1...) |
| 49 | P2WPKH-nested-in-P2SH Derivation | Deployed | m / 49' / 0' / acct' / chg / idx | Wrapped SegWit (3...) |
| 84 | Native SegWit (P2WPKH) Derivation | Deployed | m / 84' / 0' / acct' / chg / idx | Bech32 (bc1q...) |
| 86 | Taproot (P2TR) Derivation | Deployed | m / 86' / 0' / acct' / chg / idx | Bech32m (bc1p...) |
Each derivation path uses a different purpose field to prevent key overlap between address types. The progression from BIP 44 through BIP 86 mirrors the evolution of Bitcoin address formats: from legacy P2PKH to wrapped SegWit, native SegWit, and Taproot. For a visual walkthrough of these address types, see our Bitcoin address types guide and the address format reference tool.
Transaction Format BIPs
Transaction format BIPs define how Bitcoin transactions are constructed, signed, and modified. Two standards stand out for their impact on wallet workflows and fee management.
BIP 125: Replace-by-Fee (RBF)
Replace-by-Fee allows unconfirmed transactions to be replaced with higher-fee versions. Originally opt-in (signaled via nSequence values below 0xfffffffe), full RBF became the default in Bitcoin Core 24.0 (November 2022). All unconfirmed transactions are now replaceable regardless of signaling. The RBF detector tool can check whether a specific transaction signals replaceability.
BIP 174 and BIP 370: PSBT
The Partially Signed Bitcoin Transaction format (PSBT) standardizes multi-party transaction signing. BIP 174 defines a binary key-value map format with six roles: Creator, Updater, Signer, Combiner, Finalizer, and Extractor. This is critical for hardware wallets, air-gapped devices, and multisig workflows where no single party holds all keys. BIP 370 (PSBTv2) extends the format to allow adding inputs and outputs after initial creation, enabling interactive protocols like PayJoin. Use the PSBT inspector to decode and examine PSBT fields.
Network and Address Format BIPs
These BIPs define how Bitcoin nodes communicate and how addresses are encoded. They operate at the application and network layers rather than the consensus layer.
| BIP | Title | Status | Description |
|---|---|---|---|
| 21/321 | Bitcoin URI Scheme | Deployed | Defines the bitcoin: URI format for payment links and QR codes. BIP 321 supersedes BIP 21 with bech32/bech32m support. |
| 173 | Bech32 Address Format | Deployed | Base32 encoding for SegWit v0 addresses (bc1q...) with BCH error-detection codes. Case-insensitive and QR-optimized. |
| 350 | Bech32m Address Format | Deployed | Fixes a Bech32 checksum vulnerability for SegWit v1+ addresses (bc1p... for Taproot). Changes the checksum constant from 1 to 0x2bc830a3. |
| 155 | addrv2 Message | Deployed | Variable-length network address gossip supporting Tor v3 (256-bit), I2P, and Cjdns. Replaces the legacy 16-byte addr message. |
| 324 | v2 Encrypted P2P Transport | Deployed | Opportunistic encryption using ChaCha20-Poly1305 with ElligatorSwift handshakes. Traffic is indistinguishable from random data to passive observers. |
| 352 | Silent Payments | Complete | Static payment addresses without on-chain linkability. Uses ECDH to generate unique outputs per payment from a single published address. Taproot-only. |
BIP 324's encrypted transport is a significant privacy improvement: prior to its deployment, all Bitcoin P2P traffic was plaintext, allowing ISPs and network observers to identify Bitcoin nodes and monitor transaction relay. Silent Payments (BIP 352) are covered in depth in our Silent Payments privacy analysis.
Lightning Network BOLTs
The Lightning Network uses its own specification system: Basis of Lightning Technology (BOLT) documents. BOLTs build on Bitcoin's on-chain capabilities, particularly SegWit (BIP 141), relative timelocks (BIPs 68/112/113), and increasingly Taproot (BIPs 340-342). A key difference from BIPs: a proposal only becomes a BOLT after two independent implementations demonstrate interoperability.
There are 11 numbered BOLT documents covering the base protocol (BOLT 1), channel management (BOLT 2), on-chain transaction formats (BOLT 3), onion routing (BOLT 4), node discovery (BOLT 7), encrypted transport (BOLT 8), and invoice protocols (BOLT 11). BOLT 12 (Offers) is the most significant recent addition, enabling reusable payment codes, receiver privacy via blinded paths, and subscription models. For a detailed comparison of BOLT 11 and BOLT 12 invoices, see our Lightning invoices guide.
The BIP Process
BIP 3, activated in January 2026, simplified the proposal lifecycle. The previous system (BIP 2, from 2016) had nine statuses and gave editors broad authority to evaluate "technical soundness," which created bottlenecks. BIP 3 reduces statuses to four and limits editors to verifying that proposals are on-topic and properly formatted.
| Status | Meaning | Transition |
|---|---|---|
| Draft | Initial proposal, actively being worked on | Author declares specification finished to move to Complete |
| Complete | Specification finished and reviewed | Moves to Deployed once adopted in production |
| Deployed | Implemented and in active use | May move to Closed if no longer in active use |
| Closed | Withdrawn, stalled, or superseded | Can be reopened within 4 weeks if someone volunteers |
Current BIP editors include Luke Dashjr, Mark "Murch" Erhardt, Ruben Somsen, and Olaoluwa "Roasbeef" Osuntokun, among others. All BIPs are maintained in the bitcoin/bips GitHub repository.
Active Proposals and Future Direction
Several BIPs are under active development or discussion as potential future soft forks.
Covenant Proposals
Covenants allow outputs to restrict how they can be spent beyond standard signature checks. The leading proposals are BIP 119 (OP_CHECKTEMPLATEVERIFY), which lets an output commit to the exact spending transaction, and BIP 348 (OP_CHECKSIGFROMSTACK), which enables signature verification against arbitrary data. BIP 347 (OP_CAT) would reintroduce stack concatenation in Tapscript. The CTV + CSFS combination is widely considered the frontrunner for the next consensus soft fork. For technical details, see our covenants explainer.
Quantum Resistance
BIP 360 proposes Pay-to-Merkle-Root (P2MR), a new output type that removes permanently embedded public keys from on-chain data. BIP 361 outlines a three-phase quantum migration plan that would eventually prohibit sending to legacy address types. Both proposals are in early stages and remain contentious.
Data Limitation
BIP 110 proposes temporarily limiting arbitrary data in Bitcoin transactions, targeting inscriptions and Ordinals. The proposal would cap output sizes and witness element lengths for approximately one year. Signaling began in December 2025, but adoption among nodes remains low.
How BIPs Relate to Bitcoin Development
BIPs are standards documents, not code. A BIP being "Deployed" means the specification is implemented and active, but implementations vary across software. Bitcoin Core is the reference implementation, but alternative node software like Bitcoin Knots, btcd, and Libbitcoin may implement BIPs differently or on different timelines.
For developers building on Bitcoin, the key management BIPs (32, 39, 44, 84, 86) define wallet compatibility requirements. Transaction format BIPs (174, 370) define how signing workflows interoperate. Consensus BIPs define what scripts and transactions the network will accept. The opcode reference and script debugger are useful companions for working with BIP-defined script changes.
Layer-2 protocols like the Lightning Network and Spark build directly on BIP-defined primitives. SegWit (BIP 141) fixed transaction malleability, making payment channels reliable. Taproot (BIPs 340-342) enables more efficient multisig constructions and privacy-preserving channel opens. Future covenant BIPs could unlock new layer-2 designs like channel factories and vaults.
Frequently Asked Questions
What is a BIP in Bitcoin?
A Bitcoin Improvement Proposal (BIP) is a formal design document for introducing changes or standards to the Bitcoin protocol. BIPs cover everything from consensus rule changes (like SegWit and Taproot) to wallet standards (like HD key derivation) and network protocols. Anyone can author a BIP, but it must follow the format defined in BIP 3 and be accepted by the BIP editors for inclusion in the official repository.
How many BIPs are there?
The bitcoin/bips repository contains over 400 numbered proposals. Many are in Draft or Closed status. The most impactful BIPs are the roughly 30-40 that have reached Deployed status, including SegWit (BIP 141), Taproot (BIP 341), HD wallets (BIP 32), and PSBT (BIP 174).
What is the difference between a BIP and a BOLT?
BIPs define standards for the Bitcoin base layer (on-chain consensus, wallet formats, network protocols). BOLTs define standards for the Lightning Network layer-2 protocol. A key process difference: a Lightning proposal becomes a BOLT only after two independent implementations demonstrate interoperability, while BIPs have no such requirement. BOLTs build on BIP-defined primitives like SegWit and Taproot.
What is the next Bitcoin soft fork?
As of mid-2026, the leading candidates for the next consensus soft fork are the covenant proposals: BIP 119 (OP_CHECKTEMPLATEVERIFY) and BIP 348 (OP_CHECKSIGFROMSTACK). These would enable new scripting capabilities for vaults, channel factories, and more efficient layer-2 protocols. No activation timeline has been set, and community consensus is still forming.
What BIP defines seed phrases?
BIP 39 defines the standard for mnemonic seed phrases. It converts random entropy into 12-24 human-readable words using a 2048-word dictionary. The mnemonic is then converted to a 512-bit seed using PBKDF2 with 2048 iterations of HMAC-SHA512. An optional passphrase provides additional security. BIP 39 seeds are used with BIP 32 HD wallet derivation to generate all keys from a single backup.
What is the BIP for Taproot?
Taproot is defined across three BIPs: BIP 340 (Schnorr signature scheme), BIP 341 (Taproot spending rules and Merkle tree structure), and BIP 342 (Tapscript validation rules). Together they were activated at block 709,632 in November 2021 via a modified BIP 9 deployment with a 90% signaling threshold (1,815 of 2,016 blocks per period).
What is PSBT used for?
PSBT (BIP 174) is a standardized format for passing partially signed transactions between devices and parties. Common use cases include hardware wallet signing (the wallet constructs a PSBT, the hardware device signs it, and the wallet finalizes and broadcasts it), multisig coordination where multiple signers add their signatures sequentially, and CoinJoin protocols where multiple participants contribute inputs without revealing private keys.
This reference guide is for informational purposes only and does not constitute financial or technical advice. BIP statuses reflect the state of the bitcoin/bips repository as of mid-2026 and may change. Always consult the official BIP documents and Bitcoin Core release notes for authoritative information.
Build with Spark
Integrate bitcoin, Lightning, and stablecoins into your app with a few lines of code.
Read the docs →