Home › Browse › Closed BIPs

Closed BIPs

A BIP is Closed when it is no longer being pursued: its author withdrew it, it was abandoned or rejected, or a newer BIP replaced it. Under BIP 3 this status replaced Deferred, Obsolete, Rejected, Replaced and Withdrawn.

Closed BIPs are still worth reading: they record ideas Bitcoin considered, like the 2015 to 2017 block size proposals, and many were replaced by the designs in use today.

57 proposals.

  • 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 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 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 343 (Taproot UASF): 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 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 199 (HTLC): 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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…

Other statuses: Deployed BIPs · Complete BIPs · Draft BIPs