# BIP Explorer

> A guide to every Bitcoin Improvement Proposal (BIP): plain-English summaries, status, authors, topics and the full specification text, generated from the official github.com/bitcoin/bips repository. 213 proposals: 78 deployed, 22 complete, 56 draft, 57 closed.

Statuses follow BIP 3 (2025): Draft (being written), Complete (finished, awaiting adoption), Deployed (live / in use), Closed (withdrawn, rejected or replaced). Types: Specification, Informational, Process. Data last refreshed 2026-10-12.

Every BIP page has a Markdown version: append `.md` to the URL, e.g. https://bipexplorer.com/bip/341.md.

## Machine access

- [MCP server](https://bipexplorer.com/mcp): Model Context Protocol endpoint (Streamable HTTP). Tools: search_bips, get_bip, list_bips, list_topics, get_stats.
- [OpenAPI description](https://bipexplorer.com/openapi.json): JSON API (/api/search?q=, /api/bips, /api/bips/{number}, /api/topics, /api/stats).
- [All BIPs as JSON](https://bipexplorer.com/data/bips.json): metadata, summary and abstract for every BIP.
- [Full text of every BIP](https://bipexplorer.com/llms-full.txt): all specifications as one Markdown file.

## BIPs

- [BIP 1: BIP Purpose and Guidelines](https://bipexplorer.com/bip/1.md): 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 way to suggest and…
- [BIP 2: BIP process, revised](https://bipexplorer.com/bip/2.md): 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 from idea to accepted…
- [BIP 3: Updated BIP Process](https://bipexplorer.com/bip/3.md): 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 contributors and…
- [BIP 8: Version bits with lock-in by height](https://bipexplorer.com/bip/8.md): 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 end of the signaling…
- [BIP 9: Version bits with timeout and delay](https://bipexplorer.com/bip/9.md): 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 signal within a period,…
- [BIP 10: Multi-Sig Transaction Distribution](https://bipexplorer.com/bip/10.md): 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 coordination, and a shared…
- [BIP 11: M-of-N Standard Transactions](https://bipexplorer.com/bip/11.md): 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 three keys to spend.
- [BIP 12: OP_EVAL](https://bipexplorer.com/bip/12.md): 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 Pay to Script Hash…
- [BIP 13: Address Format for pay-to-script-hash](https://bipexplorer.com/bip/13.md): 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 easily as paying an…
- [BIP 14: Protocol Version and User Agent](https://bipexplorer.com/bip/14.md): 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 kept the protocol…
- [BIP 15: Aliases](https://bipexplorer.com/bip/15.md): 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; the payment protocol…
- [BIP 16: Pay to Script Hash](https://bipexplorer.com/bip/16.md): 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 multisig from…
- [BIP 17: OP_CHECKHASHVERIFY (CHV)](https://bipexplorer.com/bip/17.md): 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 was not adopted.
- [BIP 18: hashScriptCheck](https://bipexplorer.com/bip/18.md): 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 spending conditions but…
- [BIP 19: M-of-N Standard Transactions (Low SigOp)](https://bipexplorer.com/bip/19.md): 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 became available.
- [BIP 20: URI Scheme](https://bipexplorer.com/bip/20.md): 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](https://bipexplorer.com/bip/21.md): 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, reducing…
- [BIP 22: getblocktemplate - Fundamentals](https://bipexplorer.com/bip/22.md): 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, reducing reliance on a…
- [BIP 23: getblocktemplate - Pooled Mining](https://bipexplorer.com/bip/23.md): 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 sharing rewards.
- [BIP 30: Duplicate transactions](https://bipexplorer.com/bip/30.md): 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 unspendable, which had…
- [BIP 31: Pong message](https://bipexplorer.com/bip/31.md): 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](https://bipexplorer.com/bip/32.md): 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 accountant, without giving…
- [BIP 33: Stratized Nodes](https://bipexplorer.com/bip/33.md): 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 large for everyone…
- [BIP 34: Block v2, Height in Coinbase](https://bipexplorer.com/bip/34.md): 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 transactions, and set a…
- [BIP 35: mempool message](https://bipexplorer.com/bip/35.md): 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 waiting to be confirmed.
- [BIP 36: Custom Services](https://bipexplorer.com/bip/36.md): 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 network features…
- [BIP 37: Connection Bloom filtering](https://bipexplorer.com/bip/37.md): 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, though it was later found…
- [BIP 38: Passphrase-protected private key](https://bipexplorer.com/bip/38.md): 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 cannot spend without…
- [BIP 39: Mnemonic code for generating deterministic keys](https://bipexplorer.com/bip/39.md): 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 across wallets.
- [BIP 42: A finite monetary supply for Bitcoin](https://bipexplorer.com/bip/42.md): 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 limit holds permanently…
- [BIP 43: Purpose Field for Deterministic Wallets](https://bipexplorer.com/bip/43.md): 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 recognize how a wallet is…
- [BIP 44: Multi-Account Hierarchy for Deterministic Wallets](https://bipexplorer.com/bip/44.md): 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 usually be restored in…
- [BIP 45: Structure for Deterministic P2SH Multisignature Wallets](https://bipexplorer.com/bip/45.md): 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 keys for every…
- [BIP 46: Address Scheme for Timelocked Fidelity Bonds](https://bipexplorer.com/bip/46.md): 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 coinjoin markets,…
- [BIP 47: Reusable Payment Codes for Hierarchical Deterministic Wallets](https://bipexplorer.com/bip/47.md): 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 payment that only the…
- [BIP 48: Multi-Script Hierarchy for Multi-Sig Wallets](https://bipexplorer.com/bip/48.md): 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 live, so setups can…
- [BIP 49: Derivation scheme for P2WPKH-nested-in-P2SH based accounts](https://bipexplorer.com/bip/49.md): 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 could not yet send to…
- [BIP 50: March 2013 Chain Fork Post-Mortem](https://bipexplorer.com/bip/50.md): 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 resolved it, and lessons…
- [BIP 52: Durable, Low Energy Bitcoin PoW](https://bipexplorer.com/bip/52.md): 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 out mining, but it…
- [BIP 53: Disallow 64-byte transactions](https://bipexplorer.com/bip/53.md): 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 summarizing its…
- [BIP 54: Consensus Cleanup](https://bipexplorer.com/bip/54.md): 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 flaws, and duplicate…
- [BIP 60: Fixed Length "version" Message (Relay-Transactions Field)](https://bipexplorer.com/bip/60.md): 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 parsing ambiguous for…
- [BIP 61: Reject P2P message](https://bipexplorer.com/bip/61.md): 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](https://bipexplorer.com/bip/62.md): 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 the issue more…
- [BIP 64: getutxo message](https://bipexplorer.com/bip/64.md): 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 verified.
- [BIP 65: OP_CHECKLOCKTIMEVERIFY](https://bipexplorer.com/bip/65.md): 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 those used by the…
- [BIP 66: Strict DER signatures](https://bipexplorer.com/bip/66.md): 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 transactions be altered in…
- [BIP 67: Deterministic Pay-to-script-hash multi-signature addresses through public key sorting](https://bipexplorer.com/bip/67.md): 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 agreeing on key order.
- [BIP 68: Relative lock-time using consensus-enforced sequence numbers](https://bipexplorer.com/bip/68.md): 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 channels such as…
- [BIP 69: Lexicographical Indexing of Transaction Inputs and Outputs](https://bipexplorer.com/bip/69.md): 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 order reduces that…
- [BIP 70: Payment Protocol](https://bipexplorer.com/bip/70.md): 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 Bitcoin Core later…
- [BIP 71: Payment Protocol MIME types](https://bipexplorer.com/bip/71.md): 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](https://bipexplorer.com/bip/72.md): 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 older wallets fall back…
- [BIP 73: Use "Accept" header for response type negotiation with Payment Request URLs](https://bipexplorer.com/bip/73.md): 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 browsers and wallets.
- [BIP 74: Allow zero value OP_RETURN in Payment Protocol](https://bipexplorer.com/bip/74.md): 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 payment requests ask for…
- [BIP 75: Out of Band Address Exchange using Payment Protocol Encryption](https://bipexplorer.com/bip/75.md): 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 through an…
- [BIP 77: Async Payjoin](https://bipexplorer.com/bip/77.md): 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 messages between them,…
- [BIP 78: A Simple Payjoin Proposal](https://bipexplorer.com/bip/78.md): 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 by blockchain…
- [BIP 79: Bustapay :: a practical coinjoin protocol](https://bipexplorer.com/bip/79.md): 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 assumption that all…
- [BIP 80: Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets](https://bipexplorer.com/bip/80.md): 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 standards BIP 32, 43 and…
- [BIP 81: Hierarchy for Colored Voting Pool Deterministic Multisig Wallets](https://bipexplorer.com/bip/81.md): 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 common layout lets…
- [BIP 83: Dynamic Hierarchical Deterministic Key Trees](https://bipexplorer.com/bip/83.md): 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 while still…
- [BIP 84: Derivation scheme for P2WPKH based accounts](https://bipexplorer.com/bip/84.md): 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 apps and find the…
- [BIP 85: Deterministic Entropy From BIP32 Keychains](https://bipexplorer.com/bip/85.md): 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, without those child…
- [BIP 86: Key Derivation for Single Key P2TR Outputs](https://bipexplorer.com/bip/86.md): 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 restore the same Taproot…
- [BIP 87: Hierarchy for Deterministic Multisig Wallets](https://bipexplorer.com/bip/87.md): 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 easier for different…
- [BIP 88: Hierarchical Deterministic Path Templates](https://bipexplorer.com/bip/88.md): 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 quickly tell legitimate…
- [BIP 89: Chain Code Delegation](https://bipexplorer.com/bip/89.md): 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. Co-signers, such as a…
- [BIP 90: Buried Deployments](https://bipexplorer.com/bip/90.md): 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 rules have long been…
- [BIP 91: Reduced threshold Segwit MASF](https://bipexplorer.com/bip/91.md): 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 SegWit, pushing the…
- [BIP 93: codex32: Checksummed SSSS-aware BIP32 seeds](https://bipexplorer.com/bip/93.md): 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 seed into several…
- [BIP 94: Testnet 4](https://bipexplorer.com/bip/94.md): 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 the network cheaply…
- [BIP 95: Testnet 5](https://bipexplorer.com/bip/95.md): 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 54 consensus…
- [BIP 98: Fast Merkle Trees](https://bipexplorer.com/bip/98.md): 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 fixes known…
- [BIP 99: Motivation and deployment of consensus rule changes ([soft/hard]forks)](https://bipexplorer.com/bip/99.md): 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 be rolled out so…
- [BIP 100: Dynamic maximum block size by miner vote](https://bipexplorer.com/bip/100.md): 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 of several…
- [BIP 101: Increase maximum block size](https://bipexplorer.com/bip/101.md): 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 technology improves; it…
- [BIP 102: Block size increase to 2MB](https://bipexplorer.com/bip/102.md): 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 fork, and it was one…
- [BIP 103: Block size following technological growth](https://bipexplorer.com/bip/103.md): 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 ordinary users to run…
- [BIP 104: 'Block75' - Max block size like difficulty](https://bipexplorer.com/bip/104.md): 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, letting capacity grow or…
- [BIP 105: Consensus based block size retargeting algorithm](https://bipexplorer.com/bip/105.md): 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 contentious…
- [BIP 106: Dynamically Controlled Bitcoin Block Size Max Cap](https://bipexplorer.com/bip/106.md): 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 capacity to demand…
- [BIP 107: Dynamic limit on the block size](https://bipexplorer.com/bip/107.md): 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 might later need…
- [BIP 109: Two million byte size limit with sigop and sighash limits](https://bipexplorer.com/bip/109.md): 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 2016 Bitcoin Classic…
- [BIP 110: Reduced Data Temporary Softfork](https://bipexplorer.com/bip/110.md): 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 non-financial data,…
- [BIP 111: NODE_BLOOM service bit](https://bipexplorer.com/bip/111.md): 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 service, which has…
- [BIP 112: CHECKSEQUENCEVERIFY](https://bipexplorer.com/bip/112.md): 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 for the Lightning…
- [BIP 113: Median time-past as endpoint for lock-time calculations](https://bipexplorer.com/bip/113.md): 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 cannot game timestamps…
- [BIP 114: Merkelized Abstract Syntax Tree](https://bipexplorer.com/bip/114.md): 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 unused options, an idea…
- [BIP 115: Generic anti-replay protection using Script](https://bipexplorer.com/bip/115.md): 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 chain from being copied…
- [BIP 116: MERKLEBRANCHVERIFY](https://bipexplorer.com/bip/116.md): 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 condition actually used,…
- [BIP 117: Tail Call Execution Semantics](https://bipexplorer.com/bip/117.md): 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 while revealing only the…
- [BIP 118: SIGHASH_ANYPREVOUT for Taproot Scripts](https://bipexplorer.com/bip/118.md): 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 enable designs such as…
- [BIP 119: CHECKTEMPLATEVERIFY](https://bipexplorer.com/bip/119.md): 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 against theft,…
- [BIP 120: Proof of Payment](https://bipexplorer.com/bip/120.md): 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, such as a ticket,…
- [BIP 121: Proof of Payment URI scheme](https://bipexplorer.com/bip/121.md): 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 relevant payment.
- [BIP 122: URI scheme for Blockchain references / exploration](https://bipexplorer.com/bip/122.md): 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 blockchain is meant,…
- [BIP 123: BIP Classification](https://bipexplorer.com/bip/123.md): 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 proposal must be adopted…
- [BIP 124: Hierarchical Deterministic Script Templates](https://bipexplorer.com/bip/124.md): 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 matching addresses…
- [BIP 125: Opt-in Full Replace-by-Fee Signaling](https://bipexplorer.com/bip/125.md): 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 its fee was too low.
- [BIP 126: Best Practices for Heterogeneous Input Script Transactions](https://bipexplorer.com/bip/126.md): 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 reduces how much…
- [BIP 127: Simple Proof-of-Reserves Transactions](https://bipexplorer.com/bip/127.md): 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 exchanges show their…
- [BIP 128: Timelock-Recovery Storage Format](https://bipexplorer.com/bip/128.md): 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 plan and another…
- [BIP 129: Bitcoin Secure Multisig Setup (BSMS)](https://bipexplorer.com/bip/129.md): 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 they have all created…
- [BIP 130: sendheaders message](https://bipexplorer.com/bip/130.md): 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 blocks spread across…
- [BIP 131: "Coalescing Transaction" Specification (wildcard inputs)](https://bipexplorer.com/bip/131.md): 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 have required a hard…
- [BIP 132: Committee-based BIP Acceptance Process](https://bipexplorer.com/bip/132.md): 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 structured and transparent…
- [BIP 133: feefilter message](https://bipexplorer.com/bip/133.md): 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 anyway.
- [BIP 134: Flexible Transactions](https://bipexplorer.com/bip/134.md): 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 transaction's ID before…
- [BIP 135: Generalized version bits voting](https://bipexplorer.com/bip/135.md): 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 more flexible,…
- [BIP 136: Bech32 Encoded Tx Position References](https://bipexplorer.com/bip/136.md): 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 error-catching Bech32 encoding as…
- [BIP 137: Signatures of Messages using Private Keys](https://bipexplorer.com/bip/137.md): 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 wallets produce and…
- [BIP 138: Compact Encryption Scheme for Non-seed Wallet Data](https://bipexplorer.com/bip/138.md): 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 wallet's keys can decrypt…
- [BIP 140: Normalized TXID](https://bipexplorer.com/bip/140.md): 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 complicates tracking payments…
- [BIP 141: Segregated Witness (Consensus layer)](https://bipexplorer.com/bip/141.md): 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, effectively increased…
- [BIP 142: Address Format for Segregated Witness](https://bipexplorer.com/bip/142.md): 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 standard for addresses…
- [BIP 143: Transaction Signature Verification for Version 0 Witness Program](https://bipexplorer.com/bip/143.md): 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 spent, which helps…
- [BIP 144: Segregated Witness (Peer Services)](https://bipexplorer.com/bip/144.md): 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 nodes can still receive…
- [BIP 145: getblocktemplate Updates for Segregated Witness](https://bipexplorer.com/bip/145.md): 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 and their separate…
- [BIP 146: Dealing with signature encoding malleability](https://bipexplorer.com/bip/146.md): 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 makes it more…
- [BIP 147: Dealing with dummy stack element malleability](https://bipexplorer.com/bip/147.md): 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 more way third parties…
- [BIP 148: Mandatory activation of segwit deployment](https://bipexplorer.com/bip/148.md): 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 activation in 2017…
- [BIP 149: Segregated Witness (second deployment)](https://bipexplorer.com/bip/149.md): 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 failed to gain enough…
- [BIP 150: Peer Authentication](https://bipexplorer.com/bip/150.md): 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 cannot use the…
- [BIP 151: Peer-to-Peer Communication Encryption](https://bipexplorer.com/bip/151.md): 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 encrypted transport in…
- [BIP 152: Compact Block Relay](https://bipexplorer.com/bip/152.md): 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 greatly reduces…
- [BIP 154: Rate Limiting via peer specified challenges](https://bipexplorer.com/bip/154.md): 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 a node with fake…
- [BIP 155: addrv2 message](https://bipexplorer.com/bip/155.md): 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 connect privately.
- [BIP 156: Dandelion - Privacy Enhancing Routing](https://bipexplorer.com/bip/156.md): 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 to trace a…
- [BIP 157: Client Side Block Filtering](https://bipexplorer.com/bip/157.md): 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 approach, the wallet…
- [BIP 158: Compact Block Filters for Light Clients](https://bipexplorer.com/bip/158.md): 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 whether a block…
- [BIP 159: NODE_NETWORK_LIMITED service bit](https://bipexplorer.com/bip/159.md): 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 while making clear…
- [BIP 171: Currency/exchange rate information API](https://bipexplorer.com/bip/171.md): 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 without custom code…
- [BIP 172: Define Bitcoin Subunits as Satoshis](https://bipexplorer.com/bip/172.md): 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 documentation describe small…
- [BIP 173: Base32 address format for native v0-16 witness outputs](https://bipexplorer.com/bip/173.md): 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 mistakes, making…
- [BIP 174: Partially Signed Bitcoin Transaction Format](https://bipexplorer.com/bip/174.md): 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 transaction back and…
- [BIP 175: Pay to Contract Protocol](https://bipexplorer.com/bip/175.md): 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 merchants and…
- [BIP 176: Bits Denomination](https://bipexplorer.com/bip/176.md): 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](https://bipexplorer.com/bip/177.md): 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 matches how the ledger…
- [BIP 178: Version Extended WIF](https://bipexplorer.com/bip/178.md): 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 funds without guessing…
- [BIP 179: Name for payment recipient identifiers](https://bipexplorer.com/bip/179.md): 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, which harms privacy.
- [BIP 180: Block size/weight fraud proof](https://bipexplorer.com/bip/180.md): 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 trusting an invalid…
- [BIP 197: Hashed Time-Locked Collateral Contract](https://bipexplorer.com/bip/197.md): 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 by Bitcoin itself,…
- [BIP 199: Hashed Time-Locked Contract transactions](https://bipexplorer.com/bip/199.md): 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 the Lightning…
- [BIP 300: Hashrate Escrows (Consensus layer)](https://bipexplorer.com/bip/300.md): 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 new kinds of…
- [BIP 301: Blind Merged Mining (Consensus layer)](https://bipexplorer.com/bip/301.md): 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, giving miners extra…
- [BIP 310: Stratum protocol extensions](https://bipexplorer.com/bip/310.md): 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 block-header bits to search…
- [BIP 320: nVersion bits for general purpose use](https://bipexplorer.com/bip/320.md): 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 blocks more…
- [BIP 321: URI Scheme](https://bipexplorer.com/bip/321.md): 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 scanning a code opens…
- [BIP 322: Generic Signed Message Format](https://bipexplorer.com/bip/322.md): 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 in a format that…
- [BIP 323: 24 nVersion bits for general purpose use](https://bipexplorer.com/bip/323.md): 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 changing the timestamp…
- [BIP 324: Version 2 P2P Encrypted Transport Protocol](https://bipexplorer.com/bip/324.md): 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 and makes future…
- [BIP 325: Signet](https://bipexplorer.com/bip/325.md): 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, avoiding the erratic…
- [BIP 326: Anti-fee-sniping in taproot transactions](https://bipexplorer.com/bip/326.md): 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 recent blocks). Making…
- [BIP 327: MuSig2 for BIP340-compatible Multi-Signatures](https://bipexplorer.com/bip/327.md): 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 private, since…
- [BIP 328: Derivation Scheme for MuSig2 Aggregate Keys](https://bipexplorer.com/bip/328.md): 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 the same way ordinary…
- [BIP 329: Wallet Labels Export Format](https://bipexplorer.com/bip/329.md): 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 with bookkeeping and…
- [BIP 330: Transaction announcements reconciliation](https://bipexplorer.com/bip/330.md): 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 keep more…
- [BIP 331: Ancestor Package Relay](https://bipexplorer.com/bip/331.md): 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 to speed them up,…
- [BIP 332: Stale Tip Relay](https://bipexplorer.com/bip/332.md): 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 activity and network health.
- [BIP 337: Compressed Transactions](https://bipexplorer.com/bip/337.md): 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 or radio links.
- [BIP 338: Disable transaction relay message](https://bipexplorer.com/bip/338.md): 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 attacks that try to…
- [BIP 339: WTXID-based transaction relay](https://bipexplorer.com/bip/339.md): 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 ignored that data,…
- [BIP 340: Schnorr Signatures for secp256k1](https://bipexplorer.com/bip/340.md): 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 bytes) and allow…
- [BIP 341: Taproot: SegWit version 1 spending rules](https://bipexplorer.com/bip/341.md): 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 structure until used. As…
- [BIP 342: Validation of Taproot Scripts](https://bipexplorer.com/bip/342.md): 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 limits, and reserves…
- [BIP 343: Mandatory activation of taproot deployment](https://bipexplorer.com/bip/343.md): 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 timeout'). It was intended…
- [BIP 345: OP_VAULT](https://bipexplorer.com/bip/345.md): 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 address. This gives…
- [BIP 346: OP_TXHASH](https://bipexplorer.com/bip/346.md): 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 signatures over arbitrary…
- [BIP 347: OP_CAT in Tapscript](https://bipexplorer.com/bip/347.md): 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 building block could…
- [BIP 348: CHECKSIGFROMSTACK](https://bipexplorer.com/bip/348.md): 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, using signed messages…
- [BIP 349: OP_INTERNALKEY](https://bipexplorer.com/bip/349.md): 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 scripts, and is…
- [BIP 350: Bech32m format for v1+ witness addresses](https://bipexplorer.com/bip/350.md): 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 is used for Taproot…
- [BIP 351: Private Payments](https://bipexplorer.com/bip/351.md): 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 starts the…
- [BIP 352: Silent Payments](https://bipexplorer.com/bip/352.md): 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 notification…
- [BIP 353: DNS Payment Instructions](https://bipexplorer.com/bip/353.md): 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 allow the instructions…
- [BIP 360: Pay-to-Merkle-Root (P2MR)](https://bipexplorer.com/bip/360.md): 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 these outputs would be…
- [BIP 361: Post Quantum Migration and Legacy Signature Sunset](https://bipexplorer.com/bip/361.md): 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 publicized deadline,…
- [BIP 370: PSBT Version 2](https://bipexplorer.com/bip/370.md): 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 added after the file…
- [BIP 371: Taproot Fields for PSBT](https://bipexplorer.com/bip/371.md): 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 understand and sign…
- [BIP 372: Pay-to-contract tweak fields for PSBT](https://bipexplorer.com/bip/372.md): 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 message. Signing…
- [BIP 373: MuSig2 PSBT Fields](https://bipexplorer.com/bip/373.md): 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 practical for…
- [BIP 374: Discrete Log Equality Proofs](https://bipexplorer.com/bip/374.md): 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 secret was computed…
- [BIP 375: Sending Silent Payments with PSBTs](https://bipexplorer.com/bip/375.md): 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 sender's inputs, this…
- [BIP 376: Spending Silent Payment outputs with PSBTs](https://bipexplorer.com/bip/376.md): 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, and these fields…
- [BIP 379: Miniscript](https://bipexplorer.com/bip/379.md): 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 automatically,…
- [BIP 380: Output Script Descriptors General Operation](https://bipexplorer.com/bip/380.md): 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 wallets a standard way…
- [BIP 381: Non-Segwit Output Script Descriptors](https://bipexplorer.com/bip/381.md): 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 '3'). This lets…
- [BIP 382: Segwit Output Script Descriptors](https://bipexplorer.com/bip/382.md): 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 multisig setups.
- [BIP 383: Multisig Output Script Descriptors](https://bipexplorer.com/bip/383.md): 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 helps different…
- [BIP 384: combo() Output Script Descriptors](https://bipexplorer.com/bip/384.md): 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 formats, for example when…
- [BIP 385: raw() and addr() Output Script Descriptors](https://bipexplorer.com/bip/385.md): 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 without knowing the…
- [BIP 386: tr() Output Script Descriptors](https://bipexplorer.com/bip/386.md): 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 Taproot wallets.
- [BIP 387: Tapscript Multisig Output Script Descriptors](https://bipexplorer.com/bip/387.md): 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 them, helping…
- [BIP 388: Wallet Policies for Descriptor Wallets](https://bipexplorer.com/bip/388.md): 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, letting users verify…
- [BIP 389: Multipath Descriptor Key Expressions](https://bipexplorer.com/bip/389.md): 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 store nearly…
- [BIP 390: musig() Descriptor Key Expression](https://bipexplorer.com/bip/390.md): 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 on-chain, and this…
- [BIP 391: Binary Output Descriptors](https://bipexplorer.com/bip/391.md): 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 keys, making it suitable…
- [BIP 392: Silent Payment Output Script Descriptors](https://bipexplorer.com/bip/392.md): 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 restored using the…
- [BIP 393: Output Script Descriptor Annotations](https://bipexplorer.com/bip/393.md): 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 recovery without changing…
- [BIP 431: Topology Restrictions for Pinning](https://bipexplorer.com/bip/431.md): 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 limits on how…
- [BIP 433: Pay to Anchor (P2A)](https://bipexplorer.com/bip/433.md): 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 fees to get a stuck…
- [BIP 434: Peer Feature Negotiation](https://bipexplorer.com/bip/434.md): 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 upgrades to how Bitcoin…
- [BIP 440: Varops Budget For Script Runtime Constraint](https://bipexplorer.com/bip/440.md): 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 meant as a safety…
- [BIP 441: Restoration of disabled script (Tapleaf 0xC2)](https://bipexplorer.com/bip/441.md): 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 prompted the…
- [BIP 442: OP_PAIRCOMMIT](https://bipexplorer.com/bip/442.md): 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 second-layer…
- [BIP 443: OP_CHECKCONTRACTVERIFY](https://bipexplorer.com/bip/443.md): 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 vaults, where each…
- [BIP 446: OP_TEMPLATEHASH](https://bipexplorer.com/bip/446.md): 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 way, a building…
- [BIP 448: Taproot-native (Re)bindable Transactions](https://bipexplorer.com/bip/448.md): 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 spends or be re-bound to…
- [BIP 449: OP_TWEAKADD - x-only key tweak addition](https://bipexplorer.com/bip/449.md): 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 keys on the fly…
- [BIP 450: Formosa—Seed encoding by themed mnemonic stories](https://bipexplorer.com/bip/450.md): 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 fully compatible…
- [BIP 451: Dust UTXO Disposal Protocol](https://bipexplorer.com/bip/451.md): 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 other coins,…
- [BIP 461: Deterministic ECDSA Signatures](https://bipexplorer.com/bip/461.md): 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. The method also…

## Optional

- [About BIPs and this site](https://bipexplorer.com/about)
- [Topics](https://bipexplorer.com/categories)
- [Authors](https://bipexplorer.com/authors)