Home › Browse › Deployed BIPs

Deployed BIPs

A BIP is Deployed when it is actually in use: a consensus change the network enforces, like SegWit or Taproot, or a convention that wallets and nodes widely follow, like seed phrases and PSBTs. Under BIP 3 this status replaced the older labels Final and Active.

Deployed doesn't mean every wallet supports it, and nobody "approves" a BIP into this status: it reflects what people run. New to BIPs? Start with what a BIP is or the most important BIPs.

78 proposals.

  • BIP 387: Tapscript Multisig Output Script Descriptors: Deployed. Defines descriptor functions for multisignature setups inside Taproot scripts, which require a different construction than older multisig. One form keeps keys in the given order and the other sorts…
  • BIP 386 (Taproot descriptors): tr() Output Script Descriptors: Deployed. Defines the descriptor function for Taproot outputs, combining a main key with an optional tree of alternative spending conditions. This gives wallets a standard way to describe, back up and recover…
  • BIP 385: raw() and addr() Output Script Descriptors: Deployed. Defines two simple descriptor functions: one that wraps an arbitrary raw script and one that wraps a plain address. They let wallets track coins in formats not otherwise covered, or watch an address…
  • BIP 384: combo() Output Script Descriptors: Deployed. Defines a 'combo' descriptor that, from a single key, describes all the common address types that key could be used with. This is handy for wallets that need to find coins sent to any of those…
  • BIP 383: Multisig Output Script Descriptors: Deployed. Defines descriptor functions for multisignature setups, where a certain number of keys out of a group must sign. One version keeps keys in the given order and another sorts them automatically, which…
  • BIP 382: Segwit Output Script Descriptors: Deployed. Defines the descriptor functions for native SegWit outputs, covering both single-key addresses and script-based ones. With these, wallets can precisely describe and back up SegWit wallets, including…
  • BIP 381: Non-Segwit Output Script Descriptors: Deployed. Defines the descriptor functions for Bitcoin's older address types: pay-to-public-key, pay-to-public-key-hash (classic addresses starting with '1'), and pay-to-script-hash (addresses starting with…
  • BIP 380: Output Script Descriptors General Operation: Deployed. Output script descriptors are a compact text language for describing exactly which addresses a wallet owns and how they are spent. This document defines their general syntax and checksum, giving…
  • BIP 371: Taproot Fields for PSBT: Deployed. Adds Taproot-related information to the Partially Signed Bitcoin Transaction (PSBT) format that wallets use to hand transactions to signers. This lets hardware wallets and other signing tools…
  • BIP 370: PSBT Version 2: Deployed. Updates the Partially Signed Bitcoin Transaction (PSBT) format, a standard file for passing an unfinished transaction between wallets and signing devices. Version 2 allows inputs and outputs to be…
  • BIP 350: Bech32m format for v1+ witness addresses: Deployed. Introduces Bech32m, a corrected version of the Bech32 address format used for SegWit addresses (those starting with 'bc1'). A subtle flaw in Bech32 could let certain typos go undetected, so Bech32m…
  • BIP 342 (Tapscript): Validation of Taproot Scripts: Deployed. Specifies Tapscript, the updated scripting rules used when a Taproot output is spent through one of its hidden alternative conditions. It switches signature checks to Schnorr, removes some old…
  • BIP 341: Taproot: SegWit version 1 spending rules: Deployed. Taproot introduces a new kind of Bitcoin output that can be spent either with a single signature or by revealing just one of many possible alternative spending conditions, kept hidden in a tree…
  • BIP 340: Schnorr Signatures for secp256k1: Deployed. Defines a standard for Schnorr signatures, a simpler and more flexible signing method than the ECDSA scheme Bitcoin originally used, on the same elliptic curve. Schnorr signatures are compact (64…
  • BIP 339: WTXID-based transaction relay: Deployed. Nodes share new transactions by announcing short identifiers, and this change lets them use the "wtxid", an identifier that also covers a transaction's SegWit signature data. The older identifier…
  • BIP 327: MuSig2 for BIP340-compatible Multi-Signatures: Deployed. Standardizes MuSig2, a scheme that lets several people jointly create a single signature that looks like an ordinary one-person Taproot signature. This makes shared-control wallets cheaper and more…
  • BIP 324: Version 2 P2P Encrypted Transport Protocol: Deployed. Introduces a new, encrypted way for Bitcoin nodes to talk to each other, so internet providers and passive observers cannot read or easily tamper with the traffic. It also slightly reduces bandwidth…
  • BIP 174 (PSBT): Partially Signed Bitcoin Transaction Format: Deployed. Defines PSBT (Partially Signed Bitcoin Transaction), a standard file format for a transaction that is still collecting signatures. It lets different wallets, hardware devices, and co-signers pass a…
  • BIP 173 (Bech32): Base32 address format for native v0-16 witness outputs: Deployed. Introduces Bech32, an address format for native SegWit outputs, recognizable by addresses starting with "bc1". It uses only lowercase letters and numbers and a strong checksum that catches typing…
  • BIP 159: NODE_NETWORK_LIMITED service bit: Deployed. Defines a signal that pruned nodes, which keep only recent blocks to save disk space, can use to advertise that they can serve recent history. This lets pruned nodes contribute more to the network…
  • BIP 158: Compact Block Filters for Light Clients: Deployed. Specifies how to build the compact block filters used by the BIP 157 light-client protocol, a compressed summary of the addresses and data touched in each block. Wallets use these filters to decide…
  • BIP 157: Client Side Block Filtering: Deployed. Defines a protocol for lightweight wallets in which full nodes publish compact summaries (filters) of each block, and wallets download them to check locally which blocks matter. Unlike the older…
  • BIP 155: addrv2 message: Deployed. Adds a new message for sharing node addresses that are longer than the old format allows. This was necessary to support newer Tor onion addresses, I2P, and other privacy networks, helping nodes…
  • BIP 152: Compact Block Relay: Deployed. Introduces compact blocks, where nodes announce a new block using short transaction identifiers instead of sending every transaction again. Since peers usually already have most transactions, this…
  • BIP 148 (UASF): Mandatory activation of segwit deployment: Deployed. Proposed a user-activated soft fork (UASF), where nodes would reject blocks that did not signal support for SegWit after a set date. It was a way for users, rather than miners alone, to push SegWit…
  • BIP 147 (NULLDUMMY): Dealing with dummy stack element malleability: Deployed. Fixes a quirk in Bitcoin's multisignature opcode, which consumes an extra unused value that anyone could modify without invalidating the transaction. Requiring that value to be empty removes one…
  • BIP 145: getblocktemplate Updates for Segregated Witness: Deployed. Updates getblocktemplate, the interface miners and mining pools use to request a block to work on, so it supports SegWit. Without this, miners could not build blocks that include SegWit transactions…
  • BIP 144: Segregated Witness (Peer Services): Deployed. Specifies the network messages nodes use to pass SegWit transactions and blocks to one another, including the separate signature data. It lets upgraded nodes share full witness data while older…
  • BIP 143 (SegWit signature hashing): Transaction Signature Verification for Version 0 Witness Program: Deployed. Changes how signatures are calculated for SegWit transactions so that verifying them no longer requires re-hashing the same data many times. It also makes the signature commit to the amount being…
  • BIP 141 (SegWit): Segregated Witness (Consensus layer): Deployed. Defines Segregated Witness (SegWit), which moves signatures into a separate "witness" section of each transaction while remaining compatible with older nodes. This fixed transaction malleability,…
  • BIP 137: Signatures of Messages using Private Keys: Deployed. Documents the long-standing way wallets sign a plain text message with a Bitcoin private key, so anyone can verify that the message came from the owner of an address. Writing it down helps different…
  • BIP 133: feefilter message: Deployed. Adds a 'feefilter' message by which a node tells its peers not to announce transactions paying fees below a chosen rate. This reduces wasted bandwidth by avoiding transactions the node would reject…
  • BIP 130: sendheaders message: Deployed. Adds a message by which a node asks its peers to announce new blocks by sending the block headers directly instead of a short notice to request later. This saves a round of messages and helps new…
  • BIP 125: Opt-in Full Replace-by-Fee Signaling: Deployed. Defines how a sender can mark an unconfirmed transaction as replaceable, so nodes will accept a new version paying a higher fee. This 'replace-by-fee' lets users speed up a transaction stuck because…
  • BIP 123: BIP Classification: Deployed. Sets out a way to classify BIPs into layers, such as consensus, peer services, APIs and applications, according to which part of the system they affect. This helps readers judge how widely a…
  • BIP 113: Median time-past as endpoint for lock-time calculations: Deployed. Changes how Bitcoin measures time for timelocked transactions, using the median time of the previous 11 blocks instead of a single block's timestamp. Because this value only moves forward, miners…
  • BIP 112: CHECKSEQUENCEVERIFY: Deployed. Introduces CHECKSEQUENCEVERIFY, a script instruction that lets coins be locked until a certain amount of time has passed since they were received. This 'relative timelock' is a key building block…
  • BIP 111: NODE_BLOOM service bit: Deployed. Adds a way for nodes to announce whether they offer 'bloom filtering', a service that lets lightweight wallets request only transactions relevant to them. Nodes can then decline to provide this…
  • BIP 94: Testnet 4: Deployed. Defines Testnet 4, a replacement for the long-running Testnet 3 practice network, where coins have no value and developers test software. It tightens a few rules to stop attackers from disrupting…
  • BIP 91 (SegWit lock-in): Reduced threshold Segwit MASF: Deployed. Proposed a way to activate SegWit with support from a simple majority of mining power instead of the 95 percent originally required. Participating miners would reject blocks that did not signal for…
  • BIP 90: Buried Deployments: Deployed. Simplifies how Bitcoin software enforces three older soft forks (BIP 34, 65 and 66) by hard-coding the block heights at which they took effect, instead of re-checking how miners voted. Since those…
  • BIP 89: Chain Code Delegation: Deployed. Describes a technique for multisignature wallets in which one main participant keeps certain key-derivation information to themselves and gives co-signers only what they need for each signature.…
  • BIP 86 (Taproot derivation): Key Derivation for Single Key P2TR Outputs: Deployed. Defines the standard key path for HD wallets that use single-key Taproot addresses (those starting with 'bc1p'). It plays the same role for Taproot that BIP 84 does for SegWit, so seed phrases…
  • BIP 85: Deterministic Entropy From BIP32 Keychains: Deployed. Describes how to derive fresh, independent secrets, such as new seed phrases or passwords, from one master wallet seed. Users can back up a single seed yet create separate seeds for other wallets,…
  • BIP 84 (native SegWit derivation): Derivation scheme for P2WPKH based accounts: Deployed. Specifies the standard key path for HD wallets that use native SegWit addresses (those starting with 'bc1q'). Agreeing on this path means a user can restore the same seed phrase in different wallet…
  • BIP 78: A Simple Payjoin Proposal: Deployed. Defines Payjoin, a way for the payer and the recipient to both contribute coins to a single payment transaction. Because the result looks like an ordinary payment but breaks common assumptions used…
  • BIP 75: Out of Band Address Exchange using Payment Protocol Encryption: Deployed. Extends the BIP 70 Payment Protocol so a sender can optionally sign their payment request and the receiver's reply is encrypted before being relayed. This lets two people exchange payment details…
  • BIP 73: Use "Accept" header for response type negotiation with Payment Request URLs: Deployed. Lets a payment request web link return either a webpage or a payment request file, depending on what the requesting software asks for. This allows short links that fit in QR codes to serve both…
  • BIP 72: bitcoin: uri extensions for Payment Protocol: Deployed. Extends "bitcoin:" links (BIP 21) with a parameter pointing to a payment request from the payment protocol (BIP 70). Wallets that support the protocol fetch the merchant's signed request, while…
  • BIP 71: Payment Protocol MIME types: Deployed. Defines official internet media types (MIME types) for payment protocol messages. These labels let browsers and email programs recognize a Bitcoin payment request and pass it to the right wallet.
  • BIP 70: Payment Protocol: Deployed. Defines a payment protocol in which a merchant sends a signed payment request directly to the customer's wallet. It aimed to improve checkout and protect against attackers swapping addresses, though…
  • BIP 68: Relative lock-time using consensus-enforced sequence numbers: Deployed. Gives transactions a "relative lock-time," so a coin cannot be spent until a set number of blocks or amount of time has passed since it was confirmed. This is an essential building block for payment…
  • BIP 66: Strict DER signatures: Deployed. Required all signatures to follow one strict encoding format, known as DER. Different software interpreted loosely encoded signatures differently, which risked splitting the network and let…
  • BIP 65: OP_CHECKLOCKTIMEVERIFY: Deployed. Adds OP_CHECKLOCKTIMEVERIFY, a script command that keeps coins unspendable until a chosen date or block height. It enables time-locked savings, escrow with deadlines, and payment channels such as…
  • BIP 61: Reject P2P message: Deployed. Adds a "reject" message so a node can tell a peer why it refused a transaction or block. This made troubleshooting easier for wallet and node developers, though Bitcoin Core later removed the message.
  • BIP 50: March 2013 Chain Fork Post-Mortem: Deployed. A post-mortem of the March 2013 incident in which a database limit in older Bitcoin software caused the blockchain to split temporarily. It explains what went wrong, how miners and developers…
  • BIP 49 (nested SegWit derivation): Derivation scheme for P2WPKH-nested-in-P2SH based accounts: Deployed. Defines how HD wallets derive keys for SegWit addresses wrapped inside P2SH, which begin with "3". This let wallets offer cheaper SegWit transactions while staying payable from older software that…
  • BIP 48 (multisig derivation path): Multi-Script Hierarchy for Multi-Sig Wallets: Deployed. Defines a key-tree layout for multisignature HD wallets that separates different script types, such as wrapped and native SegWit. It helps multisig wallets and hardware devices agree on where keys…
  • BIP 47: Reusable Payment Codes for Hierarchical Deterministic Wallets: Deployed. Introduces reusable payment codes that someone can publish once, for example on a website, without the privacy loss of reusing an address. Senders use the code to derive fresh addresses for each…
  • BIP 44 (BIP44 derivation path): Multi-Account Hierarchy for Deterministic Wallets: Deployed. Defines a standard layout for HD wallets that organizes keys by coin type, account, and receiving versus change addresses. Because wallets share this layout, a recovery phrase from one wallet can…
  • BIP 43: Purpose Field for Deterministic Wallets: Deployed. Reserves the first level of an HD wallet's key tree for a "purpose" number that says which layout the rest of the tree follows. This lets different wallet standards coexist and helps software…
  • BIP 42: A finite monetary supply for Bitcoin: Deployed. A tongue-in-cheek proposal fixing a software quirk that would have made the block reward reappear and coin issuance restart a couple of centuries from now. It ensures the roughly 21 million coin…
  • BIP 39 (seed phrase): Mnemonic code for generating deterministic keys: Deployed. Defines the recovery phrase: a list of 12 to 24 common words that encodes a wallet's master secret. Users can write the words down to back up and later restore a wallet, a format now widely used…
  • BIP 38 (encrypted private keys): Passphrase-protected private key: Deployed. Defines a way to encrypt a private key with a passphrase, producing a printable 58-character string. It is designed for paper wallets and physical coins, so someone who finds the printed key still…
  • BIP 37: Connection Bloom filtering: Deployed. Lets lightweight wallets hand a full node a Bloom filter (a compact, approximate summary of what they care about) so they receive only relevant transactions. This made phone wallets practical,…
  • BIP 35: mempool message: Deployed. Adds a "mempool" message that lets a node ask a peer for the unconfirmed transactions it is holding. This helps lightweight wallets and freshly started nodes learn quickly about payments still…
  • BIP 34 (block height in coinbase): Block v2, Height in Coinbase: Deployed. Upgraded blocks to version 2 and required each block's coinbase transaction (the one paying the miner) to include the block's height. This makes every coinbase unique, preventing duplicate…
  • BIP 32 (HD wallets): Hierarchical Deterministic Wallets: Deployed. Defines hierarchical deterministic (HD) wallets, in which a single seed generates a whole tree of keys. Users can back up a wallet once and share watch-only parts, for example with a shop or…
  • BIP 31: Pong message: Deployed. Adds a "pong" reply that a node sends back when it receives a "ping" containing a random number. This lets software reliably tell whether a connection to another node is still alive.
  • BIP 30: Duplicate transactions: Deployed. Added a rule forbidding a block from including a transaction with the same ID as an earlier one whose outputs are not fully spent. Such duplicates can overwrite earlier coins and make them…
  • BIP 23: getblocktemplate - Pooled Mining: Deployed. Extends getblocktemplate (BIP 22) with features for mining pools, such as letting participants propose their own blocks to the pool. It helps pooled miners build blocks themselves while still…
  • BIP 22: getblocktemplate - Fundamentals: Deployed. Defines getblocktemplate, a way for a node to give miners a full block template rather than just a header to hash. Miners can then see and optionally choose which transactions go into a block,…
  • BIP 16 (P2SH): Pay to Script Hash: Deployed. Introduced Pay to Script Hash (P2SH), letting a sender pay to a short fingerprint of spending rules that the recipient reveals only when spending. This shifted the cost and complexity of setups like…
  • BIP 14: Protocol Version and User Agent: Deployed. Separates the version of the Bitcoin network protocol from the version of any one program, and adds a "user agent" label identifying the software a node runs. As alternative clients appeared, this…
  • BIP 13 (P2SH addresses): Address Format for pay-to-script-hash: Deployed. Defines the address format for pay-to-script-hash, the addresses that begin with "3". Such an address stands for a hidden set of spending rules, so people can pay into arrangements like multisig as…
  • BIP 11 (M-of-N multisig): M-of-N Standard Transactions: Deployed. Made "M-of-N" transactions, which require any M signatures out of N possible keys, a standard type that nodes relay. This enabled shared-control arrangements such as escrow or wallets needing two of…
  • BIP 9: Version bits with timeout and delay: Deployed. Lets miners signal readiness for several soft forks (backward-compatible rule upgrades) at once by setting individual bits in each block's version number. An upgrade locks in once enough blocks…
  • BIP 3: Updated BIP Process: Deployed. Replaces BIP 2 with a streamlined set of rules for preparing, submitting and publishing proposals, including the role of the editors who manage them. It keeps the process workable as the number of…

Other statuses: Complete BIPs · Draft BIPs · Closed BIPs