Home › Browse

Browse proposals

213 proposals: 78 deployed, 22 complete, 56 draft, 57 closed.

BIP 1: BIP Purpose and Guidelines: Closed. The original document that defined what a Bitcoin Improvement Proposal is and how one is written, discussed and accepted. Modeled on Python's proposal process, it gave the community a shared, public…
BIP 2: BIP process, revised: Closed. A revised version of the proposal process that replaced BIP 1, clarifying how proposals move between statuses, how comments are gathered, and which licenses are allowed. It aimed to make the path…
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…
BIP 8: Version bits with lock-in by height: Complete. An alternative way to activate soft forks (backward-compatible rule upgrades) that measures time in block counts rather than clock timestamps. It also adds an option to guarantee activation at the…
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 10: Multi-Sig Transaction Distribution: Closed. Proposed a standard format for passing a partly signed multi-signature transaction between the people who must sign it. Coins that need several parties' approval to spend require this kind of…
BIP 11: 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 12: OP_EVAL: Closed. Proposed a new script command, OP_EVAL, that would let the receiver of coins define the conditions for spending them instead of the sender. It was abandoned over security concerns and replaced by…
BIP 13: 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 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 15: Aliases: Closed. Explored ways to replace long, hard-to-remember Bitcoin addresses with human-friendly names, much as domain names stand in for numeric internet addresses. Several naming approaches were compared;…
BIP 16: 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 17: OP_CHECKHASHVERIFY (CHV): Closed. A competing proposal to P2SH that would have added a script command, OP_CHECKHASHVERIFY, letting recipients set their own spending conditions. The community chose BIP 16 instead, and this approach…
BIP 18: hashScriptCheck: Complete. Another alternative to P2SH that would have restructured how transactions present their locking and unlocking scripts, committing to a hash of the spending script. It aimed to support complex…
BIP 19: M-of-N Standard Transactions (Low SigOp): Closed. Proposed multi-signature transactions needing M of N keys as a standard type using the existing script system, designed to count fewer signature checks. It was meant as an interim option before P2SH…
BIP 20: URI Scheme: Closed. An early proposal for "bitcoin:" links that bundle an address and amount, so clicking or scanning one opens a wallet ready to pay. It was superseded by BIP 21.
BIP 21: URI Scheme: Closed. Defines the "bitcoin:" link format that packages an address, amount, label and message into one string, often shown as a QR code. Wallets read these links to fill in payment details automatically,…
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 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 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 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 32: 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 33: Stratized Nodes: Closed. Proposed specialized node roles so lightweight clients could rely on full nodes that serve them only the data they need. It aimed to keep Bitcoin usable for ordinary users as the blockchain grew too…
BIP 34: 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 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 36: Custom Services: Closed. Proposed a way for nodes to announce custom or optional services during their initial handshake without using up the small set of standard service flags. It would have made it easier to add new…
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 38: 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 39: 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 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 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 44: 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 45: Structure for Deterministic P2SH Multisignature Wallets: Complete. Defines a key structure for HD wallets shared among several co-signers using P2SH multisig. It lets each participant independently generate the same series of shared addresses without exchanging new…
BIP 46: Address Scheme for Timelocked Fidelity Bonds: Draft. Defines how HD wallets create time-locked addresses for "fidelity bonds," where coins are locked for a period to prove a costly commitment. Such bonds can help resist fake identities in systems like…
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 48: 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 49: 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 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 52: Durable, Low Energy Bitcoin PoW: Closed. Proposed replacing Bitcoin's mining puzzle with one designed for optical computing chips, so mining costs would depend more on hardware than on electricity. The aim was to cut energy use and spread…
BIP 53: Disallow 64-byte transactions: Draft. Proposes making transactions that are exactly 64 bytes long (excluding signature data) invalid. Such transactions can be confused with internal pieces of a block's Merkle tree, the structure…
BIP 54: Consensus Cleanup: Complete. Bundles fixes for several long-standing protocol weaknesses: the timewarp attack (manipulating block timestamps to speed up coin issuance), blocks that take extremely long to validate, Merkle tree…
BIP 60: Fixed Length "version" Message (Relay-Transactions Field): Closed. Proposed making the "relay transactions" flag a fixed, always-present part of the initial handshake message rather than an optional extra. The optional field, introduced by BIP 37, made message…
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 62: Dealing with malleability: Closed. Proposed a set of rules to stop third parties from altering a transaction's ID without changing what it does, a problem called malleability. It was withdrawn after Segregated Witness (SegWit) solved…
BIP 64: getutxo message: Closed. Proposed a network message letting a node ask peers whether specific coins are still unspent. It was aimed at lightweight clients but was not adopted, partly because peers' answers could not be…
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 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 67: Deterministic Pay-to-script-hash multi-signature addresses through public key sorting: Complete. Specifies sorting the public keys in a multisig setup into a fixed order, so the same keys always produce the same P2SH address. Co-signers can then independently compute matching addresses without…
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 69: Lexicographical Indexing of Transaction Inputs and Outputs: Complete. Proposes sorting transaction inputs and outputs in a standard, alphabetical-style order. Because wallets ordered them differently, observers could tell which wallet created a transaction; a shared…
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 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 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 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 74: Allow zero value OP_RETURN in Payment Protocol: Closed. Adjusts the BIP 70 Payment Protocol so a merchant's payment request can include an OP_RETURN output carrying zero bitcoin, a way of attaching a small piece of data to a transaction. This lets…
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 77: Async Payjoin: Draft. Introduces a second version of Payjoin that works asynchronously, so sender and receiver do not need to be online at the same moment. An untrusted relay called a directory server passes encrypted…
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 79: Bustapay :: a practical coinjoin protocol: Closed. Describes Bustapay, a simple protocol in which the sender and receiver of a payment jointly build and sign the transaction, each adding their own coins. Mixing ownership this way undermines the…
BIP 80: Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets: Closed. Sets out a standard folder-like structure of keys for 'voting pool' wallets, where several parties jointly control funds using multisignature (multiple-key) addresses. Building on the HD wallet…
BIP 81: Hierarchy for Colored Voting Pool Deterministic Multisig Wallets: Closed. A companion to BIP 80, this proposal defines a standard key structure for voting pool multisignature wallets that handle 'colored coins', bitcoins tagged to represent other assets. Following a…
BIP 83: Dynamic Hierarchical Deterministic Key Trees: Closed. Proposes a way to create new branches of an HD wallet's key tree on the fly rather than following one fixed layout. Wallets could then organize keys into flexible hierarchies for different purposes…
BIP 84: 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 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 86: 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 87: Hierarchy for Deterministic Multisig Wallets: Complete. Establishes a common key structure for multisignature wallets, where spending requires approval from several keys. Unlike earlier schemes, a single layout covers all script types, which makes it…
BIP 88: Hierarchical Deterministic Path Templates: Complete. Defines a compact text format for describing which key paths a wallet is allowed to use, for example 'any account number from 0 to 9'. Hardware wallets and software can use these templates to…
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 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 91: 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 93: codex32: Checksummed SSSS-aware BIP32 seeds: Draft. Introduces codex32, a format for backing up a wallet seed that includes a strong error-detecting checksum and can be checked or created by hand with paper tools. It optionally supports splitting the…
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 95: Testnet 5: Draft. Proposes Testnet 5 to replace Testnet 4, removing a special rule that let blocks be mined at minimum difficulty, which had been heavily abused. It also raises the minimum difficulty and applies the…
BIP 98: Fast Merkle Trees: Draft. Specifies a faster and safer version of the Merkle tree, the data structure Bitcoin uses to summarize many items in one fingerprint so that any single item can be proven to be included. The design…
BIP 99: Motivation and deployment of consensus rule changes ([soft/hard]forks): Closed. Lays out a classification of the different ways Bitcoin's core rules can be changed, such as soft forks and hard forks, and explains the reasons behind each. It also recommends how each type should…
BIP 100: Dynamic maximum block size by miner vote: Closed. Proposed replacing Bitcoin's fixed 1 MB block size limit with one that miners could vote to raise or lower, with votes counted on the same two-week cycle as mining difficulty adjustments. It was one…
BIP 101: Increase maximum block size: Closed. Proposed replacing the fixed 1 MB block size limit with a limit that grows automatically on a predictable schedule over time. Supporters argued it would let Bitcoin handle more transactions as…
BIP 102: Block size increase to 2MB: Closed. Proposed a single, simple increase in the maximum block size from 1 MB to 2 MB to allow more transactions per block. Being a change that older software would reject, it would have required a hard…
BIP 103: Block size following technological growth: Closed. Proposed gradually increasing the block size limit at a rate meant to track improvements in hardware and internet bandwidth. The goal was to allow more transactions while keeping it practical for…
BIP 104: 'Block75' - Max block size like difficulty: Closed. Proposed 'Block75', which would adjust the maximum block size every two weeks so that blocks stay about 75 percent full on average. Like the difficulty adjustment, it reacts to recent activity,…
BIP 105: Consensus based block size retargeting algorithm: Closed. Proposed a mechanism for changing the maximum block size based on votes or consensus among network participants rather than a fixed number. It aimed to let the limit adapt over time without repeated…
BIP 106: Dynamically Controlled Bitcoin Block Size Max Cap: Closed. Proposed letting the maximum block size rise or fall at each difficulty adjustment based on how full recent blocks were, with a variant that also considered miners' fee income. The idea was to adapt…
BIP 107: Dynamic limit on the block size: Closed. Proposed a block size limit that adjusts automatically according to the volume of transactions on the network. The aim was to expand capacity when demand is high while avoiding a fixed number that…
BIP 109: Two million byte size limit with sigop and sighash limits: Closed. Proposed doubling the block size limit from 1 MB to 2 MB, alongside new caps on signature checks and data hashing to stop specially crafted blocks from overloading nodes. It was associated with the…
BIP 110: Reduced Data Temporary Softfork: Closed. Proposes a temporary soft fork that would limit the size of arbitrary data fields allowed in transactions under Bitcoin's core rules. Supporters argue this would discourage using block space for…
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 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 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 114: Merkelized Abstract Syntax Tree: Closed. Proposed MAST, which organizes a script's possible spending conditions into a tree so that only the condition actually used needs to be revealed. This saves space and improves privacy by hiding…
BIP 115: Generic anti-replay protection using Script: Closed. Proposed a new script instruction that makes a transaction valid only on a blockchain containing a specific block. This would protect users during chain splits by preventing a transaction on one…
BIP 116: MERKLEBRANCHVERIFY: Draft. Proposed MERKLEBRANCHVERIFY, a script instruction that checks whether a piece of data belongs to a committed set using a Merkle proof. It would let complex contracts reveal only the spending…
BIP 117: Tail Call Execution Semantics: Draft. Proposed letting a script hand off execution to another script supplied at spending time, a 'tail call'. Combined with BIP 116, this would allow contracts with many possible spending conditions…
BIP 118: SIGHASH_ANYPREVOUT for Taproot Scripts: Draft. Proposes SIGHASH_ANYPREVOUT, a signature type for Taproot scripts that does not commit to the exact coin being spent, so one signed transaction can be attached to any compatible coin. This would…
BIP 119: CHECKTEMPLATEVERIFY: Draft. Proposes CHECKTEMPLATEVERIFY, a script instruction that restricts coins so they can only be spent in a transaction matching a predetermined template. This 'covenant' could enable vaults that protect…
BIP 120: Proof of Payment: Closed. Describes Proof of Payment, a way for a wallet to prove it made a particular earlier payment by showing it controls the keys that signed it. This could let a buyer prove they paid for something,…
BIP 121: Proof of Payment URI scheme: Closed. Defines a link format (URI) for requesting a Proof of Payment, as described in BIP 120. A service can present such a link or QR code, and the user's wallet can respond by proving it made the…
BIP 122: URI scheme for Blockchain references / exploration: Draft. Proposes a standard link format for referring to blocks, transactions and addresses, which software can open in any blockchain explorer the user chooses. It also lets the link specify which…
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 124: Hierarchical Deterministic Script Templates: Closed. Defines a template format that lets wallets automatically generate scripts with specific spending rules, such as multisignature, from HD wallet keys. Shared templates help different wallets produce…
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 126: Best Practices for Heterogeneous Input Script Transactions: Draft. Recommends best practices for transactions that combine coins from different addresses, which can unintentionally reveal that those addresses belong to the same person. Following these guidelines…
BIP 127: Simple Proof-of-Reserves Transactions: Complete. Standardizes a way to construct proof-of-reserves transactions, which demonstrate that someone controls a certain amount of bitcoin without actually moving it. This helps custodians such as…
BIP 128: Timelock-Recovery Storage Format: Draft. Proposes a standard file format for 'timelock recovery plans', pre-signed transactions that move funds to a backup location after a delay unless cancelled. Shared formats let one wallet create a…
BIP 129: Bitcoin Secure Multisig Setup (BSMS): Complete. Defines a step-by-step procedure for securely setting up a multisignature wallet, where several devices or people must approve spending. It helps participants verify each other's keys and confirm…
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 131: "Coalescing Transaction" Specification (wildcard inputs): Closed. Proposed a new kind of transaction that could spend all coins sent to an address at once using a single 'wildcard' input. This would make consolidating many small payments much cheaper, but would…
BIP 132: Committee-based BIP Acceptance Process: Closed. Proposed a committee-based process for deciding when a BIP is considered accepted or rejected, since the original process did not define this clearly. It aimed to give the community a more…
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 134: Flexible Transactions: Closed. Proposes a new, tag-based transaction format that would make Bitcoin transactions easier to extend with new fields later. It would also fix transaction malleability (the ability to alter a…
BIP 135: Generalized version bits voting: Closed. Extends the version-bits system miners use to signal readiness for upgrades, letting each signal have its own approval threshold, counting window, and waiting period. The aim was to give the network…
BIP 136: Bech32 Encoded Tx Position References: Draft. Defines "TxRef," a short, human-friendly code that points to a confirmed transaction by its location in the blockchain (block and position) rather than by its long ID. It uses the same…
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 138: Compact Encryption Scheme for Non-seed Wallet Data: Draft. Specifies a compact way to encrypt wallet backup details, such as descriptors (a recipe describing which addresses a wallet uses), without including any private keys. Anyone holding one of the…
BIP 140: Normalized TXID: Closed. Proposes a "normalized" transaction ID calculated without the signature data, so the ID cannot be changed by tampering with signatures. This would eliminate transaction malleability, which…
BIP 141: 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 142: Address Format for Segregated Witness: Closed. Proposed an address format for native SegWit outputs so wallets could send directly to the new transaction types. It was later replaced by the Bech32 address format (BIP 173), which became the…
BIP 143: 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 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 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 146: Dealing with signature encoding malleability: Closed. Tightens the rules on how digital signatures may be formatted, so a third party cannot slightly alter a signature's encoding and thereby change a transaction's ID. Removing this form of malleability…
BIP 147: 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 148: 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 149: Segregated Witness (second deployment): Closed. Proposed a second attempt at activating SegWit using version-bits signaling with guaranteed lock-in after a deadline. It was offered as an alternative path in case the original SegWit deployment…
BIP 150: Peer Authentication: Closed. Describes a way for Bitcoin nodes to prove their identity to trusted peers, for example so an operator can securely connect their own wallet to their own node. It is designed so that outsiders…
BIP 151: Peer-to-Peer Communication Encryption: Closed. Proposed encrypting the traffic between Bitcoin nodes so that internet providers and eavesdroppers could not easily read or tamper with it. This early design was later superseded by the version 2…
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 154: Rate Limiting via peer specified challenges: Closed. Proposes that nodes under heavy load could ask connecting peers to solve a small computational puzzle (proof of work) before receiving service. This would make it more costly for attackers to flood…
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 156: Dandelion - Privacy Enhancing Routing: Closed. Dandelion changes how new transactions travel through the network: each one is first passed quietly along a single random path before being broadcast widely. This makes it much harder for observers…
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 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 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 171: Currency/exchange rate information API: Closed. Defines a standard interface for apps to request currency exchange rates, such as the price of bitcoin in dollars or euros, from a server. A common format lets wallets switch between rate providers…
BIP 172: Define Bitcoin Subunits as Satoshis: Draft. Formally defines a "satoshi" as the smallest unit of bitcoin, one hundred-millionth of a coin, with "sats" as the standard short form. Agreeing on the name helps wallets, exchanges, and…
BIP 173: 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 174: 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 175: Pay to Contract Protocol: Closed. Describes "pay to contract," a method of deriving payment keys from a contract's contents so that a payment provably commits to a specific agreement. Built on standard wallet key derivation, it lets…
BIP 176: Bits Denomination: Complete. Proposes "bits" as the standard name for one millionth of a bitcoin (100 satoshis). The goal is to make everyday amounts easier to express without long strings of decimal places.
BIP 177: Redefine Bitcoin's Base Unit: Draft. Proposes redefining "one bitcoin" as the smallest indivisible unit, currently called a satoshi, so amounts are shown as whole numbers instead of with eight decimal places. Supporters argue this…
BIP 178: Version Extended WIF: Draft. Extends Wallet Import Format (WIF), the common text format for a single private key, to also record which address type the key belongs to. This helps wallets import a key and correctly find its…
BIP 179: Name for payment recipient identifiers: Complete. Suggests replacing the word "address" with "invoice" or "invoice address." Because Bitcoin addresses are meant to be used only once, the authors argue the new term better discourages address reuse,…
BIP 180: Block size/weight fraud proof: Closed. Describes a compact "fraud proof" that lets lightweight wallets learn that a block breaks Bitcoin's size or weight limit without downloading the whole block. This would help light clients avoid…
BIP 197: Hashed Time-Locked Collateral Contract: Draft. Describes a script for collateral-backed loans built on hashed time-locked contracts, based on the Atomic Loans design. It lets a borrower lock bitcoin as collateral for a loan with rules enforced…
BIP 199: Hashed Time-Locked Contract transactions: Closed. Defines the hashed time-locked contract (HTLC), a script where funds can be claimed by revealing a secret before a deadline or reclaimed by the sender afterward. HTLCs are a core building block for…
BIP 300: Hashrate Escrows (Consensus layer): Draft. Proposes "hashrate escrows," which would let bitcoin move to and from sidechains with withdrawals approved gradually by miners over months rather than by a trusted federation. The goal is to allow…
BIP 301: Blind Merged Mining (Consensus layer): Draft. Blind Merged Mining would let Bitcoin miners earn fees from sidechains without running any sidechain software. Sidechain users assemble blocks and bid for a miner to include a commitment to them,…
BIP 310: Stratum protocol extensions: Draft. Defines a general way to add extensions to Stratum, the protocol mining pools use to send work to miners. Its main extension allows "version rolling," letting mining hardware vary certain…
BIP 320: nVersion bits for general purpose use: Draft. Reserves 16 bits of the block header's version field for miners to use freely, removing their meaning for upgrade signaling. This formalizes a practice that helps mining hardware search for valid…
BIP 321: URI Scheme: Complete. Defines the "bitcoin:" link format that wallets use for payment requests in QR codes and clickable links. It specifies how to include an amount, label, message, and alternative payment methods, so…
BIP 322: Generic Signed Message Format: Complete. Defines a standard way to sign messages with any type of Bitcoin address, including SegWit and Taproot, not just older legacy addresses. This lets people prove they control an address or its funds…
BIP 323: 24 nVersion bits for general purpose use: Draft. Reserves 24 bits of the block header's version field as extra space miners can vary while searching for a valid block. This lets fast mining hardware keep working on just the block header without…
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 325: Signet: Complete. Defines Signet, a type of Bitcoin test network where new blocks must be signed by designated parties in addition to being mined. This gives developers a stable, predictable place to test software,…
BIP 326: Anti-fee-sniping in taproot transactions: Draft. Recommends that Taproot wallets sometimes use a transaction's sequence field, instead of its lock-time field, for their anti-fee-sniping protection (a measure discouraging miners from rewriting…
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 328: Derivation Scheme for MuSig2 Aggregate Keys: Complete. Explains how to turn a MuSig2 combined public key into a standard extended public key, so wallets can generate many fresh addresses from it. This lets groups using MuSig2 multisig manage addresses…
BIP 329: Wallet Labels Export Format: Draft. Defines a common file format for exporting wallet labels, the personal notes users attach to addresses and transactions. It lets users move these notes between wallets, preserving records that help…
BIP 330: Transaction announcements reconciliation: Draft. Specifies a method for two nodes to efficiently work out which transactions the other is missing, instead of announcing each one individually. It is a building block for Erlay, which would let nodes…
BIP 331: Ancestor Package Relay: Draft. Lets nodes request and share an unconfirmed transaction together with the parent transactions it depends on, as a single package. This helps low-fee parents get relayed when a child pays extra fees…
BIP 332: Stale Tip Relay: Draft. Defines an optional message for nodes to tell peers about recent stale blocks, valid blocks that did not end up in the main chain. Sharing them helps researchers and operators monitor mining…
BIP 337: Compressed Transactions: Draft. Proposes a compression scheme that can shrink Bitcoin transactions to less than half their usual size. This is useful when bandwidth is very limited, such as broadcasting transactions over satellite…
BIP 338: Disable transaction relay message: Closed. Adds a message letting a node tell a peer that their connection will not be used for transaction relay, only for blocks. This supports block-relay-only connections, which help protect nodes against…
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 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 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 342: 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 343: Mandatory activation of taproot deployment: Closed. Describes an alternative way to switch on Taproot in which nodes would have begun enforcing the new rules at a fixed deadline even if miners had not signaled readiness (known as 'lock-in on…
BIP 345: OP_VAULT: Closed. Proposes two new script instructions that let users lock coins in a 'vault': any withdrawal must first wait out a delay, during which the owner can redirect the coins to a pre-chosen safe recovery…
BIP 346: OP_TXHASH: Draft. Proposes a new script instruction, OP_TXHASH, that lets a script look at selected details of the transaction trying to spend it, such as its outputs or amounts. Combined with a way to check…
BIP 347: OP_CAT in Tapscript: Complete. Brings back OP_CAT, an instruction that joins two pieces of data together, which was disabled in Bitcoin's early days over security concerns. Re-enabled only inside Taproot scripts, this simple…
BIP 348: CHECKSIGFROMSTACK: Draft. Adds an instruction letting Bitcoin scripts verify a signature over any piece of data, not just over the spending transaction itself. That opens the door to things like delegating spending rights,…
BIP 349: OP_INTERNALKEY: Draft. Adds a small script instruction that places a Taproot output's 'internal key', the main key behind the output, onto the script's working data. It saves space by avoiding repeating that key inside…
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 351: Private Payments: Closed. Lets a recipient publish a single reusable "payment code" from which each sender privately derives a unique set of addresses that only the two of them can recognize. A small on-chain notification…
BIP 352: Silent Payments: Complete. Silent Payments let someone publish one static address that anyone can pay, while each payment lands at a different, unlinkable address on the blockchain. Unlike similar schemes, it needs no extra…
BIP 353: DNS Payment Instructions: Complete. Defines how to store Bitcoin payment instructions in DNS, the internet's naming system, so a person can be paid via a human-readable name such as an email-like address. Security extensions to DNS…
BIP 360: Pay-to-Merkle-Root (P2MR): Draft. Proposes a new output type, Pay-to-Merkle-Root, that works like Taproot but removes the option to spend directly with a single public key. Since only hashes are exposed until spending, coins in…
BIP 361: Post Quantum Migration and Legacy Signature Sunset: Draft. Outlines a phased plan, once a quantum-resistant address type exists, to retire today's signature types. First, sending coins to quantum-vulnerable addresses would be blocked; later, after a…
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 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 372: Pay-to-contract tweak fields for PSBT: Draft. Adds fields to the Partially Signed Bitcoin Transaction (PSBT) format for 'pay-to-contract' data, extra information used when a key has been mathematically adjusted to commit to some contract or…
BIP 373: MuSig2 PSBT Fields: Complete. Extends the Partially Signed Bitcoin Transaction (PSBT) format so it can carry the data needed for MuSig2, a method where several people jointly produce one ordinary-looking signature. This makes it…
BIP 374: Discrete Log Equality Proofs: Draft. Standardizes a short cryptographic proof that someone used the same secret key in two related calculations, without revealing the key itself. This is useful, for example, to prove that a shared…
BIP 375: Sending Silent Payments with PSBTs: Draft. Adds fields and rules to the version 2 Partially Signed Bitcoin Transaction (PSBT) format so wallets can send to Silent Payment addresses. Since a Silent Payment's final address depends on the…
BIP 376: Spending Silent Payment outputs with PSBTs: Draft. Adds fields to version 2 Partially Signed Bitcoin Transactions (PSBTs) for spending coins received via Silent Payments. Those coins require a special adjustment to the recipient's key when signing,…
BIP 379: Miniscript: Draft. Miniscript is a structured way of writing Bitcoin scripts, the small programs that define how coins can be spent. It lets software analyze spending conditions, combine them safely, and sign for them…
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 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 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 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 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 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 386: 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 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 388: Wallet Policies for Descriptor Wallets: Complete. Wallet policies are a compact, human-reviewable way of describing an 'account' in a wallet, built on top of output descriptors. They are designed especially for hardware wallets with small screens,…
BIP 389: Multipath Descriptor Key Expressions: Draft. Extends descriptors so one key expression can represent several related derivation paths at once, such as a wallet's receiving and change addresses. This shortens wallet backups and avoids having to…
BIP 390: musig() Descriptor Key Expression: Draft. Adds a 'musig()' expression to descriptors, which combines several people's public keys into a single shared key using the MuSig2 method. The resulting coins look like an ordinary single-key payment…
BIP 391: Binary Output Descriptors: Closed. Proposes a compact binary format for storing and transferring output descriptors, the text descriptions of a wallet's addresses. It can also carry extra information about the descriptor and its…
BIP 392: Silent Payment Output Script Descriptors: Draft. Defines an 'sp()' descriptor for Silent Payment wallets, describing the keys needed to detect and spend payments sent to a reusable Silent Payment address. This lets such wallets be backed up and…
BIP 393: Output Script Descriptor Annotations: Draft. Introduces optional tags that can be attached to a descriptor, such as the block height to start scanning from or how many unused addresses to check. These hints speed up and simplify wallet…
BIP 431: Topology Restrictions for Pinning: Draft. Explains 'pinning', a problem where someone can block a transaction from being replaced with a higher-fee version, which can endanger time-sensitive protocols like Lightning. It describes stricter…
BIP 433: Pay to Anchor (P2A): Draft. Defines Pay to Anchor, a tiny standard output that anyone can spend without a signature. Its purpose is to act as a hook for fee-bumping: by spending it in a follow-up transaction, any party can add…
BIP 434: Peer Feature Negotiation: Complete. Defines a peer-to-peer message that nodes can exchange while first connecting, to announce and agree on support for new network features. This gives a cleaner, uniform way to roll out future…
BIP 440: Varops Budget For Script Runtime Constraint: Draft. Proposes a 'varops budget' that caps how much computational work a script may do, based on the size of the transaction, extending the existing limit on signature checks to all operations. It is…
BIP 441: Restoration of disabled script (Tapleaf 0xC2): Draft. Proposes a new Taproot script version that restores many of Bitcoin's original script instructions disabled in 2010 and greatly loosens limits on data size. To avoid the denial-of-service risks that…
BIP 442: OP_PAIRCOMMIT: Draft. Proposes OP_PAIRCOMMIT, a script instruction that combines two pieces of data into a single secure fingerprint (hash). This compact way of committing to data could make certain smart contracts and…
BIP 443: OP_CHECKCONTRACTVERIFY: Draft. Proposes OP_CHECKCONTRACTVERIFY, an instruction that lets coins carry embedded data and restrict where they can be sent next and with what data. This lets users build multi-step contracts, such as…
BIP 446: OP_TEMPLATEHASH: Draft. Proposes OP_TEMPLATEHASH, a Taproot script instruction that produces a fingerprint of the transaction spending a coin. Scripts can use it to require that coins be spent only in a specific pre-agreed…
BIP 448: Taproot-native (Re)bindable Transactions: Draft. Bundles three small script instructions, OP_TEMPLATEHASH, OP_CHECKSIGFROMSTACK and OP_INTERNALKEY, into a single proposed upgrade. Together they would let transactions commit to specific future…
BIP 449: OP_TWEAKADD - x-only key tweak addition: Draft. Proposes OP_TWEAKADD, a script instruction that adjusts a public key by adding a given number to it, mirroring the 'tweak' technique Taproot already uses. It would let scripts verifiably derive new…
BIP 450: Formosa—Seed encoding by themed mnemonic stories: Draft. Formosa is an alternative way of writing a wallet's backup phrase as short themed sentences instead of a list of unrelated words. The sentences are designed to be easier to remember while remaining…
BIP 451: Dust UTXO Disposal Protocol: Draft. Specifies a standard way for wallets to get rid of 'dust', tiny unwanted amounts often sent to track users, by spending them entirely as miner fees. Doing so carefully, without mixing the dust with…
BIP 461: Deterministic ECDSA Signatures: Draft. Specifies a way of producing ECDSA signatures, Bitcoin's original signature type, where the result depends only on the private key and the message, removing reliance on a good random number source.…