[{"number":1,"title":"BIP Purpose and Guidelines","authors":["Amir Taaki"],"status":"Closed","type":"Process","created":"2011-09-19","requires":[],"replaces":[],"replacedBy":[2],"discussion":[],"abstract":"What is a BIP? BIP stands for Bitcoin Improvement Proposal. A BIP is a design document providing information to the Bitcoin community, or describing a new feature for Bitcoin or its processes or environment. The BIP should provide a concise technical specification of the feature and a rationale for the feature. We intend BIPs to be the primary mechanisms for proposing new features, for collecting ","eli5":"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 record changes to Bitcoin.","categories":["governance","process","foundational"],"filename":"bip-0001.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0001.mediawiki","format":"mediawiki","readingMinutes":12,"inbound":3,"revisions":37,"impact":86,"core":false,"references":[],"lastModified":"2026-05-20"},{"number":2,"title":"BIP process, revised","authors":["Luke Dashjr"],"status":"Closed","type":"Process","created":"2016-02-03","license":"BSD-2-Clause OR OPUBL-1.0","requires":[],"replaces":[1],"replacedBy":[3],"discussion":[],"abstract":"A Bitcoin Improvement Proposal (BIP) is a design document providing information to the Bitcoin community, or describing a new feature for Bitcoin or its processes or environment. The BIP should provide a concise technical specification of the feature and a rationale for the feature. We intend BIPs to be the primary mechanisms for proposing new features, for collecting community input on an issue, and for documenting the design decisions that have gone into Bitcoin. The BIP author is responsible for building consensus within the community and documenting dissenting opinions. Because the BIPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal. This particular BIP replaces BIP 1 with a more well-defined and clear process.","eli5":"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 standard more predictable.","categories":["governance","process","foundational"],"filename":"bip-0002.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki","format":"mediawiki","readingMinutes":24,"inbound":2,"revisions":69,"impact":91,"core":false,"references":[1,123],"lastModified":"2026-02-27"},{"number":3,"title":"Updated BIP Process","authors":["Murch"],"status":"Deployed","type":"Process","created":"2025-01-09","license":"BSD-2-Clause","version":"1.4.0","requires":[123],"replaces":[2],"replacedBy":[],"discussion":["https://github.com/murchandamus/bips/pull/2","https://gnusha.org/pi/bitcoindev/59fa94cea6f70e02b1ce0da07ae230670730171c.camel@timruffing.de/#t"],"abstract":"This Bitcoin Improvement Proposal (BIP) provides information about the preparation of BIPs and policies relating to the publication of BIPs. It replaces BIP 2 with a streamlined process, and may be amended to address the evolving needs of the BIP process.","eli5":"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 proposals grows.","categories":["process"],"filename":"bip-0003.md","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0003.md","format":"markdown","readingMinutes":36,"inbound":2,"revisions":53,"impact":87,"core":false,"references":[1,2,50],"lastModified":"2026-08-09"},{"number":8,"title":"Version bits with lock-in by height","authors":["Shaolin Fry","Luke Dashjr"],"status":"Complete","type":"Informational","created":"2017-02-01","license":"BSD-3-Clause OR CC0-1.0","version":"1.0.0","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This document specifies an alternative to BIP9 that corrects for a number of perceived mistakes. Block heights are used for start and timeout rather than POSIX timestamps. It additionally introduces an activation parameter that can guarantee activation of backward-compatible changes (further called \"soft forks\"). The key words \"MUST\", \"MUST NOT\", \"REQUIRED\", \"SHALL\", \"SHALL NOT\", \"SHOULD\", \"SHOULD NOT\", \"RECOMMENDED\", \"MAY\", and \"OPTIONAL\" in this document are to be interpreted as described in RFC 2119.","eli5":"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 window even if miners do not signal support.","categories":["activation","soft-fork","versioning"],"filename":"bip-0008.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0008.mediawiki","format":"mediawiki","readingMinutes":12,"inbound":3,"revisions":44,"impact":87,"core":false,"references":[9],"lastModified":"2026-08-05"},{"number":9,"title":"Version bits with timeout and delay","authors":["Pieter Wuille","Peter Todd","Greg Maxwell","Rusty Russell"],"status":"Deployed","type":"Informational","created":"2015-10-04","license":"PD","requires":[],"replaces":[],"replacedBy":[135],"discussion":[],"abstract":"This document specifies a proposed change to the semantics of the 'version' field in Bitcoin blocks, allowing multiple backward-compatible changes (further called \"soft forks\") to be deployed in parallel. It relies on interpreting the version field as a bit vector, where each bit can be used to track an independent change. These are tallied each retarget period. Once the consensus change succeeds or times out, there is a \"fallow\" pause after which the bit can be reused for later changes.","eli5":"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, or expires after a timeout; SegWit was activated this way.","categories":["activation","soft-fork","versioning"],"filename":"bip-0009.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki","format":"mediawiki","readingMinutes":9,"inbound":11,"revisions":57,"impact":98,"core":true,"references":[16,34,65,66,68,112,113,141],"lastModified":"2025-10-08"},{"number":10,"title":"Multi-Sig Transaction Distribution","authors":["Alan Reiner"],"status":"Closed","type":"Informational","layer":"Applications","created":"2011-10-28","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"A multi-signature transaction is one where a certain number of Bitcoins are \"encumbered\" with more than one recipient address. The subsequent transaction that spends these coins will require each party involved (or some subset, depending on the script), to see the proposed transaction and sign it with their private key. This necessarily requires collaboration between all parties -- to propose a di","eli5":"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 format lets different software cooperate.","categories":["multisig","scripts"],"filename":"bip-0010.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0010.mediawiki","format":"mediawiki","readingMinutes":5,"inbound":1,"revisions":28,"impact":65,"core":false,"references":[],"lastModified":"2026-09-13"},{"number":11,"title":"M-of-N Standard Transactions","authors":["Gavin Andresen"],"status":"Deployed","type":"Specification","layer":"Applications","created":"2011-10-18","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This BIP proposes M-of-N-signatures required transactions as a new 'standard' transaction type.","eli5":"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.","categories":["transactions","multisig","scripts"],"filename":"bip-0011.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0011.mediawiki","format":"mediawiki","readingMinutes":3,"inbound":5,"revisions":20,"impact":89,"core":true,"references":[],"lastModified":"2025-10-08"},{"number":12,"title":"OP_EVAL","authors":["Gavin Andresen"],"status":"Closed","type":"Specification","layer":"Consensus (soft fork)","created":"2011-10-18","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This BIP describes a new opcode (OP_EVAL) for the Bitcoin scripting system , and a new 'standard' transaction type that uses it to enables the receiver of bitcoins to specify the transaction type needed to re-spend them.","eli5":"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 16).","categories":["transactions","opcodes","scripts"],"filename":"bip-0012.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0012.mediawiki","format":"mediawiki","readingMinutes":4,"inbound":2,"revisions":18,"impact":73,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":13,"title":"Address Format for pay-to-script-hash","authors":["Gavin Andresen"],"status":"Deployed","type":"Specification","layer":"Applications","created":"2011-10-18","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This BIP describes a new type of Bitcoin address to support arbitrarily complex transactions. Complexity in this context is defined as what information is needed by the recipient to respend the received coins, in contrast to needing a single ECDSA private key as in current implementations of Bitcoin. In essence, an address encoded under this proposal represents the encoded hash of a script , rather than the encoded hash of an ECDSA public key.","eli5":"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 ordinary address.","categories":["addresses","p2sh","scripts"],"filename":"bip-0013.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0013.mediawiki","format":"mediawiki","readingMinutes":2,"inbound":5,"revisions":19,"impact":88,"core":false,"references":[12,16,17],"lastModified":"2025-10-08"},{"number":14,"title":"Protocol Version and User Agent","authors":["Amir Taaki","Patrick Strateman"],"status":"Deployed","type":"Specification","layer":"Peer Services","created":"2011-11-10","requires":[],"replaces":[],"replacedBy":[],"discussion":["https://gnusha.org/pi/bitcoindev/1320268981.72296.YahooMailNeo@web121003.mail.ne1.yahoo.com/","https://gnusha.org/pi/bitcoindev/1320959761.36702.YahooMailNeo@web121014.mail.ne1.yahoo.com/"],"abstract":"In this document, bitcoin will be used to refer to the protocol while Satoshi will refer to the current client in order to prevent confusion. Past Situation Bitcoin as a protocol began life with the Satoshi client. Now that the community is diversifying, a number of alternative clients with their own codebases written in a variety of languages (Java, Python, Javascript, C++) are rapidly developing","eli5":"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 independent of a single implementation.","categories":["network","versioning"],"filename":"bip-0014.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0014.mediawiki","format":"mediawiki","readingMinutes":5,"inbound":2,"revisions":20,"impact":75,"core":false,"references":[],"lastModified":"2026-01-16"},{"number":15,"title":"Aliases","authors":["Amir Taaki"],"status":"Closed","type":"Specification","layer":"Applications","created":"2011-12-10","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"BIP 0070 (payment protocol) may be seen as the alternative to Aliases. Using vanilla bitcoin, to send funds to a destination, an address in the form 1Hd44nkJfNAcPJeZyrGC5sKJS1TzgmCTjjZ is needed. The problem with using addresses is that they are not easy to remember. An analogy can be thought if one were required to enter the IP address of their favourite websites if domain names did not exist. Th","eli5":"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 70) was later seen as an alternative.","categories":["addresses"],"filename":"bip-0015.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0015.mediawiki","format":"mediawiki","readingMinutes":12,"inbound":1,"revisions":20,"impact":57,"core":false,"references":[70],"lastModified":"2025-10-08"},{"number":16,"title":"Pay to Script Hash","authors":["Gavin Andresen"],"status":"Deployed","type":"Specification","layer":"Consensus (soft fork)","created":"2012-01-03","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This BIP describes a new \"standard\" transaction type for the Bitcoin scripting system, and defines additional validation rules that apply only to the new transactions.","eli5":"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 senders to receivers.","categories":["transactions","p2sh","scripts"],"filename":"bip-0016.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki","format":"mediawiki","readingMinutes":5,"inbound":13,"revisions":23,"impact":97,"core":true,"references":[11,13],"lastModified":"2025-10-08"},{"number":17,"title":"OP_CHECKHASHVERIFY (CHV)","authors":["Luke Dashjr"],"status":"Closed","type":"Specification","layer":"Consensus (soft fork)","created":"2012-01-18","license":"BSD-2-Clause","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This BIP describes a new opcode (OP_CHECKHASHVERIFY) for the Bitcoin scripting system, and a new 'standard' transaction type that uses it to enables the receiver of bitcoins to specify the transaction type needed to re-spend them.","eli5":"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.","categories":["scripts","opcodes"],"filename":"bip-0017.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0017.mediawiki","format":"mediawiki","readingMinutes":4,"inbound":2,"revisions":16,"impact":69,"core":false,"references":[11,13],"lastModified":"2025-10-08"},{"number":18,"title":"hashScriptCheck","authors":["Luke Dashjr"],"status":"Complete","type":"Specification","layer":"Consensus (soft fork)","created":"2012-01-27","license":"BSD-2-Clause","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This BIP modifies the basic format of transaction inputs and outputs, replacing the current scriptSig and scriptPubKey (scripts executed to validate a transaction) with new contents: dataSig, scriptCheck, and hashScriptCheck.","eli5":"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 was not the approach the network took.","categories":["scripts","opcodes"],"filename":"bip-0018.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0018.mediawiki","format":"mediawiki","readingMinutes":6,"inbound":1,"revisions":12,"impact":41,"core":false,"references":[11,13,16],"lastModified":"2025-10-08"},{"number":19,"title":"M-of-N Standard Transactions (Low SigOp)","authors":["Luke Dashjr"],"status":"Closed","type":"Specification","layer":"Applications","created":"2012-01-30","license":"BSD-2-Clause","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This BIP proposes M-of-N-signatures required transactions as a new 'standard' transaction type using the existing scripting system without significant modifications.","eli5":"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.","categories":["multisig","scripts"],"filename":"bip-0019.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0019.mediawiki","format":"mediawiki","readingMinutes":2,"inbound":1,"revisions":15,"impact":51,"core":false,"references":[11],"lastModified":"2025-10-08"},{"number":20,"title":"URI Scheme","authors":["Luke Dashjr"],"status":"Closed","type":"Specification","layer":"Applications","created":"2011-01-10","license":"BSD-2-Clause","requires":[],"replaces":[],"replacedBy":[21],"discussion":[],"abstract":"This BIP proposes a URI scheme for making Bitcoin payments.","eli5":"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.","categories":["payments"],"filename":"bip-0020.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0020.mediawiki","format":"mediawiki","readingMinutes":5,"inbound":2,"revisions":18,"impact":73,"core":false,"references":[],"lastModified":"2026-02-27"},{"number":21,"title":"URI Scheme","authors":["Nils Schneider","Matt Corallo"],"status":"Closed","type":"Specification","layer":"Applications","created":"2012-01-29","requires":[],"replaces":[20],"replacedBy":[321],"discussion":[],"abstract":"This BIP proposes a URI scheme for making Bitcoin payments.","eli5":"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 copy-and-paste mistakes.","categories":["payments","uri","usability"],"filename":"bip-0021.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki","format":"mediawiki","readingMinutes":4,"inbound":5,"revisions":39,"impact":92,"core":false,"references":[20,321],"lastModified":"2026-02-27"},{"number":22,"title":"getblocktemplate - Fundamentals","authors":["Luke Dashjr"],"status":"Deployed","type":"Specification","layer":"API/RPC","created":"2012-02-28","license":"BSD-2-Clause","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This BIP describes a new JSON-RPC method for \"smart\" Bitcoin miners and proxies. Instead of sending a simple block header for hashing, the entire block structure is sent, and left to the miner to (optionally) customize and assemble.","eli5":"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 pool operator's choices.","categories":["mining","rpc","pools"],"filename":"bip-0022.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0022.mediawiki","format":"mediawiki","readingMinutes":8,"inbound":3,"revisions":19,"impact":81,"core":false,"references":[16,23,34],"lastModified":"2026-02-27"},{"number":23,"title":"getblocktemplate - Pooled Mining","authors":["Luke Dashjr"],"status":"Deployed","type":"Specification","layer":"API/RPC","created":"2012-02-28","license":"BSD-2-Clause","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This BIP describes extensions to the getblocktemplate JSON-RPC call to enhance pooled mining.","eli5":"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.","categories":["mining","rpc","pools"],"filename":"bip-0023.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0023.mediawiki","format":"mediawiki","readingMinutes":8,"inbound":3,"revisions":15,"impact":78,"core":false,"references":[22],"lastModified":"2026-02-27"},{"number":30,"title":"Duplicate transactions","authors":["Pieter Wuille"],"status":"Deployed","type":"Specification","layer":"Consensus (soft fork)","created":"2012-02-22","license":"BSD-2-Clause","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This document gives a specification for dealing with duplicate transactions in the block chain, in an attempt to solve certain problems the reference implementation has with them.","eli5":"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 already happened twice.","categories":["consensus","blocks","mining"],"filename":"bip-0030.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki","format":"mediawiki","readingMinutes":3,"inbound":3,"revisions":19,"impact":81,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":31,"title":"Pong message","authors":["Mike Hearn"],"status":"Deployed","type":"Specification","layer":"Peer Services","created":"2012-04-11","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This document describes a trivial protocol extension that makes it easier for clients to detect dead peer connections.","eli5":"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.","categories":["network","transactions"],"filename":"bip-0031.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0031.mediawiki","format":"mediawiki","readingMinutes":2,"inbound":1,"revisions":14,"impact":49,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":32,"title":"Hierarchical Deterministic Wallets","authors":["Pieter Wuille"],"status":"Deployed","type":"Informational","layer":"Applications","created":"2012-02-11","license":"BSD-2-Clause","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This document describes hierarchical deterministic wallets (or \"HD Wallets\"): wallets which can be shared partially or entirely with different systems, each with or without the ability to spend coins. The specification is intended to set a standard for deterministic wallets that can be interchanged between different clients. Although the wallets described here have many features, not all are required by supporting clients. The specification consists of two parts. In the first part, a system for deriving a tree of keypairs from a single seed is presented. The second part demonstrates how to build a wallet structure on top of such a tree.","eli5":"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 away the ability to spend.","categories":["wallets","keys","hd-wallets","derivation"],"filename":"bip-0032.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki","format":"mediawiki","readingMinutes":16,"inbound":26,"revisions":59,"impact":100,"core":true,"references":[],"lastModified":"2026-03-05"},{"number":33,"title":"Stratized Nodes","authors":["Amir Taaki"],"status":"Closed","type":"Specification","layer":"Peer Services","created":"2012-05-15","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"As the Bitcoin network scales, roles are fast becoming specialised. In the beginning, a single Bitcoin user would perform the synonymous roles of miner, merchant and end-user. With the growth however of this system, these functions are being abstracted away to specialised services as a natural part of Bitcoin's growth. Bitcoin's blockchain becomes more unwieldy for end users over time, negatively affecting the usability of Bitcoin clients. As it grows, it becomes ever more impractical to deal with on portable devices or low end machines. Several proposals have been put forward to deal with this such as lightweight (headers-only) clients and skipping validation for blocks before the last checkpoint. However these measures are at best stop-gap workarounds to stave off a growing problem. This document will examine a proposal which will be termed stratized nodes , a modification of an earlier concept termed blockchain service .","eli5":"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 to store.","categories":["network"],"filename":"bip-0033.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0033.mediawiki","format":"mediawiki","readingMinutes":4,"inbound":1,"revisions":13,"impact":46,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":34,"title":"Block v2, Height in Coinbase","authors":["Gavin Andresen"],"status":"Deployed","type":"Specification","layer":"Consensus (soft fork)","created":"2012-07-06","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"Bitcoin blocks and transactions are versioned binary structures. Both currently use version 1. This BIP introduces an upgrade path for versioned transactions and blocks. A unique value is added to newly produced coinbase transactions, and blocks are updated to version 2.","eli5":"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 pattern for rolling out later upgrades.","categories":["consensus","blocks","validation"],"filename":"bip-0034.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki","format":"mediawiki","readingMinutes":1,"inbound":4,"revisions":16,"impact":85,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":35,"title":"mempool message","authors":["Jeff Garzik"],"status":"Deployed","type":"Specification","layer":"Peer Services","created":"2012-08-16","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"Make a network node's transaction memory pool accessible via a new \"mempool\" message. Extend the existing \"getdata\" message behavior to permit accessing the transaction memory pool.","eli5":"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.","categories":["network","mempool"],"filename":"bip-0035.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0035.mediawiki","format":"mediawiki","readingMinutes":1,"inbound":1,"revisions":14,"impact":49,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":36,"title":"Custom Services","authors":["Stefan Thomas"],"status":"Closed","type":"Specification","layer":"Peer Services","created":"2012-08-03","license":"PD","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This BIP adds new fields to the version message which clients can use to announce custom services without polluting the limited 64-bit services field. It also makes some non-binding recommendations regarding the implementation of custom services.","eli5":"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 alongside the standard ones.","categories":["network"],"filename":"bip-0036.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0036.mediawiki","format":"mediawiki","readingMinutes":6,"inbound":1,"revisions":12,"impact":41,"core":false,"references":[],"lastModified":"2026-02-27"},{"number":37,"title":"Connection Bloom filtering","authors":["Mike Hearn","Matt Corallo"],"status":"Deployed","type":"Specification","layer":"Peer Services","created":"2012-10-24","license":"PD","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"comments":"https://github.com/bitcoin/bips/wiki/Comments:BIP-0037","abstract":"This BIP adds new support to the peer-to-peer protocol that allows peers to reduce the amount of transaction data they are sent. Peers have the option of setting filters on each connection they make after the version handshake has completed. A filter is defined as a Bloom filter on data derived from transactions. A Bloom filter is a probabilistic data structure which allows for testing set membership - they can have false positives but not false negatives. This document will not go into the details of how Bloom filters work and the reader is referred to Wikipedia for an introduction to the topic.","eli5":"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 to leak considerable privacy.","categories":["network","addresses"],"filename":"bip-0037.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki","format":"mediawiki","readingMinutes":13,"inbound":2,"revisions":16,"impact":69,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":38,"title":"Passphrase-protected private key","authors":["Mike Caldwell","Aaron Voisine"],"status":"Deployed","type":"Specification","layer":"Applications","created":"2012-11-20","license":"PD","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"comments":"https://github.com/bitcoin/bips/wiki/Comments:BIP-0038","abstract":"A method is proposed for encrypting and encoding a passphrase-protected Bitcoin private key record in the form of a 58-character Base58Check-encoded printable string. Encrypted private key records are intended for use on paper wallets and physical Bitcoins. Each record string contains all the information needed to reconstitute the private key except for a passphrase, and the methodology uses salting and scrypt to resist brute-force attacks. The method provides two encoding methodologies - one permitting any known private key to be encrypted with any passphrase, and another permitting a shared private key generation scheme where the party generating the final key string and its associated Bitcoin address (such as a physical bitcoin manufacturer) knows only a string derived from the original passphrase, and where the original passphrase is needed in order to actually redeem funds sent to the associated Bitcoin address. A 32-bit hash of the resulting Bitcoin address is encoded in plaintext within each encrypted key, so it can be correlated to a Bitcoin address with reasonable probability by someone not knowing the passphrase. The complete Bitcoin address can be derived through successful decryption of the key record.","eli5":"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 the passphrase.","categories":["standards","process"],"filename":"bip-0038.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0038.mediawiki","format":"mediawiki","readingMinutes":20,"inbound":1,"revisions":31,"impact":69,"core":false,"references":[],"lastModified":"2026-05-20"},{"number":39,"title":"Mnemonic code for generating deterministic keys","authors":["Marek Palatinus","Pavol Rusnak","Aaron Voisine","Sean Bowe"],"status":"Deployed","type":"Specification","layer":"Applications","created":"2013-09-10","license":"MIT","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This BIP describes the implementation of a mnemonic code or mnemonic sentence -- a group of easy to remember words -- for the generation of deterministic wallets. It consists of two parts: generating the mnemonic and converting it into a binary seed. This seed can be later used to generate deterministic wallets using BIP-0032 or similar methods.","eli5":"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.","categories":["wallets","mnemonics","backup"],"filename":"bip-0039.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki","format":"mediawiki","readingMinutes":5,"inbound":2,"revisions":85,"impact":92,"core":true,"references":[],"lastModified":"2026-05-31"},{"number":42,"title":"A finite monetary supply for Bitcoin","authors":["Pieter Wuille"],"status":"Deployed","type":"Specification","layer":"Consensus (soft fork)","created":"2014-04-01","license":"PD","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"comments":"https://github.com/bitcoin/bips/wiki/Comments:BIP-0042","abstract":"Although it is widely believed that Satoshi was an inflation-hating goldbug he never said this, and in fact programmed Bitcoin's money supply to grow indefinitely, forever. He modeled the monetary supply as 4 gold mines being discovered per mibillennium (1024 years), with equal intervals between them, each one being depleted over the course of 140 years. This poses obvious problems, however. Prominent among them is the discussion on what to call 1 billion bitcoin, which symbol color to use for it, and when wallet clients should switch to it by default. To combat this, this document proposes a controversial change: making Bitcoin's monetary supply finite.","eli5":"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 rather than only for a long time.","categories":["consensus","validation"],"filename":"bip-0042.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0042.mediawiki","format":"mediawiki","readingMinutes":3,"inbound":1,"revisions":14,"impact":49,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":43,"title":"Purpose Field for Deterministic Wallets","authors":["Marek Palatinus","Pavol Rusnak"],"status":"Deployed","type":"Specification","layer":"Applications","created":"2014-04-24","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This BIP introduces a \"Purpose Field\" for use in deterministic wallets based on algorithm described in BIP-0032 (BIP32 from now on).","eli5":"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 organized.","categories":["wallets","hd-wallets","derivation"],"filename":"bip-0043.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki","format":"mediawiki","readingMinutes":1,"inbound":12,"revisions":17,"impact":96,"core":true,"references":[32],"lastModified":"2025-10-08"},{"number":44,"title":"Multi-Account Hierarchy for Deterministic Wallets","authors":["Marek Palatinus","Pavol Rusnak"],"status":"Deployed","type":"Specification","layer":"Applications","created":"2014-04-24","requires":[32,43],"replaces":[],"replacedBy":[],"discussion":[],"comments":"https://github.com/bitcoin/bips/wiki/Comments:BIP-0044","abstract":"This BIP defines a logical hierarchy for deterministic wallets based on an algorithm described in BIP-0032 (BIP32 from now on) and purpose scheme described in BIP-0043 (BIP43 from now on). This BIP is a particular application of BIP43.","eli5":"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 another.","categories":["wallets","hd-wallets","multi-coin","derivation"],"filename":"bip-0044.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki","format":"mediawiki","readingMinutes":5,"inbound":12,"revisions":31,"impact":97,"core":true,"references":[],"lastModified":"2026-02-27"},{"number":45,"title":"Structure for Deterministic P2SH Multisignature Wallets","authors":["Manuel Araoz","Ryan X. Charles","Matias Alejo Garcia"],"status":"Complete","type":"Specification","layer":"Applications","created":"2014-04-25","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This BIP defines a structure for hierarchical deterministic P2SH multi-party multi-signature wallets (HDPM wallets from now on) based on the algorithm described in BIP-0032 (BIP32 from now on) and purpose scheme described in BIP-0043 (BIP43 from now on). This BIP is a particular application of BIP43.","eli5":"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 payment.","categories":["wallets","hd-wallets","derivation","multisig"],"filename":"bip-0045.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0045.mediawiki","format":"mediawiki","readingMinutes":6,"inbound":1,"revisions":15,"impact":51,"core":false,"references":[32,43],"lastModified":"2025-10-08"},{"number":46,"title":"Address Scheme for Timelocked Fidelity Bonds","authors":["Chris Belcher","Thebora Kompanioni"],"status":"Draft","type":"Specification","layer":"Applications","created":"2022-04-01","license":"CC0-1.0","requires":[],"replaces":[],"replacedBy":[],"discussion":["https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020389.html"],"abstract":"This BIP defines the derivation scheme for HD wallets which create timelocked addresses used for creating fidelity bonds. It also gives advice to wallet developers on how to use fidelity bonds to sign over messages, such as certificates, which are needed when using fidelity bonds that are stored offline.","eli5":"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, and the proposal covers signing messages for bonds kept offline.","categories":["wallets","addresses"],"filename":"bip-0046.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0046.mediawiki","format":"mediawiki","readingMinutes":7,"inbound":0,"revisions":31,"impact":54,"core":false,"references":[32,44,49,65,84,86],"lastModified":"2026-02-27"},{"number":47,"title":"Reusable Payment Codes for Hierarchical Deterministic Wallets","authors":["Justus Ranvier"],"status":"Deployed","type":"Specification","layer":"Applications","created":"2015-04-24","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This BIP defines a technique for creating a payment code which can be publicly advertised and associated with a real-life identity without creating the loss of security or privacy inherent to P2PKH address reuse. This BIP is a particular application of BIP43 and is intended to supplement HD wallets which implement BIP44. The key words \"MUST\", \"MUST NOT\", \"REQUIRED\", \"SHALL\", \"SHALL NOT\", \"SHOULD\", \"SHOULD NOT\", \"RECOMMENDED\", \"MAY\", and \"OPTIONAL\" in this document are to be interpreted as described in RFC 2119.","eli5":"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 recipient can recognize.","categories":["privacy","transactions"],"filename":"bip-0047.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0047.mediawiki","format":"mediawiki","readingMinutes":15,"inbound":2,"revisions":38,"impact":83,"core":false,"references":[32,43,44],"lastModified":"2026-07-23"},{"number":48,"title":"Multi-Script Hierarchy for Multi-Sig Wallets","authors":["Fontaine"],"status":"Deployed","type":"Specification","layer":"Applications","created":"2020-12-16","license":"MIT","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This BIP defines a logical hierarchy for deterministic multi-sig wallets based on an algorithm described in BIP-0067 (BIP67 from now on), BIP-0032 (BIP32 from now on), purpose scheme described in BIP-0043 (BIP43 from now on), and multi-account hierarchy described in BIP-0044 (BIP44 from now on). This BIP is a particular application of BIP43.","eli5":"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 be recovered consistently.","categories":["wallets"],"filename":"bip-0048.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0048.mediawiki","format":"mediawiki","readingMinutes":4,"inbound":1,"revisions":32,"impact":72,"core":false,"references":[32,43,44,67],"lastModified":"2025-10-08"},{"number":49,"title":"Derivation scheme for P2WPKH-nested-in-P2SH based accounts","authors":["Daniel Weigl"],"status":"Deployed","type":"Specification","layer":"Applications","created":"2016-05-19","license":"PD","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"comments":"https://github.com/bitcoin/bips/wiki/Comments:BIP-0049","abstract":"This BIP defines the derivation scheme for HD wallets using the P2WPKH-nested-in-P2SH ( BIP 141 ) serialization format for segregated witness transactions.","eli5":"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 native SegWit addresses.","categories":["wallets","derivation","hd-wallets"],"filename":"bip-0049.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0049.mediawiki","format":"mediawiki","readingMinutes":3,"inbound":5,"revisions":18,"impact":88,"core":false,"references":[16,32,43,44,141],"lastModified":"2025-10-08"},{"number":50,"title":"March 2013 Chain Fork Post-Mortem","authors":["Gavin Andresen"],"status":"Deployed","type":"Informational","created":"2013-03-20","license":"PD","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"What went wrong A block that had a larger number of total transaction inputs than previously seen was mined and broadcasted. Bitcoin 0.8 nodes were able to handle this, but some pre-0.8 Bitcoin nodes rejected it, causing an unexpected fork of the blockchain. The pre-0.8-incompatible chain (from here on, the 0.8 chain) at that point had around 60% of the mining hash power ensuring the split did not","eli5":"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 for avoiding similar accidental splits.","categories":["consensus","blocks","security"],"filename":"bip-0050.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki","format":"mediawiki","readingMinutes":5,"inbound":2,"revisions":12,"impact":62,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":52,"title":"Durable, Low Energy Bitcoin PoW","authors":["Michael Dubrovsky","Bogdan Penkovsky"],"status":"Closed","type":"Specification","layer":"Consensus (hard fork)","created":"2021-05-13","license":"BSD-2-Clause OR OPUBL-1.0","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"As Bitcoin gained utility and value over the preceding decade, the network incentivized the purchase of billions of dollars in mining equipment and electricity. With the growth of competition, home mining became unprofitable. Even the most sophisticated special-purpose hardware (ASIC miners) doesn’t cover its energy costs unless the miner also has direct access to very cheap electricity. This heavy reliance on energy makes it difficult for new miners to enter the market and leads to hashrate instability as miners shut off their machines when the price of Bitcoin falls. Additionally as the network stores ever more value, the percentage of world energy consumption that is associated with Bitcoin continues to grow, creating the potential for scaling failure and a general backlash. To ensure that Bitcoin can continue scaling and reach its full potential as a world currency and store of value, we propose a low-energy proof-of-work paradigm for Bitcoin. Optical proof of work (oPoW) is designed to decouple Bitcoin’s security from massive energy use and make bitcoin mining feasible outside of regions with low electricity costs. Optical proof-of-work is a modification of Hashcash that is most efficiently computed using a new class of photonic processors that has emerged as a leading solution for ultra-low energy computing over the last 5 years. oPoW shifts the operating expenses of mining (OPEX), to capital expenses (CAPEX)–i.e. electricity to hardware, without compromising the cryptographic or game-theoretical security of Hashcash. We provide an example implementation of oPoW, briefly discuss its cryptographic construction as well as the working principle of photonic processors. Additionally, we outline the potential benefits of oPoW to the bitcoin network, including geographic decentralization and democratization of mining as well as hashrate resilience to price fluctuations.","eli5":"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 required a hard fork (a rule change incompatible with existing software).","categories":["payments","mining"],"filename":"bip-0052.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0052.mediawiki","format":"mediawiki","readingMinutes":14,"inbound":0,"revisions":15,"impact":25,"core":false,"references":[],"lastModified":"2026-05-20"},{"number":53,"title":"Disallow 64-byte transactions","authors":["Chris Stewart"],"status":"Draft","type":"Specification","layer":"Consensus (soft fork)","created":"2025-04-11","license":"BSD-3-Clause","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This BIP describes the rationale for disallowing transactions that are serialized to 64 bytes without the transaction's witness. We describe the weaknesses to the Merkle tree included in Bitcoin block headers, and various exploits for those weaknesses.","eli5":"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 transactions, which could be used to deceive lightweight wallets.","categories":["transactions"],"filename":"bip-0053.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0053.mediawiki","format":"mediawiki","readingMinutes":7,"inbound":0,"revisions":7,"impact":10,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":54,"title":"Consensus Cleanup","authors":["Antoine Poinsot","Matt Corallo"],"status":"Complete","type":"Specification","layer":"Consensus (soft fork)","created":"2025-04-11","license":"CC0-1.0","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This document proposes new consensus rules in order to fix the timewarp attack, reduce the worst case block validation time, prevent Merkle tree weaknesses, and avoid duplicate transactions without bip-0030 validation.","eli5":"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 transactions. Together these soft-fork rule changes make the network more robust against rare but real attacks.","categories":["consensus","transactions"],"filename":"bip-0054.md","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0054.md","format":"markdown","readingMinutes":11,"inbound":1,"revisions":30,"impact":67,"core":false,"references":[],"lastModified":"2026-10-02"},{"number":60,"title":"Fixed Length \"version\" Message (Relay-Transactions Field)","authors":["Amir Taaki"],"status":"Closed","type":"Specification","layer":"Peer Services","created":"2013-06-16","license":"PD","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"comments":"https://github.com/bitcoin/bips/wiki/Comments:BIP-0060","abstract":"BIP 0037 introduced a new flag to version messages which says whether to relay new transaction messages to that node. The protocol version was upgraded to 70001, and the (now accepted) BIP 0037 became implemented. The implementation is problematic because the RelayTransactions flag is an optional part of the version message stream.","eli5":"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 some software.","categories":["network","transactions"],"filename":"bip-0060.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0060.mediawiki","format":"mediawiki","readingMinutes":2,"inbound":1,"revisions":12,"impact":41,"core":false,"references":[14,37],"lastModified":"2025-10-08"},{"number":61,"title":"Reject P2P message","authors":["Gavin Andresen"],"status":"Deployed","type":"Specification","layer":"Peer Services","created":"2014-06-18","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"comments":"https://github.com/bitcoin/bips/wiki/Comments:BIP-0061","abstract":"This BIP describes a new message type for the Bitcoin peer-to-peer network.","eli5":"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.","categories":["network","transactions"],"filename":"bip-0061.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0061.mediawiki","format":"mediawiki","readingMinutes":3,"inbound":1,"revisions":12,"impact":41,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":62,"title":"Dealing with malleability","authors":["Pieter Wuille"],"status":"Closed","type":"Specification","layer":"Consensus (soft fork)","created":"2014-03-12","license":"BSD-2-Clause","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This document specifies proposed changes to the Bitcoin transaction validity rules in order to make malleability of transactions impossible (at least when the sender doesn't choose to avoid it).","eli5":"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 thoroughly.","categories":["consensus","transactions","security","validation"],"filename":"bip-0062.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki","format":"mediawiki","readingMinutes":7,"inbound":3,"revisions":20,"impact":82,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":64,"title":"getutxo message","authors":["Mike Hearn"],"status":"Closed","type":"Specification","layer":"Peer Services","created":"2014-06-10","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This document describes a small P2P protocol extension that performs UTXO lookups given a set of outpoints.","eli5":"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.","categories":["network"],"filename":"bip-0064.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0064.mediawiki","format":"mediawiki","readingMinutes":4,"inbound":1,"revisions":10,"impact":34,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":65,"title":"OP_CHECKLOCKTIMEVERIFY","authors":["Peter Todd"],"status":"Deployed","type":"Specification","layer":"Consensus (soft fork)","created":"2014-10-01","license":"PD","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This BIP describes a new opcode (OP_CHECKLOCKTIMEVERIFY) for the Bitcoin scripting system that allows a transaction output to be made unspendable until some point in the future.","eli5":"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 Lightning Network.","categories":["time-locks","scripts","consensus"],"filename":"bip-0065.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki","format":"mediawiki","readingMinutes":8,"inbound":6,"revisions":38,"impact":94,"core":true,"references":[],"lastModified":"2025-10-08"},{"number":66,"title":"Strict DER signatures","authors":["Pieter Wuille"],"status":"Deployed","type":"Specification","layer":"Consensus (soft fork)","created":"2015-01-10","license":"BSD-2-Clause","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This document specifies proposed changes to the Bitcoin transaction validity rules to restrict signatures to strict DER encoding.","eli5":"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 transit.","categories":["consensus","blocks","security"],"filename":"bip-0066.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki","format":"mediawiki","readingMinutes":5,"inbound":4,"revisions":15,"impact":85,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":67,"title":"Deterministic Pay-to-script-hash multi-signature addresses through public key sorting","authors":["Thomas Kerin","Jean-Pierre Rupp","Ruben de Vries"],"status":"Complete","type":"Specification","layer":"Applications","created":"2015-02-08","license":"PD","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This BIP describes a method to deterministically generate multi-signature pay-to-script-hash transaction scripts. It focuses on defining how the public keys must be encoded and sorted so that the redeem script and corresponding P2SH address are always the same for a given set of keys and number of required signatures.","eli5":"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.","categories":["wallets","keys","derivation","multisig"],"filename":"bip-0067.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0067.mediawiki","format":"mediawiki","readingMinutes":3,"inbound":2,"revisions":25,"impact":75,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":68,"title":"Relative lock-time using consensus-enforced sequence numbers","authors":["Mark Friedenbach","BtcDrak","Nicolas Dorier","kinoshitajona"],"status":"Deployed","type":"Specification","layer":"Consensus (soft fork)","created":"2015-05-28","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This BIP introduces relative lock-time (RLT) consensus-enforced semantics of the sequence number field to enable a signed transaction input to remain invalid for a defined period of time after confirmation of its corresponding outpoint.","eli5":"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 the Lightning Network.","categories":["sequence","time-locks","lightning"],"filename":"bip-0068.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki","format":"mediawiki","readingMinutes":8,"inbound":4,"revisions":36,"impact":90,"core":true,"references":[],"lastModified":"2026-05-28"},{"number":69,"title":"Lexicographical Indexing of Transaction Inputs and Outputs","authors":["Kristov Atlas"],"status":"Complete","type":"Informational","layer":"Applications","created":"2015-06-12","license":"PD","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"Currently there is no standard for bitcoin wallet clients when ordering transaction inputs and outputs. As a result, wallet clients often have a discernible blockchain fingerprint, and can leak private information about their users. By contrast, a standard for non-deterministic sorting could be difficult to audit. This document proposes deterministic lexicographical sorting, using hashes of previous transactions and output indices to sort transaction inputs, as well as values and scriptPubKeys to sort transaction outputs.","eli5":"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 privacy leak.","categories":["privacy","addresses"],"filename":"bip-0069.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0069.mediawiki","format":"mediawiki","readingMinutes":6,"inbound":2,"revisions":31,"impact":79,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":70,"title":"Payment Protocol","authors":["Gavin Andresen","Mike Hearn"],"status":"Deployed","type":"Specification","layer":"Applications","created":"2013-07-29","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This BIP describes a protocol for communication between a merchant and their customer, enabling both a better customer experience and better security against man-in-the-middle attacks on the payment process.","eli5":"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 dropped support over complexity and privacy concerns.","categories":["payments","transactions"],"filename":"bip-0070.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki","format":"mediawiki","readingMinutes":10,"inbound":5,"revisions":41,"impact":92,"core":true,"references":[71,72],"lastModified":"2025-10-08"},{"number":71,"title":"Payment Protocol MIME types","authors":["Gavin Andresen"],"status":"Deployed","type":"Specification","layer":"Applications","created":"2013-07-29","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This BIP defines a MIME (RFC 2046) Media Type for Bitcoin payment request messages.","eli5":"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.","categories":["payments","contracts"],"filename":"bip-0071.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0071.mediawiki","format":"mediawiki","readingMinutes":1,"inbound":2,"revisions":11,"impact":61,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":72,"title":"bitcoin: uri extensions for Payment Protocol","authors":["Gavin Andresen"],"status":"Deployed","type":"Specification","layer":"Applications","created":"2013-07-29","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This BIP describes an extension to the bitcoin: URI scheme (BIP 21) to support the payment protocol (BIP 70).","eli5":"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 to the plain address.","categories":["payments","uri"],"filename":"bip-0072.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0072.mediawiki","format":"mediawiki","readingMinutes":1,"inbound":2,"revisions":16,"impact":69,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":73,"title":"Use \"Accept\" header for response type negotiation with Payment Request URLs","authors":["Stephen Pair"],"status":"Deployed","type":"Specification","layer":"Applications","created":"2013-08-27","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This BIP describes an enhancement to the payment protocol ( BIP 70 ) that addresses the need for short URLs when scanning from QR codes. It generalizes the specification for the behavior of a payment request URL in a way that allows the client and server to negotiate the content of the response using the HTTP Accept: header field. Specifically, the client can indicate to the server whether it prefers to receive a bitcoin URI or a payment request. Implementation of this BIP does not require full payment request ( BIP 70 ) support.","eli5":"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.","categories":["payments","uri"],"filename":"bip-0073.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0073.mediawiki","format":"mediawiki","readingMinutes":3,"inbound":1,"revisions":11,"impact":37,"core":false,"references":[70],"lastModified":"2025-10-08"},{"number":74,"title":"Allow zero value OP_RETURN in Payment Protocol","authors":["Toby Padilla"],"status":"Closed","type":"Specification","layer":"Applications","created":"2016-01-29","license":"PD","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"comments":"https://github.com/bitcoin/bips/wiki/Comments:BIP-0074","abstract":"This BIP alters the Payment Protocol to allow for zero value OP_RETURN outputs in serialized PaymentRequests.","eli5":"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 data to be recorded on the blockchain without forcing the payer to send funds to an unspendable output.","categories":["consensus"],"filename":"bip-0074.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0074.mediawiki","format":"mediawiki","readingMinutes":4,"inbound":1,"revisions":10,"impact":34,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":75,"title":"Out of Band Address Exchange using Payment Protocol Encryption","authors":["Justin Newton","Matt David","Aaron Voisine","James MacWhyte"],"status":"Deployed","type":"Specification","layer":"Applications","created":"2015-11-20","license":"CC-BY-4.0","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"comments":"https://github.com/bitcoin/bips/wiki/Comments:BIP-0075","abstract":"This BIP is an extension to BIP 70 that provides two enhancements to the existing Payment Protocol. It allows the requester (Sender) of a PaymentRequest to voluntarily sign the original request and provide a certificate to allow the payee to know the identity of who they are transacting with. It encrypts the PaymentRequest that is returned, before handing it off to the SSL/TLS layer to prevent man in the middle viewing of the Payment Request details. The key words \"MUST\", \"MUST NOT\", \"REQUIRED\", \"SHALL\", \"SHALL NOT\", \"SHOULD\", \"SHOULD NOT\", \"RECOMMENDED\", \"MAY\", and \"OPTIONAL\" in this document are to be interpreted as described in RFC 2119.","eli5":"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 intermediary, such as a wallet relay server, without that middleman being able to read or tamper with the addresses.","categories":["security","signatures"],"filename":"bip-0075.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0075.mediawiki","format":"mediawiki","readingMinutes":16,"inbound":1,"revisions":46,"impact":79,"core":false,"references":[70],"lastModified":"2026-02-27"},{"number":77,"title":"Async Payjoin","authors":["Dan Gould","Yuval Kogman"],"status":"Draft","type":"Specification","layer":"Applications","created":"2023-08-08","license":"BSD-2-Clause","version":"0.2.0","requires":[21,78,173,174],"replaces":[],"replacedBy":[],"discussion":["https://github.com/bitcoin/bips/pull/1483","https://gnusha.org/pi/bitcoindev/7B11AE34-27A7-46ED-95BF-66CA13BA26F3@ngould.dev/#t","https://gnusha.org/pi/bitcoindev/3C0A6E4C-444E-4E75-829C-1A21D8EE40E0@ngould.dev/#t"],"comments":"https://github.com/bitcoin/bips/wiki/Comments:BIP-0077","abstract":"Payjoin lets Bitcoin senders and receivers interact to make batched transactions. This document proposes a second, backwards-compatible, asynchronous version of the Payjoin protocol (\"Version 2\") relative to and described in BIP 78 (\"Version 1\"). An untrusted third-party \"directory server\" replaces the requirement for a receiver to host a secure public endpoint for interactions. HTTP clients access the directory server using an asynchronous protocol and authenticated, encrypted payloads. The design preserves complete Payjoin receiver functionality, including payment output substitution. Authenticated encryption depends only on cryptographic primitives available in Bitcoin Core. Requests use Oblivious HTTP (OHTTP) to prevent the directory and other Payjoin clients from linking requests to client IP addresses.","eli5":"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, meaning ordinary wallets can receive Payjoin payments without running their own web server.","categories":["addresses","transactions"],"filename":"bip-0077.md","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0077.md","format":"markdown","readingMinutes":20,"inbound":0,"revisions":14,"impact":23,"core":false,"references":[],"lastModified":"2026-06-01"},{"number":78,"title":"A Simple Payjoin Proposal","authors":["Nicolas Dorier"],"status":"Deployed","type":"Specification","layer":"Applications","created":"2019-05-01","license":"BSD-2-Clause","requires":[],"replaces":[79],"replacedBy":[],"discussion":[],"abstract":"This document proposes a protocol for two parties to negotiate a coinjoin transaction during a payment between them.","eli5":"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 surveillance, it improves privacy for both parties and for Bitcoin users in general.","categories":["transactions"],"filename":"bip-0078.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0078.mediawiki","format":"mediawiki","readingMinutes":22,"inbound":1,"revisions":46,"impact":79,"core":false,"references":[21,79],"lastModified":"2026-05-20"},{"number":79,"title":"Bustapay :: a practical coinjoin protocol","authors":["Ryan Havar"],"status":"Closed","type":"Informational","layer":"Applications","created":"2018-10-05","license":"CC0-1.0","requires":[],"replaces":[],"replacedBy":[78],"discussion":[],"abstract":"The way bitcoin transactions are normally created leaks more information than desirable, and as a result has been exploited by unreasonably effective blockchain analysis techniques to jeopardize important properties that are expected of a useful currency. Bustapay is a simple and practical protocol for the sender and receiver of a payment to collaboratively sign a bitcoin transaction in such a way that busts some analysis assumptions to the immediate benefit of the sender and receiver. Furthermore it does so in such a way that gives a significant amount of control to the receiver to help manage their utxo set size, a constant problem for bitcoin merchants.","eli5":"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 inputs in a transaction belong to one person, making blockchain analysis less reliable.","categories":["payments","transactions"],"filename":"bip-0079.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0079.mediawiki","format":"mediawiki","readingMinutes":8,"inbound":1,"revisions":18,"impact":55,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":80,"title":"Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets","authors":["Justus Ranvier","Jimmy Song"],"status":"Closed","type":"Informational","created":"2014-08-11","license":"PD","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This BIP defines a logical hierarchy for non-colored voting pool deterministic multisig wallets based on an algorithm described in BIP-0032 (BIP32 from now on) and purpose scheme described in BIP-0043 (BIP43 from now on). This BIP is a particular application of BIP43 and is based on BIP44.","eli5":"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 44, it lets compatible software derive the same addresses from shared keys.","categories":["wallets"],"filename":"bip-0080.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0080.mediawiki","format":"mediawiki","readingMinutes":2,"inbound":2,"revisions":13,"impact":64,"core":false,"references":[32,43,44],"lastModified":"2025-10-08"},{"number":81,"title":"Hierarchy for Colored Voting Pool Deterministic Multisig Wallets","authors":["Justus Ranvier","Jimmy Song"],"status":"Closed","type":"Informational","created":"2014-08-11","license":"PD","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This BIP defines a logical hierarchy for colored coin voting pool deterministic multisig wallets based on an algorithm described in BIP-0032 (BIP32 from now on) and purpose scheme described in BIP-0043 (BIP43 from now on). This BIP is a particular application of BIP43 and is based on BIP44.","eli5":"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 different wallet software consistently generate and track the same addresses.","categories":["wallets"],"filename":"bip-0081.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0081.mediawiki","format":"mediawiki","readingMinutes":2,"inbound":1,"revisions":14,"impact":49,"core":false,"references":[32,43,44,80],"lastModified":"2025-10-08"},{"number":83,"title":"Dynamic Hierarchical Deterministic Key Trees","authors":["Eric Lombrozo"],"status":"Closed","type":"Specification","layer":"Applications","created":"2015-11-16","license":"PD","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This BIP defines a scheme for key derivation that allows for dynamic creation of key hierarchies based on the algorithm described in BIP32.","eli5":"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 recovering everything from a single backup seed.","categories":["wallets"],"filename":"bip-0083.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0083.mediawiki","format":"mediawiki","readingMinutes":4,"inbound":1,"revisions":12,"impact":41,"core":false,"references":[32],"lastModified":"2025-10-08"},{"number":84,"title":"Derivation scheme for P2WPKH based accounts","authors":["Pavol Rusnak"],"status":"Deployed","type":"Specification","layer":"Applications","created":"2017-12-28","license":"CC0-1.0","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"comments":"https://github.com/bitcoin/bips/wiki/Comments:BIP-0084","abstract":"This BIP defines the derivation scheme for HD wallets using the P2WPKH ( BIP 173 ) serialization format for segregated witness transactions.","eli5":"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 same addresses and funds.","categories":["wallets","hd-wallets","derivation"],"filename":"bip-0084.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0084.mediawiki","format":"mediawiki","readingMinutes":2,"inbound":3,"revisions":12,"impact":76,"core":false,"references":[32,43,44,49,141,173],"lastModified":"2025-10-08"},{"number":85,"title":"Deterministic Entropy From BIP32 Keychains","authors":["Ethan Kosakovsky","Aneesh Karve"],"status":"Deployed","type":"Informational","layer":"Applications","created":"2020-03-20","license":"BSD-2-Clause OR OPUBL-1.0","version":"2.1.0","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"\"One Seed to rule them all, One Key to find them, One Path to bring them all, And in cryptography bind them.\" It is not possible to maintain one single (mnemonic) seed backup for all keychains used across various wallets because there are a variety of incompatible standards. Sharing of seeds across multiple wallets is not desirable for security reasons. Physical storage of multiple seeds is difficult depending on the security and redundancy required. As HD keychains are essentially derived from initial entropy, this proposal provides a way to derive entropy from the keychain which can be fed into whatever method a wallet uses to derive the initial mnemonic seed or root key.","eli5":"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 wallets being able to reveal the master.","categories":["wallets","derivation"],"filename":"bip-0085.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0085.mediawiki","format":"mediawiki","readingMinutes":12,"inbound":0,"revisions":42,"impact":62,"core":false,"references":[],"lastModified":"2026-08-03"},{"number":86,"title":"Key Derivation for Single Key P2TR Outputs","authors":["Ava Chow"],"status":"Deployed","type":"Specification","layer":"Applications","created":"2021-06-22","license":"BSD-2-Clause","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This document suggests a derivation scheme for HD wallets whose keys are involved in single key P2TR ( BIP 341 ) outputs as the Taproot internal key.","eli5":"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 addresses across different wallets.","categories":["wallets","derivation"],"filename":"bip-0086.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0086.mediawiki","format":"mediawiki","readingMinutes":2,"inbound":2,"revisions":8,"impact":59,"core":false,"references":[32,43,44,49,84,341],"lastModified":"2025-10-08"},{"number":87,"title":"Hierarchy for Deterministic Multisig Wallets","authors":["Robert Spigler"],"status":"Complete","type":"Specification","layer":"Applications","created":"2020-03-11","license":"BSD-2-Clause","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This BIP defines a sane hierarchy for deterministic multisig wallets based on an algorithm described in BIP-0032 (BIP32 from now on), purpose scheme described in BIP-0043 (BIP43 from now on), and multi-account hierarchy described in BIP-0044 (BIP44 from now on). This BIP is a particular application of BIP43.","eli5":"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 wallet apps and hardware devices to set up and recover the same multisig wallet.","categories":["wallets","derivation"],"filename":"bip-0087.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0087.mediawiki","format":"mediawiki","readingMinutes":7,"inbound":0,"revisions":12,"impact":22,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":88,"title":"Hierarchical Deterministic Path Templates","authors":["Dmitry Petukhov"],"status":"Complete","type":"Informational","layer":"Applications","created":"2020-06-23","license":"BSD-2-Clause","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This document describes a format for the representation of the templates that specify the constraints that can be imposed on BIP32 derivation paths. The constraints specified by the templates allow to easily discern 'valid' paths, that match the constraints, and 'invalid' paths, that exceed the constraints.","eli5":"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 key paths from suspicious ones, reducing the risk of funds being sent to unexpected places.","categories":["wallets"],"filename":"bip-0088.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0088.mediawiki","format":"mediawiki","readingMinutes":9,"inbound":0,"revisions":15,"impact":25,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":89,"title":"Chain Code Delegation","authors":["Jesse Posner","Jurvis Tan"],"status":"Deployed","type":"Specification","layer":"Applications","created":"2025-12-03","license":"BSD-3-Clause","version":"1.0.0","requires":[32,340,341],"replaces":[],"replacedBy":[],"discussion":["https://delvingbitcoin.org/t/chain-code-delegation-private-access-control-for-bitcoin-keys/1837"],"comments":"https://github.com/bitcoin/bips/wiki/Comments:BIP-0089","abstract":"Chain Code Delegation (CCD) is a method for multi-signature wallets in which a privileged participant withholds BIP32 chain codes from one or more non-privileged participants, and supplies per-input scalar tweaks at signing time. This allows non-privileged participants to co-sign transactions without learning wallet-wide derivations, balances, or signing activity from other spending combinations. CCD defines the tweak exchange needed for verification and signing behavior when the signer does not possess a chain code.","eli5":"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 backup service, can still approve transactions without learning the wallet's full balance or history, improving privacy.","categories":["wallets","signatures","transactions"],"filename":"bip-0089.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0089.mediawiki","format":"mediawiki","readingMinutes":20,"inbound":0,"revisions":3,"impact":6,"core":false,"references":[],"lastModified":"2026-09-15"},{"number":90,"title":"Buried Deployments","authors":["Suhas Daftuar"],"status":"Deployed","type":"Informational","created":"2016-11-08","license":"PD","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"comments":"https://github.com/bitcoin/bips/wiki/Comments:BIP-0090","abstract":"Prior soft forks (BIP 34, BIP 65, and BIP 66) were activated via miner signaling in block version numbers. Now that the chain has long since passed the blocks at which those consensus rules have triggered, we can (as a simplification) replace the trigger mechanism by caching the block heights at which those consensus rules became enforced.","eli5":"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 active, this cleans up the code without changing how valid blocks are judged.","categories":["consensus"],"filename":"bip-0090.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0090.mediawiki","format":"mediawiki","readingMinutes":4,"inbound":0,"revisions":17,"impact":29,"core":false,"references":[],"lastModified":"2026-02-27"},{"number":91,"title":"Reduced threshold Segwit MASF","authors":["James Hilliard"],"status":"Deployed","type":"Specification","layer":"Consensus (soft fork)","created":"2017-05-22","license":"BSD-3-Clause OR CC0-1.0","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This document specifies a method to activate the existing BIP9 segwit deployment with a majority hashpower less than 95%.","eli5":"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 remaining miners to signal; it was part of the 2017 SegWit activation debate.","categories":["consensus","blocks"],"filename":"bip-0091.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki","format":"mediawiki","readingMinutes":3,"inbound":0,"revisions":15,"impact":25,"core":false,"references":[9,16,141,143,147,148,149],"lastModified":"2025-10-22"},{"number":93,"title":"codex32: Checksummed SSSS-aware BIP32 seeds","authors":["Leon Olsson Curr and Pearlwort Sneed","Andrew Poelstra"],"status":"Draft","type":"Informational","layer":"Applications","created":"2023-02-13","license":"BSD-3-Clause","requires":[],"replaces":[],"replacedBy":[],"discussion":["https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021469.html"],"abstract":"This document proposes a checksummed base32 format, \"codex32\", and a standard for backing up and restoring the master seed of a BIP-0032 hierarchical deterministic wallet using it. It includes an encoding format, a BCH error-correcting checksum, and optional Shamir's secret sharing algorithms for share generation and secret recovery. Secret data can be encoded directly, or split into up to 31 shares. A minimum threshold of shares, which can be between 2 and 9, is needed to recover the secret, whereas without sufficient shares, no information about the secret is recoverable.","eli5":"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 shares so that only a chosen number are needed to recover it.","categories":["wallets"],"filename":"bip-0093.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0093.mediawiki","format":"mediawiki","readingMinutes":25,"inbound":0,"revisions":13,"impact":22,"core":false,"references":[],"lastModified":"2026-08-26"},{"number":94,"title":"Testnet 4","authors":["Fabian Jahr"],"status":"Deployed","type":"Specification","layer":"Applications","created":"2024-05-27","license":"CC0-1.0","requires":[],"replaces":[],"replacedBy":[95],"discussion":["https://gnusha.org/pi/bitcoindev/CADL_X_eXjbRFROuJU0b336vPVy5Q2RJvhcx64NSNPH-3fDCUfw@mail.gmail.com/","https://gnusha.org/pi/bitcoindev/a6e3VPsXJf9p3gt_FmNF_Up-wrFuNMKTN30-xCSDHBKXzXnSpVflIZIj2NQ8Wos4PhQCzI2mWEMvIms_FAEs7rQdL15MpC_Phmu_fnR9iTg=@protonmail.com/","https://github.com/bitcoin/bitcoin/pull/29775"],"abstract":"A new test network with the goal to replace Testnet 3. This network comes with small but important improvements of the consensus rules, that should make it impractical to attack the network using only CPU mining.","eli5":"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 with ordinary computers, making testing more reliable.","categories":["consensus","mining"],"filename":"bip-0094.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0094.mediawiki","format":"mediawiki","readingMinutes":6,"inbound":1,"revisions":15,"impact":51,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":95,"title":"Testnet 5","authors":["Pol Espinasa","Fabian Jahr"],"status":"Draft","type":"Specification","layer":"Applications","created":"2026-06-22","license":"CC0-1.0","version":"0.1.0","requires":[54],"replaces":[94],"replacedBy":[],"discussion":["https://groups.google.com/g/bitcoindev/c/kGUMTxOvdJA"],"abstract":"Testnet 5 is a new test network intended to replace Testnet 4. Testnet 5 removes the difficulty exception defined in Testnet 4. Sustained exploitation of this exception has made the network difficult to use for testing. Additionally, Testnet 5 raises the minimum difficulty and enforces the consensus rules specified in BIP 54 from block 1.","eli5":"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 cleanup rules from the start, aiming for a more stable test network.","categories":["consensus"],"filename":"bip-0095.md","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0095.md","format":"markdown","readingMinutes":5,"inbound":0,"revisions":1,"impact":0,"core":false,"references":[30,94],"lastModified":"2026-05-08"},{"number":98,"title":"Fast Merkle Trees","authors":["Mark Friedenbach","Kalle Alm","BtcDrak"],"status":"Draft","type":"Specification","layer":"Consensus (soft fork)","created":"2017-08-24","license":"CC-BY-SA-4.0","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"In many applications it is useful to prove membership of a data element in a set without having to reveal the entire contents of that set. The Merkle hash-tree, where inner/non-leaf nodes are labeled with the hash of the labels or values of its children, is a cryptographic tool that achieves this goal. Bitcoin uses a Merkle hash-tree construct for committing the transactions of a block into the block header. This particular design, created by Satoshi, suffers from a serious flaw related to duplicate entries documented in the National Vulnerability Database as CVE-2012-2459[1], and also suffers from less than optimal performance due to unnecessary double-hashing. This Bitcoin Improvement Proposal describes a more efficient Merkle hash-tree construct that is not vulnerable to CVE-2012-2459 and achieves an approximate 55% decrease in hash-tree construction and validation times as compared with fully optimized implementations of the Satoshi Merkle hash-tree construct.","eli5":"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 weaknesses in Bitcoin's original construction and is intended as a building block for future upgrades.","categories":["consensus"],"filename":"bip-0098.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0098.mediawiki","format":"mediawiki","readingMinutes":13,"inbound":1,"revisions":12,"impact":41,"core":false,"references":[],"lastModified":"2026-09-25"},{"number":99,"title":"Motivation and deployment of consensus rule changes ([soft/hard]forks)","authors":["Jorge Timón"],"status":"Closed","type":"Informational","created":"2015-06-20","license":"PD","requires":[],"replaces":[],"replacedBy":[],"discussion":["http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008936.html"],"abstract":"This BIP attempts to create a taxonomy of the different types of consensus forks and proposes a deployment mechanism for each of them.","eli5":"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 that changes are introduced safely and with broad agreement.","categories":["standards","process"],"filename":"bip-0099.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0099.mediawiki","format":"mediawiki","readingMinutes":13,"inbound":1,"revisions":25,"impact":60,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":100,"title":"Dynamic maximum block size by miner vote","authors":["Jeff Garzik","Tom Harding","Dagur Valberg Johannsson"],"status":"Closed","type":"Specification","layer":"Consensus (hard fork)","created":"2015-06-11","license":"BSD-2-Clause","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"Replace the static 1M block size hard limit with a hard limit set by coinbase vote, conducted on the same schedule as difficulty retargeting.","eli5":"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 proposals during the block size debate and would have required a hard fork.","categories":["blocks"],"filename":"bip-0100.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0100.mediawiki","format":"mediawiki","readingMinutes":3,"inbound":0,"revisions":10,"impact":17,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":101,"title":"Increase maximum block size","authors":["Gavin Andresen"],"status":"Closed","type":"Specification","layer":"Consensus (hard fork)","created":"2015-06-22","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This BIP proposes replacing the fixed one megabyte maximum block size with a maximum size that grows over time at a predictable rate.","eli5":"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 would have required a hard fork and was part of the block size debate.","categories":["consensus","blocks"],"filename":"bip-0101.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki","format":"mediawiki","readingMinutes":6,"inbound":1,"revisions":11,"impact":37,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":102,"title":"Block size increase to 2MB","authors":["Jeff Garzik"],"status":"Closed","type":"Specification","layer":"Consensus (hard fork)","created":"2015-06-23","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"Simple, one-time increase in total amount of transaction data permitted in a block from 1MB to 2MB.","eli5":"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 of the competing options in the block size debate.","categories":["capacity","blocks"],"filename":"bip-0102.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0102.mediawiki","format":"mediawiki","readingMinutes":1,"inbound":1,"revisions":13,"impact":46,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":103,"title":"Block size following technological growth","authors":["Pieter Wuille"],"status":"Closed","type":"Specification","layer":"Consensus (hard fork)","created":"2015-07-21","license":"BSD-2-Clause","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This BIP proposes a block size growth intended to accommodate for hardware and other technological improvements for the foreseeable future.","eli5":"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 their own full node.","categories":["consensus","blocks","capacity"],"filename":"bip-0103.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0103.mediawiki","format":"mediawiki","readingMinutes":4,"inbound":1,"revisions":11,"impact":37,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":104,"title":"'Block75' - Max block size like difficulty","authors":["t.khan"],"status":"Closed","type":"Specification","layer":"Consensus (hard fork)","created":"2017-01-13","license":"BSD-2-Clause OR FSFAP","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"Automatic adjustment of max block size with the target of keeping blocks 75% full, based on the average block size of the previous 2016 blocks. This would be done on the same schedule as difficulty.","eli5":"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 shrink with demand; it required a hard fork.","categories":["blocks"],"filename":"bip-0104.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0104.mediawiki","format":"mediawiki","readingMinutes":3,"inbound":0,"revisions":11,"impact":20,"core":false,"references":[],"lastModified":"2025-10-24"},{"number":105,"title":"Consensus based block size retargeting algorithm","authors":["BtcDrak"],"status":"Closed","type":"Specification","layer":"Consensus (hard fork)","created":"2015-08-21","license":"PD","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"A method of altering the maximum allowed block size of the Bitcoin protocol using a consensus based approach.","eli5":"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 upgrades, but required a hard fork.","categories":["capacity","consensus"],"filename":"bip-0105.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0105.mediawiki","format":"mediawiki","readingMinutes":3,"inbound":1,"revisions":13,"impact":46,"core":false,"references":[34],"lastModified":"2025-10-08"},{"number":106,"title":"Dynamically Controlled Bitcoin Block Size Max Cap","authors":["Upal Chakraborty"],"status":"Closed","type":"Specification","layer":"Consensus (hard fork)","created":"2015-08-24","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This BIP proposes replacing the fixed one megabyte maximum block size with a dynamically controlled maximum block size that may increase or decrease with difficulty change depending on various network factors. I have two proposals regarding this... i. Depending only on previous block size calculation. ii. Depending on previous block size calculation and previous Tx fee collected by miners.","eli5":"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 automatically; it was part of the block size debate.","categories":["network"],"filename":"bip-0106.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0106.mediawiki","format":"mediawiki","readingMinutes":3,"inbound":1,"revisions":11,"impact":37,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":107,"title":"Dynamic limit on the block size","authors":["Washington Y. Sanchez"],"status":"Closed","type":"Specification","layer":"Consensus (hard fork)","created":"2015-09-11","license":"PD","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This BIP proposes a dynamic limit to the block size based on transaction volume.","eli5":"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 contentious changes.","categories":["blocks","transactions"],"filename":"bip-0107.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0107.mediawiki","format":"mediawiki","readingMinutes":4,"inbound":1,"revisions":12,"impact":41,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":109,"title":"Two million byte size limit with sigop and sighash limits","authors":["Gavin Andresen"],"status":"Closed","type":"Specification","layer":"Consensus (hard fork)","created":"2016-01-28","license":"PD","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"One-time increase in total amount of transaction data permitted in a block from 1MB to 2MB, with limits on signature operations and hashing.","eli5":"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 effort and would have required a hard fork.","categories":["consensus","capacity"],"filename":"bip-0109.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0109.mediawiki","format":"mediawiki","readingMinutes":3,"inbound":1,"revisions":13,"impact":46,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":110,"title":"Reduced Data Temporary Softfork","authors":["Dathon Ohm"],"status":"Closed","type":"Specification","layer":"Consensus (soft fork)","created":"2025-12-03","license":"BSD-3-Clause","version":"1.0.1","requires":[],"replaces":[],"replacedBy":[],"discussion":["https://groups.google.com/g/bitcoindev/c/nOZim6FbuF8"],"abstract":"Temporarily limit the size of data fields at the consensus level, in order to correct distorted incentives caused by standardizing support for arbitrary data, and to refocus priorities on improving Bitcoin as money.","eli5":"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, such as inscriptions, and keep the focus on Bitcoin as money.","categories":["consensus"],"filename":"bip-0110.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0110.mediawiki","format":"mediawiki","readingMinutes":21,"inbound":0,"revisions":9,"impact":15,"core":false,"references":[9,141,341,342,433],"lastModified":"2026-08-09"},{"number":111,"title":"NODE_BLOOM service bit","authors":["Matt Corallo","Peter Todd"],"status":"Deployed","type":"Specification","layer":"Peer Services","created":"2015-08-20","license":"PD","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This BIP extends BIP 37, Connection Bloom filtering, by defining a service bit to allow peers to advertise that they support bloom filters explicitly. It also bumps the protocol version to allow peers to identify old nodes which allow bloom filtering of the connection despite lacking the new service bit.","eli5":"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 privacy and resource costs, while lightweight clients can still find nodes that do.","categories":["network"],"filename":"bip-0111.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0111.mediawiki","format":"mediawiki","readingMinutes":2,"inbound":1,"revisions":15,"impact":51,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":112,"title":"CHECKSEQUENCEVERIFY","authors":["BtcDrak","Mark Friedenbach","Eric Lombrozo"],"status":"Deployed","type":"Specification","layer":"Consensus (soft fork)","created":"2015-08-10","license":"PD","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This BIP describes a new opcode (CHECKSEQUENCEVERIFY) for the Bitcoin scripting system that in combination with BIP 68 allows execution pathways of a script to be restricted based on the age of the output being spent.","eli5":"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 Network and other payment channels.","categories":["time-locks","scripts","consensus"],"filename":"bip-0112.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki","format":"mediawiki","readingMinutes":10,"inbound":7,"revisions":41,"impact":95,"core":true,"references":[],"lastModified":"2025-10-08"},{"number":113,"title":"Median time-past as endpoint for lock-time calculations","authors":["Thomas Kerin","Mark Friedenbach"],"status":"Deployed","type":"Specification","layer":"Consensus (soft fork)","created":"2015-08-10","license":"PD","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This BIP is a proposal to redefine the semantics used in determining a time-locked transaction's eligibility for inclusion in a block. The median of the last 11 blocks is used instead of the block's timestamp, ensuring that it increases monotonically with each block.","eli5":"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 to include timelocked transactions early.","categories":["sequence","consensus"],"filename":"bip-0113.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki","format":"mediawiki","readingMinutes":2,"inbound":2,"revisions":16,"impact":69,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":114,"title":"Merkelized Abstract Syntax Tree","authors":["Johnson Lau"],"status":"Closed","type":"Specification","layer":"Consensus (soft fork)","created":"2016-04-02","license":"PD","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This BIP defines a new witness program type that uses a Merkle tree to encode mutually exclusive branches in a script. This enables complicated redemption conditions that are currently not possible, improves privacy by hiding unexecuted scripts, and allows inclusion of non-consensus enforced data with very low or no additional cost.","eli5":"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 later incorporated into Taproot.","categories":["lightning","transactions","smart-contracts"],"filename":"bip-0114.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0114.mediawiki","format":"mediawiki","readingMinutes":13,"inbound":2,"revisions":15,"impact":67,"core":false,"references":[9,16,112,141],"lastModified":"2026-09-15"},{"number":115,"title":"Generic anti-replay protection using Script","authors":["Luke Dashjr"],"status":"Closed","type":"Specification","layer":"Consensus (soft fork)","created":"2016-09-23","license":"BSD-2-Clause","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This BIP describes a new opcode ( OP_CHECKBLOCKATHEIGHT ) for the Bitcoin scripting system that allows construction of transactions which are valid only on specific blockchains.","eli5":"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 and replayed on the other.","categories":["consensus"],"filename":"bip-0115.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0115.mediawiki","format":"mediawiki","readingMinutes":5,"inbound":0,"revisions":10,"impact":17,"core":false,"references":[9],"lastModified":"2025-10-08"},{"number":116,"title":"MERKLEBRANCHVERIFY","authors":["Mark Friedenbach","Kalle Alm","BtcDrak"],"status":"Draft","type":"Specification","layer":"Consensus (soft fork)","created":"2017-08-25","license":"CC-BY-SA-4.0","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"A general approach to bitcoin contracts is to fully enumerate the possible spending conditions and then program verification of these conditions into a single script. At redemption, the spending condition used is explicitly selected, e.g. by pushing a value on the witness stack that cascades through a series of if/else constructs. This approach has significant downsides, such as requiring all program pathways to be visible in the scriptPubKey or redeem script, even those which are not used at validation. This wastes space on the block chain, restricts the size of possible scripts due to push limits, and impacts both privacy and fungibility as details of the contract can often be specific to the user. This BIP proposes a new soft-fork upgradeable opcode, MERKLEBRANCHVERIFY, which allows script writers to commit to a set of data elements and have one or more of these elements be provided at redemption without having to reveal the entire set. As these data elements can be used to encode policy, such as public keys or validation subscripts, the MERKLEBRANCHVERIFY opcode can be used to overcome these limitations of existing bitcoin script.","eli5":"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, saving space and improving privacy.","categories":["consensus","smart-contracts","scripts"],"filename":"bip-0116.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0116.mediawiki","format":"mediawiki","readingMinutes":7,"inbound":0,"revisions":10,"impact":17,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":117,"title":"Tail Call Execution Semantics","authors":["Mark Friedenbach","Kalle Alm","BtcDrak"],"status":"Draft","type":"Specification","layer":"Consensus (soft fork)","created":"2017-08-25","license":"CC-BY-SA-4.0","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"BIP16 (Pay to Script Hash)[1] and BIP141 (Segregated Witness)[2] provide mechanisms by which script policy can be revealed at spend time as part of the execution witness. In both cases only a single script can be committed to by the construct. While useful for achieving the goals of these proposals, they still require that all policies be specified within the confine of a single script, regardless of whether the policies are needed at the time of spend. This BIP, in conjunction with BIP116 (MERKLEBRANCHVERIFY)[3] allows for a script to commit to a practically unbounded number of code pathways, and then reveal the actual code pathway used at spend time. This achieves a form of generalized MAST[4] enabling decomposition of complex branching scripts into a set of non-branching flat execution pathways, committing to the entire set of possible pathways, and then revealing only the path used at spend time.","eli5":"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 one used, an approach later superseded by Taproot.","categories":["consensus","smart-contracts","scripts"],"filename":"bip-0117.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0117.mediawiki","format":"mediawiki","readingMinutes":10,"inbound":1,"revisions":9,"impact":33,"core":false,"references":[],"lastModified":"2026-02-27"},{"number":118,"title":"SIGHASH_ANYPREVOUT for Taproot Scripts","authors":["Christian Decker","Anthony Towns"],"status":"Draft","type":"Specification","layer":"Consensus (soft fork)","created":"2017-02-28","license":"BSD-3-Clause","requires":[340,341,342],"replaces":[],"replacedBy":[],"discussion":[],"comments":"https://github.com/bitcoin/bips/wiki/Comments:BIP-0118","abstract":"This BIP describes a new type of public key for tapscript ( BIP 342 ) transactions. It allows signatures for these public keys to not commit to the exact UTXO being spent. This enables dynamic binding of transactions to different UTXOs, provided they have compatible scripts.","eli5":"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 the 'Eltoo' upgrade to Lightning, simplifying channel updates and backups.","categories":["lightning","smart-contracts"],"filename":"bip-0118.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki","format":"mediawiki","readingMinutes":13,"inbound":3,"revisions":14,"impact":77,"core":false,"references":[30,68,112,350],"lastModified":"2025-10-08"},{"number":119,"title":"CHECKTEMPLATEVERIFY","authors":["Jeremy Rubin"],"status":"Draft","type":"Specification","layer":"Consensus (soft fork)","created":"2020-01-06","license":"BSD-3-Clause","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This BIP proposes a new opcode, OP_CHECKTEMPLATEVERIFY, to be activated as a change to the semantics of OP_NOP4.","eli5":"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, efficient batched payments and other advanced contracts.","categories":["lightning","scripts","smart-contracts"],"filename":"bip-0119.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki","format":"mediawiki","readingMinutes":22,"inbound":5,"revisions":57,"impact":94,"core":false,"references":[],"lastModified":"2026-03-04"},{"number":120,"title":"Proof of Payment","authors":["Kalle Rosenbaum"],"status":"Closed","type":"Specification","layer":"Applications","created":"2015-07-28","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This BIP describes a system called Proof of Payment, PoP. It is used to prove that a wallet has the credentials that were used to sign a previously generated transaction. Or simply put, it lets you prove that you have made a payment.","eli5":"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, without a separate receipt.","categories":["scripts"],"filename":"bip-0120.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0120.mediawiki","format":"mediawiki","readingMinutes":6,"inbound":1,"revisions":14,"impact":49,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":121,"title":"Proof of Payment URI scheme","authors":["Kalle Rosenbaum"],"status":"Closed","type":"Specification","layer":"Applications","created":"2015-07-27","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This is a proposal for a URI scheme to be used in the Proof of Payment process.","eli5":"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.","categories":["scripts"],"filename":"bip-0121.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0121.mediawiki","format":"mediawiki","readingMinutes":3,"inbound":1,"revisions":19,"impact":57,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":122,"title":"URI scheme for Blockchain references / exploration","authors":["Marco Pontello"],"status":"Draft","type":"Specification","layer":"Applications","created":"2015-08-29","license":"PD","requires":[],"replaces":[],"replacedBy":[],"discussion":["https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010712.html"],"abstract":"This BIP proposes a URI scheme for looking up blocks, transactions and addresses on a Blockchain explorer, or in general to make proper Blockchain references.","eli5":"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, avoiding ambiguity between networks.","categories":["standards","uri"],"filename":"bip-0122.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0122.mediawiki","format":"mediawiki","readingMinutes":2,"inbound":1,"revisions":18,"impact":55,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":123,"title":"BIP Classification","authors":["Eric Lombrozo"],"status":"Deployed","type":"Process","created":"2015-08-26","license":"CC0-1.0 OR FSFAP","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This document describes a classification scheme for BIPs. BIPs are classified by system layers with lower numbered layers involving more intricate interoperability requirements. The specification defines the layers and sets forth specific criteria for deciding to which layer a particular standards BIP belongs.","eli5":"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 for it to work.","categories":["process","standards"],"filename":"bip-0123.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0123.mediawiki","format":"mediawiki","readingMinutes":7,"inbound":2,"revisions":16,"impact":69,"core":false,"references":[1,2,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,30,31,32,33,34,35,36,37,38,39,42,43,44,45,47,49,50,60,61,62,64,65,66,67,68,69,70,71,72,73,74,75,80,81,83,99,101,102,103,105,106,107,109,111,112,113,114,120,121,122,124,125,126,130,131,132,133,134,140,141,142,143,144,145,146,147,150,151,152],"lastModified":"2025-10-24"},{"number":124,"title":"Hierarchical Deterministic Script Templates","authors":["Eric Lombrozo","William Swanson"],"status":"Closed","type":"Informational","layer":"Applications","created":"2015-11-20","license":"PD","requires":[],"replaces":[],"replacedBy":[],"discussion":["http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011795.html"],"abstract":"This BIP defines a script template format that can be used by wallets to deterministically generate scripts with specific authorization policies using the key derivation mechanism defined in BIP32.","eli5":"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 for the same arrangement of keys.","categories":["wallets"],"filename":"bip-0124.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0124.mediawiki","format":"mediawiki","readingMinutes":3,"inbound":1,"revisions":10,"impact":34,"core":false,"references":[16,32,65,112],"lastModified":"2025-10-08"},{"number":125,"title":"Opt-in Full Replace-by-Fee Signaling","authors":["David A. Harding","Peter Todd"],"status":"Deployed","type":"Specification","layer":"Applications","created":"2015-12-04","license":"PD","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"comments":"https://github.com/bitcoin/bips/wiki/Comments:BIP-0125","abstract":"Many nodes today will not replace any transaction in their mempool with another transaction that spends the same inputs, making it difficult for spenders to adjust their previously-sent transactions to deal with unexpected confirmation delays or to perform other useful replacements. The opt-in full Replace-by-Fee (opt-in full-RBF) signaling policy described here allows spenders to add a signal to a transaction indicating that they want to be able to replace that transaction in the future. In response to this signal, Nodes may allow transactions containing this signal to be replaced in their mempools. The recipient or recipients of a transaction containing this signal may choose not to treat it as payment until it has been confirmed, eliminating the risk that the spender will use allowed replacements to defraud them. Nodes and recipients may continue to treat transactions without the signal the same way they treated them before, preserving the existing status quo.","eli5":"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.","categories":["rbf","fees","mempool","transactions"],"filename":"bip-0125.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki","format":"mediawiki","readingMinutes":6,"inbound":1,"revisions":17,"impact":54,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":126,"title":"Best Practices for Heterogeneous Input Script Transactions","authors":["Kristov Atlas"],"status":"Draft","type":"Informational","created":"2016-02-10","license":"PD","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"When a Bitcoin transaction contains inputs that reference previous transaction outputs sent to different Bitcoin addresses, personally identifiable information of the user will leak into the blockchain in an uncontrolled manner. While undesirable, these transactions are frequently unavoidable due to the natural fragmentation of wallet balances over time. This document proposes a set of best practice guidelines which minimize the uncontrolled disclosure of personally identifiable information by defining standard forms for transactions containing heterogeneous input scripts.","eli5":"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 private information leaks into the public blockchain.","categories":["standards","process"],"filename":"bip-0126.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0126.mediawiki","format":"mediawiki","readingMinutes":5,"inbound":1,"revisions":11,"impact":37,"core":false,"references":[69],"lastModified":"2025-10-08"},{"number":127,"title":"Simple Proof-of-Reserves Transactions","authors":["Steven Roose"],"status":"Complete","type":"Specification","layer":"Applications","created":"2019-01-28","license":"CC0-1.0","version":"1.0.0","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This BIP describes a simple way to construct proof-of-reserves transactions. This proposal formalizes a standard format for constructing such proofs, easing their construction with existing wallet infrastructure and enabling general proof-verification software. It relies on existing standards such as regular Bitcoin transaction serialization/validation and the BIP 174 PSBT format. The proposal also includes the description of a PSBT extension for a better user experience.","eli5":"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 holdings using existing wallet tools and common verification software.","categories":["wallets"],"filename":"bip-0127.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0127.mediawiki","format":"mediawiki","readingMinutes":5,"inbound":0,"revisions":10,"impact":17,"core":false,"references":[],"lastModified":"2026-05-21"},{"number":128,"title":"Timelock-Recovery Storage Format","authors":["Oren Z"],"status":"Draft","type":"Specification","layer":"Applications","created":"2026-02-05","license":"BSD-2-Clause","requires":[],"replaces":[],"replacedBy":[],"discussion":["https://groups.google.com/g/bitcoindev/c/K1NpJp9_BYk"],"abstract":"This document proposes a standard format for saving timelock-recovery plans, to allow different wallets to generate them, and different services to monitor/execute them.","eli5":"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 service store, monitor or carry it out.","categories":["wallets"],"filename":"bip-0128.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0128.mediawiki","format":"mediawiki","readingMinutes":10,"inbound":0,"revisions":2,"impact":4,"core":false,"references":[65,68,112,119,140,433,443],"lastModified":"2026-03-16"},{"number":129,"title":"Bitcoin Secure Multisig Setup (BSMS)","authors":["Hugo Nguyen","Peter Gray","Marko Bencun","Aaron Chen","Rodolfo Novak"],"status":"Complete","type":"Specification","layer":"Applications","created":"2020-11-10","license":"BSD-2-Clause","requires":[32,174,322,380,381,382,383],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This document proposes a mechanism to set up multisig wallets securely.","eli5":"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 the same wallet, guarding against tampering during setup.","categories":["wallets"],"filename":"bip-0129.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0129.mediawiki","format":"mediawiki","readingMinutes":12,"inbound":1,"revisions":13,"impact":46,"core":false,"references":[],"lastModified":"2026-02-27"},{"number":130,"title":"sendheaders message","authors":["Suhas Daftuar"],"status":"Deployed","type":"Specification","layer":"Peer Services","created":"2015-05-08","license":"PD","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"Add a new message, \"sendheaders\", which indicates that a node prefers to receive new block announcements via a \"headers\" message rather than an \"inv\".","eli5":"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 the network faster.","categories":["network"],"filename":"bip-0130.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0130.mediawiki","format":"mediawiki","readingMinutes":2,"inbound":1,"revisions":10,"impact":34,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":131,"title":"\"Coalescing Transaction\" Specification (wildcard inputs)","authors":["Chris Priest"],"status":"Closed","type":"Specification","layer":"Consensus (hard fork)","created":"2015-11-30","license":"PD","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This specification defines a new type of transaction that supplements (not replaces) normal \"non coalescing\" bitcoin transactions.","eli5":"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 fork.","categories":["transactions"],"filename":"bip-0131.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0131.mediawiki","format":"mediawiki","readingMinutes":3,"inbound":1,"revisions":12,"impact":41,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":132,"title":"Committee-based BIP Acceptance Process","authors":["Andy Chase"],"status":"Closed","type":"Process","created":"2015-08-31","license":"PD","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"The current process for accepting a BIP is not clearly defined. While BIP-0001 defines the process for writing and submitting a Bitcoin Improvement Proposal to the community it does not specify the precise method for which BIPs are considered accepted or rejected. This proposal sets up a method for determining BIP acceptance. This BIP has two parts: It sets up a process which a BIP goes through for comments and acceptance. The Process is: BIP Draft Submitted for comments (2 weeks) Waiting on opinion (2 weeks) BIP becomes either Accepted or Deferred It sets up committees for reviewing comments and indicating acceptance under precise conditions. Committees are authorized groups that represent client authors, miners, merchants, and users (each as a segment). Each one must represent at least 1% stake in the Bitcoin ecosystem. BIP acceptance is defined as at least 70% of the represented percentage stake in 3 out of the 4 Bitcoin segments.","eli5":"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 way to evaluate proposals.","categories":["standards","process"],"filename":"bip-0132.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0132.mediawiki","format":"mediawiki","readingMinutes":6,"inbound":1,"revisions":10,"impact":34,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":133,"title":"feefilter message","authors":["Alex Morcos"],"status":"Deployed","type":"Specification","layer":"Peer Services","created":"2016-02-13","license":"PD","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"Add a new message, \"feefilter\", which serves to instruct peers not to send \"inv\"'s to the node for transactions with fees below the specified fee rate.","eli5":"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.","categories":["network"],"filename":"bip-0133.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0133.mediawiki","format":"mediawiki","readingMinutes":3,"inbound":1,"revisions":12,"impact":41,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":134,"title":"Flexible Transactions","authors":["Tom Zander"],"status":"Closed","type":"Specification","layer":"Consensus (hard fork)","created":"2016-07-27","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This BIP describes the next step in making Bitcoin's most basic element, the transaction, more flexible and easier to extend. At the same time this fixes all known cases of malleability and resolves significant amounts of technical debt.","eli5":"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 confirmation) and clean up old design debt, but it requires a hard fork, meaning every node would need to upgrade.","categories":["consensus"],"filename":"bip-0134.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0134.mediawiki","format":"mediawiki","readingMinutes":8,"inbound":1,"revisions":15,"impact":51,"core":false,"references":[],"lastModified":"2025-10-22"},{"number":135,"title":"Generalized version bits voting","authors":["Sancho Panza"],"status":"Closed","type":"Informational","created":"2017-03-29","license":"CC0-1.0 OR FSFAP","requires":[],"replaces":[9],"replacedBy":[],"discussion":["https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/013969.html","https://bitco.in/forum/threads/bip9-generalized-version-bits-voting-bip-genvbvoting.1968/"],"abstract":"BIP9 introduced a mechanism for using the version bits to signal support for backwards-compatible changes (soft-forks) using a tally over the previous 2016 blocks computed at re-targeting intervals. It provided for a fixed threshold and non-configurable lock-in interval applicable to all deployments on a chain. This document describes a generalized signaling scheme which allows each signaling bit to have its own configurable threshold, window size (number of blocks over which it is tallied) and a configurable lock-in period. It extends the semantics of the signaling bits to cover arbitrary consensus changes, referred to under the general term 'forks'. The same range of version bits is used for signaling. The states of the BIP9 state machine and its original parameters (name, bit, starttime, timeout) are retained. Some state transition conditions are extended by additional parameters ('threshold', 'windowsize', 'minlockedblocks', 'minlockedtime') to provide for fine-tuning of threshold and grace period.","eli5":"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, configurable ways to coordinate future rule changes instead of one fixed set of activation parameters.","categories":["consensus"],"filename":"bip-0135.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0135.mediawiki","format":"mediawiki","readingMinutes":12,"inbound":0,"revisions":14,"impact":23,"core":false,"references":[],"lastModified":"2025-10-24"},{"number":136,"title":"Bech32 Encoded Tx Position References","authors":["Велеслав","Jonas Schnelli","Daniel Pape"],"status":"Draft","type":"Informational","layer":"Applications","created":"2017-07-09","license":"BSD-2-Clause","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This document proposes a convenient, human usable encoding to refer to a confirmed transaction position within the Bitcoin blockchain--known as \"TxRef\" . The primary purpose of this encoding is to allow users to refer to a confirmed transaction (and optionally, a particular outpoint index within the transaction) in a standard, reliable, and concise way. Please note: Unlike a transaction ID, \"TxID\" , where there is a strong cryptographic link between the ID and the actual transaction, a TxRef only provides a weak link to a particular transaction. A TxRef locates an offset within a blockchain for a transaction, that may - or may not - point to an actual transaction, which in fact may change with reorganisations. We recommend that TxRef s should be not used for positions within the blockchain having a maturity less than 100 blocks. The key words \"MUST\", \"MUST NOT\", \"REQUIRED\", \"SHALL\", \"SHALL NOT\", \"SHOULD\", \"SHOULD NOT\", \"RECOMMENDED\", \"MAY\", and \"OPTIONAL\" in this document are to be interpreted as described in RFC 2119 .","eli5":"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 modern addresses, making transaction references easier to read aloud, type, or print.","categories":["transactions"],"filename":"bip-0136.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0136.mediawiki","format":"mediawiki","readingMinutes":12,"inbound":0,"revisions":7,"impact":10,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":137,"title":"Signatures of Messages using Private Keys","authors":["Christopher Gilliard"],"status":"Deployed","type":"Specification","layer":"Applications","created":"2019-02-16","license":"BSD-2-Clause","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This document describes a signature format for signing messages with Bitcoin private keys. The specification is intended to describe the standard for signatures of messages that can be signed and verified between different clients that exist in the field today. Note: that a new signature format has been defined which has a number of advantages over this BIP, but to be backwards compatible with existing implementations this BIP will be useful. See BIP 322 [1] for full details on the new signature scheme. One of the key problems in this area is that there are several different types of Bitcoin addresses and without introducing specific standards it is unclear which type of address format is being used. See [2]. This BIP will attempt to address these issues and define a clear and concise format for Bitcoin signatures.","eli5":"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 check these signatures compatibly, even though a newer, more general format now exists.","categories":["signatures"],"filename":"bip-0137.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0137.mediawiki","format":"mediawiki","readingMinutes":6,"inbound":0,"revisions":22,"impact":32,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":138,"title":"Compact Encryption Scheme for Non-seed Wallet Data","authors":["Pyth"],"status":"Draft","type":"Specification","layer":"Applications","created":"2026-05-11","license":"BSD-2-Clause","version":"0.1.3","requires":[32,340,380,388,389,390],"replaces":[],"replacedBy":[],"discussion":["https://delvingbitcoin.org/t/a-simple-backup-scheme-for-wallet-accounts/1607","https://groups.google.com/g/bitcoindev/c/5NgJbpVDgEc/m/TtGK9sF9BgAJ","https://github.com/bitcoin/bips/pull/1951"],"abstract":"This BIP defines a compact encryption scheme for output script descriptors (BIP-0380), wallet policies (BIP-0388), and other wallet metadata. The payload must not contain any private key material. Users can store encrypted backups on untrusted media or cloud services without leaking addresses, script structures, or cosigner counts. The encryption key derives from the lexicographically-sorted public keys in the descriptor, allowing any keyholder to decrypt without additional secrets. Though designed for descriptors and policies, the scheme works equally well for labels and backup metadata.","eli5":"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 it, so users can store backups on cloud services without revealing their addresses or multisig setup.","categories":["signatures"],"filename":"bip-0138.md","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0138.md","format":"markdown","readingMinutes":18,"inbound":0,"revisions":44,"impact":65,"core":false,"references":[],"lastModified":"2026-09-23"},{"number":140,"title":"Normalized TXID","authors":["Christian Decker"],"status":"Closed","type":"Specification","layer":"Consensus (soft fork)","created":"2015-10-14","license":"PD","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This BIP describes the use of normalized transaction IDs (NTXIDs) in order to eliminate transaction malleability, both in the third-party modification scenario as well as the participant modification scenario. The transaction ID is normalized by removing the signature scripts from transactions before computing its hash. The normalized transaction hashes are then used during the signature creation and signature verification of dependent transactions.","eli5":"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 and building protocols that rely on unconfirmed transactions.","categories":["transactions"],"filename":"bip-0140.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0140.mediawiki","format":"mediawiki","readingMinutes":9,"inbound":2,"revisions":11,"impact":61,"core":false,"references":[62,66],"lastModified":"2025-10-08"},{"number":141,"title":"Segregated Witness (Consensus layer)","authors":["Eric Lombrozo","Johnson Lau","Pieter Wuille"],"status":"Deployed","type":"Specification","layer":"Consensus (soft fork)","created":"2015-12-21","license":"PD","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This BIP defines a new structure called a \"witness\" that is committed to blocks separately from the transaction merkle tree. This structure contains data required to check transaction validity but not required to determine transaction effects. In particular, scripts and signatures are moved into this new structure. The witness is committed in a tree that is nested into the block's existing merkle root via the coinbase transaction for the purpose of making this BIP soft fork compatible. A future hard fork can place this tree in its own branch.","eli5":"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 block capacity, and created a clean upgrade path that later enabled the Lightning Network and Taproot.","categories":["segwit","consensus","capacity","malleability"],"filename":"bip-0141.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki","format":"mediawiki","readingMinutes":17,"inbound":17,"revisions":54,"impact":100,"core":true,"references":[16,143,144,173],"lastModified":"2025-10-08"},{"number":142,"title":"Address Format for Segregated Witness","authors":["Johnson Lau"],"status":"Closed","type":"Specification","layer":"Applications","created":"2015-12-24","license":"PD","requires":[],"replaces":[],"replacedBy":[173],"discussion":[],"abstract":"This BIP describes new types of Bitcoin address to support native segregated witness transactions with 20-byte and 32-byte program.","eli5":"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 starting with \"bc1\".","categories":["addresses","segwit","p2sh"],"filename":"bip-0142.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0142.mediawiki","format":"mediawiki","readingMinutes":4,"inbound":1,"revisions":17,"impact":54,"core":false,"references":[13,16,70,141],"lastModified":"2025-10-08"},{"number":143,"title":"Transaction Signature Verification for Version 0 Witness Program","authors":["Johnson Lau","Pieter Wuille"],"status":"Deployed","type":"Specification","layer":"Consensus (soft fork)","created":"2016-01-03","license":"PD","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This proposal defines a new transaction digest algorithm for signature verification in version 0 witness program, in order to minimize redundant data hashing in verification, and to cover the input value by the signature.","eli5":"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 hardware wallets and offline signers confirm fees safely.","categories":["segwit","consensus","validation"],"filename":"bip-0143.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki","format":"mediawiki","readingMinutes":12,"inbound":6,"revisions":35,"impact":93,"core":true,"references":[144],"lastModified":"2025-10-08"},{"number":144,"title":"Segregated Witness (Peer Services)","authors":["Eric Lombrozo","Pieter Wuille"],"status":"Deployed","type":"Specification","layer":"Peer Services","created":"2016-01-08","license":"PD","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This BIP defines new messages and serialization formats for propagation of transactions and blocks committing to segregated witness structures.","eli5":"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 a version they understand.","categories":["segwit","consensus","validation","encoding"],"filename":"bip-0144.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki","format":"mediawiki","readingMinutes":3,"inbound":3,"revisions":23,"impact":83,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":145,"title":"getblocktemplate Updates for Segregated Witness","authors":["Luke Dashjr"],"status":"Deployed","type":"Specification","layer":"API/RPC","created":"2016-01-30","license":"BSD-2-Clause OR OPUBL-1.0","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This BIP describes modifications to the getblocktemplate JSON-RPC call ( BIP 22 ) to support segregated witness as defined by BIP 141 .","eli5":"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 witness data.","categories":["segwit","consensus"],"filename":"bip-0145.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0145.mediawiki","format":"mediawiki","readingMinutes":4,"inbound":1,"revisions":22,"impact":58,"core":false,"references":[9,22,23,141],"lastModified":"2026-02-27"},{"number":146,"title":"Dealing with signature encoding malleability","authors":["Johnson Lau","Pieter Wuille"],"status":"Closed","type":"Specification","layer":"Consensus (soft fork)","created":"2016-08-16","license":"PD","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This document specifies proposed changes to the Bitcoin transaction validity rules to fix signature malleability related to ECDSA signature encoding.","eli5":"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 reliable to track and build upon unconfirmed transactions.","categories":["consensus","security","validation"],"filename":"bip-0146.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0146.mediawiki","format":"mediawiki","readingMinutes":4,"inbound":2,"revisions":11,"impact":61,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":147,"title":"Dealing with dummy stack element malleability","authors":["Johnson Lau"],"status":"Deployed","type":"Specification","layer":"Consensus (soft fork)","created":"2016-09-02","license":"PD","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This document specifies proposed changes to the Bitcoin transaction validity rules to fix a malleability vector in the extra stack element consumed by OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY .","eli5":"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 could alter a transaction's ID.","categories":["segwit","consensus","security","malleability"],"filename":"bip-0147.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0147.mediawiki","format":"mediawiki","readingMinutes":2,"inbound":4,"revisions":12,"impact":84,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":148,"title":"Mandatory activation of segwit deployment","authors":["Shaolin Fry"],"status":"Deployed","type":"Specification","layer":"Consensus (soft fork)","created":"2017-03-12","license":"BSD-3-Clause OR CC0-1.0","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This document specifies a BIP16 like soft fork flag day activation of the segregated witness BIP9 deployment known as \"segwit\".","eli5":"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 and became a notable episode in Bitcoin governance.","categories":["segwit","consensus"],"filename":"bip-0148.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki","format":"mediawiki","readingMinutes":2,"inbound":2,"revisions":14,"impact":65,"core":false,"references":[9,16,141,143,147],"lastModified":"2025-10-22"},{"number":149,"title":"Segregated Witness (second deployment)","authors":["Shaolin Fry"],"status":"Closed","type":"Specification","layer":"Consensus (soft fork)","created":"2017-04-14","license":"BSD-3-Clause OR CC0-1.0","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This document specifies a user activated soft fork for BIP141 , BIP143 and BIP147 using versionbits with guaranteed lock-in.","eli5":"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 miner support.","categories":["consensus"],"filename":"bip-0149.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0149.mediawiki","format":"mediawiki","readingMinutes":1,"inbound":1,"revisions":9,"impact":33,"core":false,"references":[8,9,141,143,147],"lastModified":"2025-10-22"},{"number":150,"title":"Peer Authentication","authors":["Jonas Schnelli"],"status":"Closed","type":"Specification","layer":"Peer Services","created":"2016-03-23","license":"PD","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"comments":"https://github.com/bitcoin/bips/wiki/Comments:BIP-0150","abstract":"This BIP describes a way for peers to authenticate to other peers to guarantee node ownership and/or allow peers to access additional or limited node services, without the possibility of fingerprinting.","eli5":"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 authentication to fingerprint or track nodes.","categories":["network"],"filename":"bip-0150.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0150.mediawiki","format":"mediawiki","readingMinutes":6,"inbound":1,"revisions":11,"impact":37,"core":false,"references":[151],"lastModified":"2025-10-08"},{"number":151,"title":"Peer-to-Peer Communication Encryption","authors":["Jonas Schnelli"],"status":"Closed","type":"Specification","layer":"Peer Services","created":"2016-03-23","license":"PD","requires":[],"replaces":[],"replacedBy":[324],"discussion":[],"comments":"https://github.com/bitcoin/bips/wiki/Comments:BIP-0151","abstract":"This BIP describes an alternative way that a peer can encrypt their communication between a selective subset of remote peers.","eli5":"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 324.","categories":["privacy","transactions","network"],"filename":"bip-0151.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0151.mediawiki","format":"mediawiki","readingMinutes":6,"inbound":2,"revisions":20,"impact":75,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":152,"title":"Compact Block Relay","authors":["Matt Corallo"],"status":"Deployed","type":"Specification","layer":"Peer Services","created":"2016-04-27","license":"PD","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"comments":"https://github.com/bitcoin/bips/wiki/Comments:BIP-0152","abstract":"Compact blocks on the wire as a way to save bandwidth for nodes on the P2P network. The key words \"MUST\", \"MUST NOT\", \"REQUIRED\", \"SHALL\", \"SHALL NOT\", \"SHOULD\", \"SHOULD NOT\", \"RECOMMENDED\", \"MAY\", and \"OPTIONAL\" in this document are to be interpreted as described in RFC 2119.","eli5":"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 bandwidth and speeds up how quickly new blocks spread across the network.","categories":["network"],"filename":"bip-0152.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki","format":"mediawiki","readingMinutes":22,"inbound":1,"revisions":33,"impact":74,"core":false,"references":[],"lastModified":"2026-02-27"},{"number":154,"title":"Rate Limiting via peer specified challenges","authors":["Karl-Johan Alm"],"status":"Closed","type":"Specification","layer":"Peer Services","created":"2017-04-12","license":"BSD-2-Clause","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"An anti-DoS system which provides additional service for peers which perform proof of work.","eli5":"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 connections.","categories":["network"],"filename":"bip-0154.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0154.mediawiki","format":"mediawiki","readingMinutes":17,"inbound":0,"revisions":10,"impact":17,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":155,"title":"addrv2 message","authors":["Wladimir J. van der Laan"],"status":"Deployed","type":"Specification","layer":"Peer Services","created":"2019-02-27","license":"BSD-2-Clause","version":"2.1.1","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This document proposes a new P2P message to gossip longer node addresses over the P2P network. This is required to support new-generation Onion addresses, I2P, and potentially other networks that have longer endpoint addresses than fit in the 128 bits of the current addr message.","eli5":"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.","categories":["network"],"filename":"bip-0155.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0155.mediawiki","format":"mediawiki","readingMinutes":5,"inbound":0,"revisions":25,"impact":34,"core":false,"references":[],"lastModified":"2026-08-08"},{"number":156,"title":"Dandelion - Privacy Enhancing Routing","authors":["Brad Denby","Andrew Miller","Giulia Fanti","Surya Bakshi","Shaileshh Bojja Venkatakrishnan","Pramod Viswanath"],"status":"Closed","type":"Specification","layer":"Peer Services","created":"2017-06-09","license":"CC0-1.0","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"Bitcoin's transaction spreading protocol is vulnerable to deanonymization attacks. Dandelion is a transaction routing mechanism that provides formal anonymity guarantees against these attacks. When a node generates a transaction without Dandelion, it transmits that transaction to its peers with independent, exponential delays. This approach, known as diffusion in academia, allows network adversaries to link transactions to IP addresses. Dandelion mitigates this class of attacks by sending transactions over a randomly selected path before diffusion. Transactions travel along this path during the \"stem phase\" and are then diffused during the \"fluff phase\" (hence Dandelion). We have shown that this routing protocol provides near-optimal anonymity guarantees among schemes that do not introduce additional encryption mechanisms.","eli5":"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 transaction back to the IP address of the person who sent it.","categories":["network"],"filename":"bip-0156.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0156.mediawiki","format":"mediawiki","readingMinutes":11,"inbound":0,"revisions":9,"impact":15,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":157,"title":"Client Side Block Filtering","authors":["Olaoluwa Osuntokun","Alex Akselrod","Jim Posen"],"status":"Deployed","type":"Specification","layer":"Peer Services","created":"2017-05-24","license":"CC0-1.0","requires":[158],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This BIP describes a new light client protocol in Bitcoin that improves upon currently available options. The standard light client protocol in use today, defined in BIP 37, has known flaws that weaken the security and privacy of clients and allow denial-of-service attack vectors on full nodes. The new protocol overcomes these issues by allowing light clients to obtain compact probabilistic filters of block content from full nodes and download full blocks if the filter matches relevant data. New P2P messages empower light clients to securely sync the blockchain without relying on a trusted source. This BIP also defines a filter header, which serves as a commitment to all filters for previous blocks and provides the ability to efficiently detect malicious or faulty peers serving invalid filters. The resulting protocol guarantees that light clients with at least one honest peer are able to identify the correct block filters. https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki ↩ https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-May/012636.html ↩","eli5":"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 never tells the server which addresses it owns, improving privacy and reducing load on nodes.","categories":["network"],"filename":"bip-0157.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0157.mediawiki","format":"mediawiki","readingMinutes":14,"inbound":2,"revisions":14,"impact":65,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":158,"title":"Compact Block Filters for Light Clients","authors":["Olaoluwa Osuntokun","Alex Akselrod"],"status":"Deployed","type":"Specification","layer":"Peer Services","created":"2017-05-24","license":"CC0-1.0","requires":[157],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This BIP describes a structure for compact filters on block data, for use in the BIP 157 light client protocol. The filter construction proposed is an alternative to Bloom filters, as used in BIP 37, that minimizes filter size by using Golomb-Rice coding for compression. This document specifies one initial filter type based on this construction that enables basic wallets and applications with more advanced smart contracts. bip-0157.mediawiki ↩","eli5":"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 might contain their transactions without revealing their addresses to anyone.","categories":["wallets","network"],"filename":"bip-0158.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0158.mediawiki","format":"mediawiki","readingMinutes":10,"inbound":2,"revisions":30,"impact":78,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":159,"title":"NODE_NETWORK_LIMITED service bit","authors":["Jonas Schnelli"],"status":"Deployed","type":"Specification","layer":"Peer Services","created":"2017-05-11","license":"BSD-2-Clause","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"Define a service bit that allows pruned peers to signal their limited services.","eli5":"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 they cannot provide the full blockchain.","categories":["network"],"filename":"bip-0159.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0159.mediawiki","format":"mediawiki","readingMinutes":2,"inbound":0,"revisions":20,"impact":31,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":171,"title":"Currency/exchange rate information API","authors":["Luke Dashjr"],"status":"Closed","type":"Specification","layer":"Applications","created":"2017-03-04","license":"BSD-2-Clause","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"comments":"https://github.com/bitcoin/bips/wiki/Comments:BIP-0171","abstract":"A common interface for requesting currency exchange rate information from a server.","eli5":"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 for each one.","categories":["payments"],"filename":"bip-0171.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0171.mediawiki","format":"mediawiki","readingMinutes":8,"inbound":0,"revisions":8,"impact":14,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":172,"title":"Define Bitcoin Subunits as Satoshis","authors":["OceanSlim"],"status":"Draft","type":"Informational","layer":"Applications","created":"2025-05-01","license":"BSD-2-Clause","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"comments":"https://github.com/bitcoin/bips/wiki/Comments:BIP-0172","abstract":"This BIP proposes to formally define and standardize Bitcoin's smallest indivisible unit (1/100,000,000 of a bitcoin) as \"satoshi\" (singular) or \"satoshis\" (plural), with \"sats\" as the standard abbreviated form. This standardization aims to improve clarity in communication, user interfaces, documentation, and development across the Bitcoin ecosystem.","eli5":"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 amounts consistently.","categories":["blocks"],"filename":"bip-0172.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0172.mediawiki","format":"mediawiki","readingMinutes":5,"inbound":0,"revisions":3,"impact":6,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":173,"title":"Base32 address format for native v0-16 witness outputs","authors":["Pieter Wuille","Greg Maxwell"],"status":"Deployed","type":"Informational","layer":"Applications","created":"2017-03-20","license":"BSD-2-Clause","requires":[],"replaces":[142],"replacedBy":[350],"discussion":[],"comments":"https://github.com/bitcoin/bips/wiki/Comments:BIP-0173","abstract":"This document proposes a checksummed base32 format, \"Bech32\", and a standard for native segregated witness output addresses using it.","eli5":"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 addresses easier to read, type, and scan as QR codes.","categories":["addresses","bech32","segwit","encoding"],"filename":"bip-0173.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki","format":"mediawiki","readingMinutes":12,"inbound":5,"revisions":20,"impact":89,"core":true,"references":[350],"lastModified":"2025-10-08"},{"number":174,"title":"Partially Signed Bitcoin Transaction Format","authors":["Ava Chow"],"status":"Deployed","type":"Specification","layer":"Applications","created":"2017-07-12","license":"BSD-2-Clause","version":"1.4.4","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"comments":"https://github.com/bitcoin/bips/wiki/Comments:BIP-0174","abstract":"This document proposes a binary transaction format which contains the information necessary for a signer to produce signatures for the transaction and holds the signatures for an input while the input does not have a complete set of signatures. The signer can be offline as all necessary information will be provided in the transaction. The generic format is described here in addition to the specification for version 0 of this format.","eli5":"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 forth safely, which is essential for multisig setups and offline signing.","categories":["psbt","transactions","hardware-wallets"],"filename":"bip-0174.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki","format":"mediawiki","readingMinutes":25,"inbound":5,"revisions":116,"impact":96,"core":true,"references":[],"lastModified":"2026-09-23"},{"number":175,"title":"Pay to Contract Protocol","authors":["Omar Shibli","Nicholas Gregory"],"status":"Closed","type":"Informational","layer":"Applications","created":"2017-07-17","license":"BSD-2-Clause","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"Utilizing hierarchical deterministic wallets as described in BIP-0032 and the \"Purpose Field\" in BIP-0043, this document specifies the multiparty pay-to-contract key derivation scheme outlined by Ilja Gerhardt and Timo Hanke.[0] The key words \"MUST\", \"MUST NOT\", \"REQUIRED\", \"SHALL\", \"SHALL NOT\", \"SHOULD\", \"SHOULD NOT\", \"RECOMMENDED\", \"MAY\", and \"OPTIONAL\" in this document are to be interpreted as described in RFC 2119.","eli5":"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 customers later prove what a payment was for without extra on-chain data.","categories":["payments"],"filename":"bip-0175.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0175.mediawiki","format":"mediawiki","readingMinutes":5,"inbound":0,"revisions":13,"impact":22,"core":false,"references":[32,43,44],"lastModified":"2025-10-08"},{"number":176,"title":"Bits Denomination","authors":["Jimmy Song"],"status":"Complete","type":"Informational","created":"2017-12-12","license":"BSD-2-Clause","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"comments":"https://github.com/bitcoin/bips/wiki/Comments:BIP-0176","abstract":"Bits is presented here as the standard term for 100 (one hundred) satoshis or 1/1,000,000 (one one-millionth) of a bitcoin.","eli5":"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.","categories":["transactions"],"filename":"bip-0176.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0176.mediawiki","format":"mediawiki","readingMinutes":2,"inbound":0,"revisions":7,"impact":10,"core":false,"references":[],"lastModified":"2026-05-21"},{"number":177,"title":"Redefine Bitcoin's Base Unit","authors":["John Carvalho"],"status":"Draft","type":"Informational","created":"2025-04-23","license":"CC0-1.0","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This BIP proposes redefining the commonly recognized \"bitcoin\" unit so that the base unit becomes the primary reference unit. Under this proposal, one bitcoin is defined as that indivisible base unit, eliminating the convention of synthetic decimal places. By making the base unit the standard measure, this BIP aims to simplify user comprehension, reduce confusion, and align on-chain values directly with their displayed representation.","eli5":"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 actually counts value and would reduce confusion for newcomers.","categories":["blocks"],"filename":"bip-0177.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0177.mediawiki","format":"mediawiki","readingMinutes":5,"inbound":0,"revisions":4,"impact":8,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":178,"title":"Version Extended WIF","authors":["Karl-Johan Alm"],"status":"Draft","type":"Specification","layer":"Applications","created":"2018-04-04","license":"CC0-1.0","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"comments":"https://github.com/bitcoin/bips/wiki/Comments:BIP-0178","abstract":"An extension to the Wallet Import Format (WIF) to specify what kind of bitcoin address the private key corresponds to.","eli5":"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 between legacy, SegWit, and other address styles.","categories":["wallets"],"filename":"bip-0178.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0178.mediawiki","format":"mediawiki","readingMinutes":2,"inbound":0,"revisions":7,"impact":10,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":179,"title":"Name for payment recipient identifiers","authors":["Emil Engler","Luke Dashjr"],"status":"Complete","type":"Informational","created":"2019-10-17","license":"CC0-1.0","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This BIP proposes a new term for 'address'","eli5":"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.","categories":["transactions"],"filename":"bip-0179.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0179.mediawiki","format":"mediawiki","readingMinutes":1,"inbound":0,"revisions":6,"impact":9,"core":false,"references":[],"lastModified":"2026-07-22"},{"number":180,"title":"Block size/weight fraud proof","authors":["Luke Dashjr"],"status":"Closed","type":"Specification","layer":"Peer Services","created":"2017-03-17","license":"BSD-2-Clause","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"A fraud proof that enables light clients to detect oversized (or overweight) blocks.","eli5":"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 chain built with oversized blocks.","categories":["blocks"],"filename":"bip-0180.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0180.mediawiki","format":"mediawiki","readingMinutes":6,"inbound":0,"revisions":7,"impact":10,"core":false,"references":[141],"lastModified":"2025-10-08"},{"number":197,"title":"Hashed Time-Locked Collateral Contract","authors":["Matthew Black","Tony Cai"],"status":"Draft","type":"Specification","layer":"Applications","created":"2019-03-19","license":"BSD-3-Clause OR CC0-1.0","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This BIP describes a script for generalized debt agreement contract based on Hashed Time-Lock Contract (BIP 199) transactions according to the Atomic Loans specification ( https://arxiv.org/pdf/1901.05117.pdf ). For more details visit https://atomicloans.io .","eli5":"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, rather than relying on a trusted custodian.","categories":["transactions"],"filename":"bip-0197.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0197.mediawiki","format":"mediawiki","readingMinutes":8,"inbound":0,"revisions":10,"impact":17,"core":false,"references":[],"lastModified":"2025-10-22"},{"number":199,"title":"Hashed Time-Locked Contract transactions","authors":["Sean Bowe","Daira Hopwood"],"status":"Closed","type":"Specification","layer":"Applications","created":"2017-03-27","license":"BSD-3-Clause OR CC0-1.0","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"comments":"https://github.com/bitcoin/bips/wiki/Comments:BIP-0199","abstract":"This BIP describes a script for generalized off-chain contract negotiation.","eli5":"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 Network and for atomic swaps between blockchains.","categories":["smart-contracts","contracts"],"filename":"bip-0199.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0199.mediawiki","format":"mediawiki","readingMinutes":2,"inbound":0,"revisions":9,"impact":15,"core":false,"references":[],"lastModified":"2025-10-22"},{"number":300,"title":"Hashrate Escrows (Consensus layer)","authors":["Paul Sztorc","CryptAxe"],"status":"Draft","type":"Specification","layer":"Consensus (soft fork)","created":"2017-08-14","license":"BSD-2-Clause","requires":[],"replaces":[],"replacedBy":[],"discussion":["https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014364.html"],"abstract":"BIP-300 enables a new type of L2, where \"withdrawals\" (the L2-to-L1 txns) are governed by proof-of-work -- instead of a federation or fixed set of pubkeys. BIP-300 emphasizes slow, transparent, and auditable withdrawals that are easy for honest users to get right and hard for dishonest miners to abuse. The main design goal for BIP-300 is partitioning -- users can ignore BIP-300 txns if they wish; it makes no difference to L1 if the user validates all, some, or none of them. The second design goal is security -- users of the L2 should feel confident that, if the L2 network is paying a lot of fees , then miners will want to keep it around, and the withdrawals will therefore be processed accurately. Once BIP-300 has established a \"bridge\" between L1 and these L2s, users can swap coins in and out instantly, only using BIP-300 for final settlement. This setup allows Bitcoin to process all the transactions in the world, of any shape or size, regardless of blocksize, node software, tech stack, or decentralization level -- all without altering L1 at all.","eli5":"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 sidechain experiments while letting users who ignore them stay unaffected.","categories":["smart-contracts","contracts"],"filename":"bip-0300.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0300.mediawiki","format":"mediawiki","readingMinutes":10,"inbound":0,"revisions":28,"impact":49,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":301,"title":"Blind Merged Mining (Consensus layer)","authors":["Paul Sztorc","CryptAxe"],"status":"Draft","type":"Specification","layer":"Consensus (soft fork)","created":"2019-07-23","license":"BSD-2-Clause","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"Blind Merged Mining (BMM) allows SHA-256d miners to collect transaction fee revenue from other blockchains, without running any new software (i.e., without \"looking\" at those alt-chains, hence \"blind\"). Instead, this block-assembly work is done by alt-chain users. They choose the alt-chain block, and what txns go in it, the fees etc. Simultaneously, these users \"bid\" on L1 to win the right to be the sole creator of the alt-chain block. BIP-301 ensures that L1 miners only accept one bid (per 10 minutes, per L2 category), instead of taking all of them (which is what they would ordinarily do).","eli5":"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 revenue while keeping their workload unchanged.","categories":["consensus"],"filename":"bip-0301.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0301.mediawiki","format":"mediawiki","readingMinutes":4,"inbound":0,"revisions":14,"impact":23,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":310,"title":"Stratum protocol extensions","authors":["Pavel Moravec","Jan Čapek"],"status":"Draft","type":"Informational","layer":"Applications","created":"2018-03-10","license":"BSD-3-Clause OR CC0-1.0","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This BIP provides a generic mechanism for specifying stratum protocol extensions. At the same time, one of the important extensions that is specified by this BIP is configuration of bits for \"version rolling\" in nVersion field of bitcoin block header. The key words \"MUST\", \"MUST NOT\", \"REQUIRED\", \"SHALL\", \"SHALL NOT\", \"SHOULD\", \"SHOULD NOT\", \"RECOMMENDED\", \"MAY\", and \"OPTIONAL\" in this document are to be interpreted as described in RFC 2119.","eli5":"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 for valid blocks more efficiently.","categories":["contracts"],"filename":"bip-0310.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0310.mediawiki","format":"mediawiki","readingMinutes":7,"inbound":0,"revisions":9,"impact":15,"core":false,"references":[],"lastModified":"2025-10-22"},{"number":320,"title":"nVersion bits for general purpose use","authors":["BtcDrak"],"status":"Draft","type":"Specification","created":"2018-03-01","license":"BSD-3-Clause OR CC0-1.0","requires":[],"replaces":[],"replacedBy":[323],"discussion":[],"abstract":"This BIP reserves 16 bits of the block header nVersion field for general purpose use and removes their meaning for the purpose of version bits soft-fork signalling. The key words \"MUST\", \"MUST NOT\", \"REQUIRED\", \"SHALL\", \"SHALL NOT\", \"SHOULD\", \"SHOULD NOT\", \"RECOMMENDED\", \"MAY\", and \"OPTIONAL\" in this document are to be interpreted as described in RFC 2119.","eli5":"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 efficiently without confusing nodes about pending upgrades.","categories":["consensus"],"filename":"bip-0320.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0320.mediawiki","format":"mediawiki","readingMinutes":2,"inbound":0,"revisions":7,"impact":10,"core":false,"references":[8,9],"lastModified":"2026-05-12"},{"number":321,"title":"URI Scheme","authors":["Matt Corallo"],"status":"Complete","type":"Specification","layer":"Applications","created":"2024-11-15","license":"BSD-2-Clause","requires":[],"replaces":[21],"replacedBy":[],"discussion":[],"abstract":"This BIP proposes a URI scheme for describing Bitcoin payment instructions.","eli5":"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 a wallet with the details filled in.","categories":["payments"],"filename":"bip-0321.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0321.mediawiki","format":"mediawiki","readingMinutes":9,"inbound":2,"revisions":14,"impact":65,"core":false,"references":[21,351,352],"lastModified":"2026-07-31"},{"number":322,"title":"Generic Signed Message Format","authors":["Karl-Johan Alm","Oliver Gugger"],"status":"Complete","type":"Specification","layer":"Applications","created":"2018-09-10","license":"CC0-1.0","version":"2.0.0","requires":[174,340,341],"replaces":[],"replacedBy":[],"discussion":["https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-March/015818.html","https://github.com/bitcoin/bitcoin/pull/16440","https://github.com/bitcoin/bitcoin/pull/24058","https://bitcointalk.org/index.php?topic=5408898.0","https://groups.google.com/g/bitcoindev/c/RCi1Exs0ZvQ/m/vp6Xo36aBwAJ","https://bitcoin.stackexchange.com/questions/126277/where-can-i-use-bip322-to-sign-a-message-to-verify-a-multisig-address","https://groups.google.com/g/bitcoindev/c/qd6BNz9gxCk/m/k1fHq4RKAQAJ"],"abstract":"A standard for interoperable signed messages based on the Bitcoin Script format, either for proving availability of funds, or for committing to a message as the intended recipient of funds sent to the invoice address.","eli5":"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 different wallets can verify.","categories":["payments"],"filename":"bip-0322.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0322.mediawiki","format":"mediawiki","readingMinutes":12,"inbound":1,"revisions":52,"impact":83,"core":false,"references":[],"lastModified":"2026-06-04"},{"number":323,"title":"24 nVersion bits for general purpose use","authors":["Matt Corallo"],"status":"Draft","type":"Specification","created":"2026-04-22","license":"BSD-3-Clause OR CC0-1.0","requires":[],"replaces":[320],"replacedBy":[],"discussion":["https://groups.google.com/g/bitcoindev/c/fCfbi8hy-AE/m/g85UXI4qAAAJ"],"abstract":"24 bits are reserved in the nVersion field as extra nonce space for miners, providing for additional hashrate with header-only mining without relying on rolling nTime more often than once per second.","eli5":"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 more often than once per second.","categories":["payments"],"filename":"bip-0323.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0323.mediawiki","format":"mediawiki","readingMinutes":2,"inbound":0,"revisions":1,"impact":0,"core":false,"references":[],"lastModified":"2026-05-12"},{"number":324,"title":"Version 2 P2P Encrypted Transport Protocol","authors":["Dhruv Mehta","Tim Ruffing","Jonas Schnelli","Pieter Wuille"],"status":"Deployed","type":"Specification","layer":"Peer Services","created":"2019-03-08","license":"BSD-3-Clause","version":"1.0.2","requires":[],"replaces":[151],"replacedBy":[],"discussion":[],"abstract":"This document proposes a new Bitcoin P2P transport protocol, which features opportunistic encryption, a mild bandwidth reduction, and the ability to negotiate upgrades before exchanging application messages.","eli5":"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 protocol upgrades easier to negotiate.","categories":["consensus"],"filename":"bip-0324.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0324.mediawiki","format":"mediawiki","readingMinutes":41,"inbound":0,"revisions":22,"impact":32,"core":false,"references":[],"lastModified":"2026-08-18"},{"number":325,"title":"Signet","authors":["Karl-Johan Alm","Anthony Towns"],"status":"Complete","type":"Specification","layer":"Applications","created":"2019-03-20","license":"CC0-1.0","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"A new type of test network where signatures are used in addition to proof of work for block progress, enabling much better coordination and robustness (be reliably unreliable), for persistent, longer-term testing scenarios involving multiple independent parties.","eli5":"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 behavior of the older public testnet.","categories":["consensus"],"filename":"bip-0325.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0325.mediawiki","format":"mediawiki","readingMinutes":5,"inbound":0,"revisions":20,"impact":31,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":326,"title":"Anti-fee-sniping in taproot transactions","authors":["Chris Belcher"],"status":"Draft","type":"Informational","layer":"Applications","created":"2021-06-10","license":"CC0-1.0","requires":[],"replaces":[],"replacedBy":[],"discussion":["https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019048.html"],"abstract":"This document proposes a certain type of wallet behaviour which uses BIP341 taproot[1]. It provides a greater anonymity set for off-chain protocols which will make use of point-time-locked contracts (PTLCs) such as CoinSwap, Lightning and Discrete Log Contracts.","eli5":"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 ordinary payments look like off-chain protocol transactions, such as Lightning, helps both blend in and improves privacy.","categories":["consensus"],"filename":"bip-0326.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0326.mediawiki","format":"mediawiki","readingMinutes":5,"inbound":0,"revisions":8,"impact":14,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":327,"title":"MuSig2 for BIP340-compatible Multi-Signatures","authors":["Jonas Nick","Tim Ruffing","Elliott Jin"],"status":"Deployed","type":"Informational","created":"2022-03-22","license":"BSD-3-Clause","version":"1.0.4","requires":[],"replaces":[],"replacedBy":[],"discussion":["https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020198.html","https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021000.html"],"abstract":"This document proposes a standard for the MuSig2 multi-signature scheme. The standard is compatible with BIP340 public keys and signatures. It supports tweaking , which allows deriving BIP32 child keys from aggregate public keys and creating BIP341 Taproot outputs with key and script paths.","eli5":"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 outsiders cannot tell a multi-party spend from a single-owner one.","categories":["transactions"],"filename":"bip-0327.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0327.mediawiki","format":"mediawiki","readingMinutes":44,"inbound":5,"revisions":20,"impact":89,"core":false,"references":[],"lastModified":"2026-08-19"},{"number":328,"title":"Derivation Scheme for MuSig2 Aggregate Keys","authors":["Ava Chow"],"status":"Complete","type":"Informational","layer":"Applications","created":"2024-06-04","license":"CC0-1.0","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This document specifies how BIP 32 extended public keys can be constructed from a BIP 327 MuSig2 aggregate public key and how such keys should be used for key derivation.","eli5":"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 HD wallets do.","categories":["wallets"],"filename":"bip-0328.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0328.mediawiki","format":"mediawiki","readingMinutes":2,"inbound":2,"revisions":9,"impact":59,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":329,"title":"Wallet Labels Export Format","authors":["Craig Raw"],"status":"Draft","type":"Informational","layer":"Applications","created":"2022-08-23","license":"BSD-2-Clause","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This document specifies a format for the export of labels that may be attached to various common types of records in a wallet.","eli5":"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 privacy.","categories":["wallets"],"filename":"bip-0329.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0329.mediawiki","format":"mediawiki","readingMinutes":7,"inbound":0,"revisions":15,"impact":25,"core":false,"references":[],"lastModified":"2026-04-27"},{"number":330,"title":"Transaction announcements reconciliation","authors":["Gleb Naumenko","Pieter Wuille"],"status":"Draft","type":"Specification","layer":"Peer Services","created":"2019-09-25","license":"CC0-1.0","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This document specifies a P2P protocol extension for reconciliation of transaction announcements between 2 nodes , which is a building block for efficient transaction relay protocols (e.g., Erlay ). This is a step towards increasing the connectivity of the network for almost no bandwidth cost.","eli5":"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 connections while using much less bandwidth.","categories":["transactions"],"filename":"bip-0330.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0330.mediawiki","format":"mediawiki","readingMinutes":14,"inbound":0,"revisions":11,"impact":20,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":331,"title":"Ancestor Package Relay","authors":["Gloria Zhao"],"status":"Draft","type":"Specification","layer":"Peer Services","created":"2022-08-08","license":"BSD-3-Clause","requires":[],"replaces":[],"replacedBy":[],"discussion":["https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020493.html"],"abstract":"Peer-to-peer protocol messages enabling nodes to request and relay the unconfirmed ancestor package of a given transaction, and to request and relay transactions in batches.","eli5":"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, which matters for fee bumping and Lightning.","categories":["transactions"],"filename":"bip-0331.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0331.mediawiki","format":"mediawiki","readingMinutes":18,"inbound":0,"revisions":7,"impact":10,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":332,"title":"Stale Tip Relay","authors":["Anthony Towns","w0xlt","Ram"],"status":"Draft","type":"Specification","layer":"Peer Services","created":"2026-08-21","license":"BSD-3-Clause","version":"0.1.0","requires":[434],"replaces":[],"replacedBy":[],"discussion":["https://gnusha.org/pi/bitcoindev/d92f1615-368b-4406-b326-a1799c72a555n@googlegroups.com/"],"abstract":"Bitcoin miners sporadically produce stale blocks: valid blocks or valid block headers that do not become part of the node's active chain. This BIP defines a new optional peer-to-peer (P2P) staletip message for announcing recent stale chain tips to peers. The announcement includes the stale branch headers and whether the sender is willing to serve corresponding stale block data.","eli5":"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.","categories":["network"],"filename":"bip-0332.md","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0332.md","format":"markdown","readingMinutes":22,"inbound":0,"revisions":1,"impact":0,"core":false,"references":[],"lastModified":"2026-08-21"},{"number":337,"title":"Compressed Transactions","authors":["Tom Briar"],"status":"Draft","type":"Specification","layer":"API/RPC","created":"2024-02-01","license":"BSD-3-Clause","requires":[],"replaces":[],"replacedBy":[],"discussion":["https://github.com/bitcoin/bitcoin/pull/29134","https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-August/021924.html"],"abstract":"This document proposes a serialization scheme for compressing Bitcoin transactions. The compressed Bitcoin transactions can reach a serialized size of less than 50% of the original serialized transaction. One method for compressing involves reducing the transaction outpoints in a potentially lossy way. Therefore, it is an optional path for compression. Compressing the outpoints is necessary for compressed transactions to reach less than 70% of the original size.","eli5":"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.","categories":["transactions"],"filename":"bip-0337.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0337.mediawiki","format":"mediawiki","readingMinutes":6,"inbound":0,"revisions":7,"impact":10,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":338,"title":"Disable transaction relay message","authors":["Suhas Daftuar"],"status":"Closed","type":"Specification","layer":"Peer Services","created":"2020-09-03","license":"BSD-2-Clause","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This BIP describes a change to the p2p protocol to allow a node to tell a peer that a connection will not be used for transaction relay, to support block-relay-only connections that are currently in use on the network.","eli5":"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 isolate them while revealing less about the transactions they see.","categories":["consensus"],"filename":"bip-0338.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0338.mediawiki","format":"mediawiki","readingMinutes":4,"inbound":0,"revisions":9,"impact":15,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":339,"title":"WTXID-based transaction relay","authors":["Suhas Daftuar"],"status":"Deployed","type":"Specification","layer":"Peer Services","created":"2020-02-03","license":"BSD-2-Clause","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This BIP describes two changes to the p2p protocol to support transaction relay based on the BIP 141 wtxid of a transaction, rather than its txid.","eli5":"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, which could cause nodes to wrongly reject or repeatedly re-download valid transactions, so the switch makes relay more efficient and robust.","categories":["transactions"],"filename":"bip-0339.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0339.mediawiki","format":"mediawiki","readingMinutes":2,"inbound":0,"revisions":10,"impact":17,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":340,"title":"Schnorr Signatures for secp256k1","authors":["Pieter Wuille","Jonas Nick","Tim Ruffing"],"status":"Deployed","type":"Specification","created":"2020-01-19","license":"BSD-2-Clause","requires":[],"replaces":[],"replacedBy":[],"discussion":["https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-July/016203.html"],"comments":"https://github.com/bitcoin/bips/wiki/Comments:BIP-0340","abstract":"This document proposes a standard for 64-byte Schnorr signatures over the elliptic curve secp256k1 .","eli5":"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 several signers to combine their keys and signatures into one, enabling cheaper and more private multi-party transactions.","categories":["taproot","schnorr","signatures","privacy"],"filename":"bip-0340.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki","format":"mediawiki","readingMinutes":26,"inbound":13,"revisions":58,"impact":98,"core":true,"references":[32,62,66,118,146,327,341],"lastModified":"2025-10-22"},{"number":341,"title":"Taproot: SegWit version 1 spending rules","authors":["Pieter Wuille","Jonas Nick","Anthony Towns"],"status":"Deployed","type":"Specification","layer":"Consensus (soft fork)","created":"2020-01-19","license":"BSD-3-Clause","requires":[340],"replaces":[],"replacedBy":[],"discussion":["https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016914.html","https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-October/017378.html"],"comments":"https://github.com/bitcoin/bips/wiki/Comments:BIP-0341","abstract":"This document proposes a new SegWit version 1 output type, with spending rules based on Taproot, Schnorr signatures, and Merkle branches.","eli5":"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 a result, complex arrangements like multisig or timelocked contracts can look like ordinary payments on-chain, improving privacy and reducing fees.","categories":["taproot","scripts","smart-contracts"],"filename":"bip-0341.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki","format":"mediawiki","readingMinutes":28,"inbound":17,"revisions":50,"impact":99,"core":true,"references":[9,98,114,117,118,141,143,342,350],"lastModified":"2025-10-08"},{"number":342,"title":"Validation of Taproot Scripts","authors":["Pieter Wuille","Jonas Nick","Anthony Towns"],"status":"Deployed","type":"Specification","layer":"Consensus (soft fork)","created":"2020-01-19","license":"BSD-3-Clause","requires":[340,341],"replaces":[],"replacedBy":[],"discussion":["https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016914.html"],"abstract":"This document specifies the semantics of the initial scripting system under BIP341 .","eli5":"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 unused instructions so future upgrades can add new features more easily and safely.","categories":["taproot","signatures","validation"],"filename":"bip-0342.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki","format":"mediawiki","readingMinutes":15,"inbound":11,"revisions":21,"impact":95,"core":true,"references":[65,112,141],"lastModified":"2026-02-27"},{"number":343,"title":"Mandatory activation of taproot deployment","authors":["Shinobius","Michael Folkson"],"status":"Closed","type":"Specification","layer":"Consensus (soft fork)","created":"2021-04-25","license":"BSD-3-Clause OR CC0-1.0","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This document specifies a BIP8 (LOT=true) deployment to activate taproot.","eli5":"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 as a guarantee that the upgrade could not be indefinitely stalled by miners, though Taproot ultimately activated through miner signaling.","categories":["consensus"],"filename":"bip-0343.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0343.mediawiki","format":"mediawiki","readingMinutes":3,"inbound":0,"revisions":11,"impact":20,"core":false,"references":[8,148,340,341,342],"lastModified":"2026-06-01"},{"number":345,"title":"OP_VAULT","authors":["James O'Beirne","Greg Sanders"],"status":"Closed","type":"Specification","layer":"Consensus (soft fork)","created":"2023-02-03","license":"BSD-3-Clause","requires":[],"replaces":[],"replacedBy":[443],"discussion":["https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021318.html","https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-March/021510.html"],"abstract":"Introduction This BIP proposes two new tapscript opcodes that add consensus support for a specialized covenant: OP_VAULT and OP_VAULT_RECOVER . These opcodes, in conjunction with OP_CHECKTEMPLATEVERIFY ( BIP-0119 ), allow users to enforce a delay period before designated coins may be spent to an arbitrary destination, with the exception of a prespecified \"recovery\" path. At any time prior to final","eli5":"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 people a way to claw back funds if their keys are stolen, before the thief can complete the theft.","categories":["consensus"],"filename":"bip-0345.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0345.mediawiki","format":"mediawiki","readingMinutes":26,"inbound":2,"revisions":32,"impact":80,"core":false,"references":[],"lastModified":"2026-02-27"},{"number":346,"title":"OP_TXHASH","authors":["Steven Roose","Brandon Black"],"status":"Draft","type":"Specification","layer":"Consensus (soft fork)","created":"2024-04-24","license":"BSD-3-Clause","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This BIP proposes a new opcode OP_TXHASH , to be activated as a change to the semantics of OP_SUCCESS189 in tapscript contexts. This opcode provides a generalized method for introspecting certain details of the spending transaction, which enables non-interactive enforcement of certain properties of the transaction spending a certain UTXO. Together with an opcode like OP_CHECKSIGFROMSTACK , this opcode effectively provides a fully generalized signature hash construction, fully supporting all existing SIGHASH flags, the proposed sighash flags from BIP-118 ( SIGHASH_ANYPREVOUT ) and many other new signature hash combinations. The constructions specified in this BIP also open up the way for other potential updates; see Motivation section for more details.","eli5":"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 data, it could support flexible spending restrictions (covenants) and new kinds of second-layer protocols.","categories":["consensus"],"filename":"bip-0346.md","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0346.md","format":"markdown","readingMinutes":11,"inbound":1,"revisions":2,"impact":28,"core":false,"references":[118,119,345,347,348,443],"lastModified":"2026-02-04"},{"number":347,"title":"OP_CAT in Tapscript","authors":["Ethan Heilman","Armin Sabouri"],"status":"Complete","type":"Specification","layer":"Consensus (soft fork)","created":"2023-12-11","license":"BSD-3-Clause","version":"1.0.0","requires":[340,341,342],"replaces":[],"replacedBy":[],"discussion":["https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022049.html"],"abstract":"This BIP introduces OP_CAT as a tapscript opcode which allows the concatenation of two values on the stack. OP_CAT would be activated via a soft fork by redefining the opcode OP_SUCCESS126 (126 in decimal and 0x7e in hexadecimal). This is the same opcode value used by the original OP_CAT.","eli5":"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 make many advanced constructions possible, including spending restrictions (covenants) and more expressive smart contracts.","categories":["consensus"],"filename":"bip-0347.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0347.mediawiki","format":"mediawiki","readingMinutes":8,"inbound":2,"revisions":27,"impact":76,"core":false,"references":[3],"lastModified":"2026-04-23"},{"number":348,"title":"CHECKSIGFROMSTACK","authors":["Brandon Black","Jeremy Rubin"],"status":"Draft","type":"Specification","layer":"Consensus (soft fork)","created":"2024-11-26","license":"BSD-3-Clause","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This BIP describes a new opcode for the purpose of checking cryptographic signatures in bitcoin scripts against data from the stack.","eli5":"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 from outside parties (oracles), and building more efficient second-layer protocols.","categories":["consensus"],"filename":"bip-0348.md","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0348.md","format":"markdown","readingMinutes":4,"inbound":2,"revisions":10,"impact":60,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":349,"title":"OP_INTERNALKEY","authors":["Brandon Black","Jeremy Rubin"],"status":"Draft","type":"Specification","layer":"Consensus (soft fork)","created":"2024-11-14","license":"BSD-3-Clause","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This BIP describes a new tapscript opcode ( OP_INTERNALKEY ) which pushes the taproot internal key to the stack.","eli5":"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 designed to complement other proposed instructions for advanced contracts.","categories":["wallets"],"filename":"bip-0349.md","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0349.md","format":"markdown","readingMinutes":2,"inbound":1,"revisions":11,"impact":37,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":350,"title":"Bech32m format for v1+ witness addresses","authors":["Pieter Wuille"],"status":"Deployed","type":"Specification","layer":"Applications","created":"2020-12-16","license":"BSD-2-Clause","requires":[],"replaces":[173],"replacedBy":[],"discussion":["https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-January/018338.html"],"abstract":"This document defines an improved variant of Bech32 called Bech32m , and amends BIP173 to use Bech32m for native segregated witness outputs of version 1 and later. Bech32 remains in use for segregated witness outputs of version 0.","eli5":"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 and later address types to keep address error-checking reliable.","categories":["addresses","bech32","encoding"],"filename":"bip-0350.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki","format":"mediawiki","readingMinutes":15,"inbound":6,"revisions":15,"impact":91,"core":true,"references":[141,173],"lastModified":"2025-10-08"},{"number":351,"title":"Private Payments","authors":["Alfred Hodler","Clark Moody"],"status":"Closed","type":"Specification","layer":"Applications","created":"2022-07-10","license":"MIT","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This BIP makes it possible for two parties to transact using addresses that only they can calculate. This is done using exclusively on-chain methods and in a manner that minimizes blockchain footprint. Receiving parties can share their payment codes publicly without a loss of privacy, as every sender will calculate a unique set of addresses for each payment code.","eli5":"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 relationship, so receivers gain privacy without reusing addresses or handing out a fresh one for every payment.","categories":["wallets"],"filename":"bip-0351.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0351.mediawiki","format":"mediawiki","readingMinutes":10,"inbound":1,"revisions":12,"impact":41,"core":false,"references":[32,43,44,47,157,158],"lastModified":"2026-07-22"},{"number":352,"title":"Silent Payments","authors":["josibake","Ruben Somsen","Sebastian Falbesoner"],"status":"Complete","type":"Specification","layer":"Applications","created":"2023-03-09","license":"BSD-2-Clause","version":"1.1.1","requires":[340,341,350],"replaces":[],"replacedBy":[],"discussion":["https://gist.github.com/RubenSomsen/c43b79517e7cb701ebf77eec6dbb46b8","https://gnusha.org/pi/bitcoindev/CAPv7TjbXm953U2h+-12MfJ24YqOM5Kcq77_xFTjVK+R2nf-nYg@mail.gmail.com/","https://gnusha.org/pi/bitcoindev/P_21MLHGJicZ-hkbC4DGu86c5BtNKiH8spY4TOw5FJsfimdi_6VyHzU_y-s1mZsOcC2FA3EW_6w6W5qfV9dRK_7AvTAxDlwVfU-yhWZPEuo=@protonmail.com/","https://gnusha.org/pi/bitcoindev/ZM03twumu88V2NFH@petertodd.org/"],"abstract":"This document specifies a protocol for static payment addresses in Bitcoin without on-chain linkability of payments or a need for on-chain notifications.","eli5":"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 transaction, improving privacy for donations and repeat payments at the cost of more work for the receiver's wallet when scanning.","categories":["bech32","addresses"],"filename":"bip-0352.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0352.mediawiki","format":"mediawiki","readingMinutes":34,"inbound":6,"revisions":34,"impact":93,"core":false,"references":[],"lastModified":"2026-09-24"},{"number":353,"title":"DNS Payment Instructions","authors":["Matt Corallo","Bastien Teinturier"],"status":"Complete","type":"Specification","layer":"Applications","created":"2024-02-10","license":"CC0-1.0","requires":[],"replaces":[],"replacedBy":[],"discussion":["https://groups.google.com/g/bitcoindev/c/uATaflkYglQ"],"abstract":"This BIP proposes a standard format for encoding BIP 21 URI schemes in DNS TXT records.","eli5":"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 to be verified, making it easier to pay someone without copying long addresses.","categories":["wallets"],"filename":"bip-0353.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0353.mediawiki","format":"mediawiki","readingMinutes":10,"inbound":0,"revisions":18,"impact":30,"core":false,"references":[21,321,352],"lastModified":"2026-09-03"},{"number":360,"title":"Pay-to-Merkle-Root (P2MR)","authors":["Hunter Beast","Ethan Heilman","Isabel Foxen Duke"],"status":"Draft","type":"Specification","layer":"Consensus (soft fork)","created":"2024-12-18","license":"BSD-3-Clause","version":"0.12.1","requires":[340,341,342],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This document proposes a new output type: Pay-to-Merkle-Root (P2MR), via a soft fork. P2MR outputs operate with nearly the same functionality as P2TR (Pay-to-Taproot) outputs, but with the key path spend removed. Through this modification, P2MR outputs allow developers to use script trees and tapscript in a manner that is: resistant to long exposure attacks by Cryptographically Relevant Quantum Computers (CRQCs), and resistant to future cryptanalytic approaches that may compromise the elliptic curve cryptography (ECC) used by Bitcoin. It is worth noting that proposed P2MR outputs are only resistant to \"long exposure attacks\" on elliptic curve cryptography; that is, attacks on keys exposed for time periods longer than needed to confirm a spending transaction. Protection against more sophisticated quantum attacks, including protection against private key recovery from public keys exposed in the mempool while a transaction is waiting to be confirmed (a.k.a. \"short exposure attacks\"), may require the introduction of post-quantum signatures in Bitcoin. We believe it's worth considering this path in the future and intend to offer a separate proposal for this purpose upon further research. This document additionally defines \"long exposure\" and \"short exposure\" attacks, and other new terminology in the Glossary.","eli5":"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 better protected against future quantum computers that could break the cryptography behind exposed public keys.","categories":["consensus"],"filename":"bip-0360.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0360.mediawiki","format":"mediawiki","readingMinutes":25,"inbound":0,"revisions":6,"impact":9,"core":false,"references":[3,16,141,173,347,350],"lastModified":"2026-07-28"},{"number":361,"title":"Post Quantum Migration and Legacy Signature Sunset","authors":["Jameson Lopp","Christian Papathanasiou","Ian Smith","Joe Ross","Steve Vaile","Pierre-Luc Dallaire-Demers"],"status":"Draft","type":"Informational","layer":"Consensus (soft fork)","created":"2026-02-11","license":"BSD-3-Clause","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This proposal follows the implementation of any post-quantum (PQ) output type and introduces a pre-announced sunset of legacy ECDSA/Schnorr signatures. It turns quantum security into a private incentive: fail to upgrade and you will encounter additional friction to access your funds, creating a certainty where none previously existed. Phase A : Disallows sending of any funds to quantum-vulnerable addresses, hastening the adoption of PQ address types. Phase B : Restricts ECDSA/Schnorr spends by encumbering them with a quantum-safe rescue protocol, preventing theft of funds in quantum-vulnerable UTXOs. This is triggered by a well-publicized flag-day five years after activation.","eli5":"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, spending with old signatures would be restricted to a quantum-safe recovery process, aiming to prevent mass theft of unmoved coins.","categories":["consensus"],"filename":"bip-0361.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0361.mediawiki","format":"mediawiki","readingMinutes":7,"inbound":0,"revisions":3,"impact":6,"core":false,"references":[32],"lastModified":"2026-04-17"},{"number":370,"title":"PSBT Version 2","authors":["Ava Chow"],"status":"Deployed","type":"Specification","layer":"Applications","created":"2021-01-14","license":"BSD-2-Clause","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This document proposes a second version of the Partially Signed Bitcoin Transaction format described in BIP 174 which allows for inputs and outputs to be added to the PSBT after creation.","eli5":"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 is created, which makes collaborative transactions like CoinJoins or payjoins easier to build.","categories":["psbt","transactions"],"filename":"bip-0370.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0370.mediawiki","format":"mediawiki","readingMinutes":13,"inbound":3,"revisions":34,"impact":86,"core":false,"references":[],"lastModified":"2026-09-07"},{"number":371,"title":"Taproot Fields for PSBT","authors":["Ava Chow"],"status":"Deployed","type":"Specification","layer":"Applications","created":"2021-06-21","license":"BSD-2-Clause","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This document proposes additional fields for BIP 174 PSBTv0 and BIP 370 PSBTv2 that allow for BIP 340/341/342 Taproot data to be included in a PSBT of any version. These will be fields for signatures and scripts that are relevant to the creation of Taproot inputs.","eli5":"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 Taproot spends correctly.","categories":["psbt","transactions"],"filename":"bip-0371.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0371.mediawiki","format":"mediawiki","readingMinutes":7,"inbound":1,"revisions":22,"impact":58,"core":false,"references":[],"lastModified":"2026-09-07"},{"number":372,"title":"Pay-to-contract tweak fields for PSBT","authors":["Maxim Orlovsky"],"status":"Draft","type":"Specification","layer":"Applications","created":"2022-01-16","license":"BSD-2-Clause","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This document proposes additional fields for BIP 174 PSBTv0 and BIP 370 PSBTv2 that allow for pay-to-contract (P2C) key tweaking data to be included in a PSBT of any version. These will represent extra-transaction information required for the signer to produce valid signatures spending previous outputs.","eli5":"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 devices need this data to spend such coins, so the fields allow those coins to flow through standard PSBT workflows.","categories":["transactions"],"filename":"bip-0372.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0372.mediawiki","format":"mediawiki","readingMinutes":5,"inbound":0,"revisions":14,"impact":23,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":373,"title":"MuSig2 PSBT Fields","authors":["Ava Chow"],"status":"Complete","type":"Specification","layer":"Applications","created":"2024-06-04","license":"CC0-1.0","requires":[32,174,327,328,370],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This document proposes additional fields for BIP 174 PSBTv0 and BIP 370 PSBTv2 that allow for BIP 327 MuSig2 Multi-Signature data to be included in a PSBT of any version. These will be fields for the participants' keys, the public nonces, and the partial signatures produced with MuSig2.","eli5":"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 wallets and hardware devices to coordinate such multi-party signing.","categories":["wallets"],"filename":"bip-0373.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0373.mediawiki","format":"mediawiki","readingMinutes":9,"inbound":0,"revisions":18,"impact":30,"core":false,"references":[340,341],"lastModified":"2025-10-08"},{"number":374,"title":"Discrete Log Equality Proofs","authors":["Andrew Toth","Ruben Somsen","Sebastian Falbesoner"],"status":"Draft","type":"Specification","layer":"Applications","created":"2024-12-26","license":"BSD-2-Clause","version":"0.3.0","requires":[],"replaces":[],"replacedBy":[],"discussion":["https://gist.github.com/andrewtoth/df97c3260cc8d12f09d3855ee61322ea","https://groups.google.com/g/bitcoindev/c/MezoKV5md7s"],"abstract":"This document proposes a standard for 64-byte zero-knowledge discrete logarithm equality proofs (DLEQ proofs) over an elliptic curve. For given elliptic curve points A , B , C , G , and a scalar a known only to the prover where A = a⋅G and C = a⋅B , the prover proves knowledge of a without revealing anything about a . This can, for instance, be useful in ECDH: if A and B are ECDH public keys, and C is their ECDH shared secret computed as C = a⋅B , the proof establishes that the same secret key a is used for generating both A and C without revealing a .","eli5":"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 honestly, which helps protocols like Silent Payments work safely with hardware wallets and multiple signers.","categories":["wallets"],"filename":"bip-0374.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0374.mediawiki","format":"mediawiki","readingMinutes":6,"inbound":1,"revisions":18,"impact":55,"core":false,"references":[],"lastModified":"2026-08-19"},{"number":375,"title":"Sending Silent Payments with PSBTs","authors":["Andrew Toth","Ava Chow","josibake"],"status":"Draft","type":"Specification","layer":"Applications","created":"2025-01-08","license":"BSD-2-Clause","version":"0.1.2","requires":[352,370,374],"replaces":[],"replacedBy":[],"discussion":["https://groups.google.com/g/bitcoindev/c/5G5wzqUXyk4"],"abstract":"This document proposes additional fields and updated role responsibilities for BIP370 PSBTv2 which adds support for sending to silent payments as described in BIP352.","eli5":"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 lets multiple devices or parties safely work out and verify that address together.","categories":["wallets"],"filename":"bip-0375.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0375.mediawiki","format":"mediawiki","readingMinutes":11,"inbound":0,"revisions":17,"impact":29,"core":false,"references":[],"lastModified":"2026-09-27"},{"number":376,"title":"Spending Silent Payment outputs with PSBTs","authors":["nymius"],"status":"Draft","type":"Specification","layer":"Applications","created":"2026-02-05","license":"BSD-2-Clause","requires":[352,370,371],"replaces":[],"replacedBy":[],"discussion":["https://delvingbitcoin.org/t/bip352-psbt-support/877/30","https://gist.github.com/nymius/b3dd0b8a08c6735d617e6216b73c4260","https://gnusha.org/pi/bitcoindev/R53cG3TeXgXDUUS4kH_q226GlaFCjI0DZVT6mdTQzSQdj3RnNqWA-bFT7uGgGQFJG6938kDGvDJVoFQj8ItEMsJ6NyOjCTvpVEarYiyW6-8=@proton.me/"],"abstract":"This document proposes additional per-input fields for BIP 370 PSBTv2 that allow BIP 352 Silent Payment tweaks to be included in a PSBT of version 2. These fields are relevant to Silent Payment output spending.","eli5":"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 carry that information so hardware wallets and other signers can spend them.","categories":["wallets"],"filename":"bip-0376.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0376.mediawiki","format":"mediawiki","readingMinutes":8,"inbound":0,"revisions":2,"impact":4,"core":false,"references":[],"lastModified":"2026-09-04"},{"number":379,"title":"Miniscript","authors":["Pieter Wuille","Andrew Poelstra","Sanket Kanjalkar","Antoine Poinsot","Ava Chow"],"status":"Draft","type":"Specification","layer":"Applications","created":"2023-10-10","license":"CC0-1.0","requires":[380],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This document specifies Miniscript, a language for writing (a subset of) Bitcoin Scripts in a structured way, enabling analysis, composition, generic signing and more.","eli5":"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, making complex setups like multisig with time-delayed backups less error-prone.","categories":["wallets"],"filename":"bip-0379.md","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0379.md","format":"markdown","readingMinutes":21,"inbound":2,"revisions":13,"impact":64,"core":false,"references":[141,342,382,386],"lastModified":"2026-09-17"},{"number":380,"title":"Output Script Descriptors General Operation","authors":["Pieter Wuille","Ava Chow"],"status":"Deployed","type":"Specification","layer":"Applications","created":"2021-06-27","license":"BSD-2-Clause","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"Output Script Descriptors are a simple language which can be used to describe collections of output scripts. There can be many different descriptor fragments and functions. This document describes the general syntax for descriptors, descriptor checksums, and common expressions.","eli5":"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 to back up and share wallet setups precisely.","categories":["encoding"],"filename":"bip-0380.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0380.mediawiki","format":"mediawiki","readingMinutes":10,"inbound":16,"revisions":27,"impact":99,"core":true,"references":[381,382,383,384,385,386,390,392],"lastModified":"2026-09-17"},{"number":381,"title":"Non-Segwit Output Script Descriptors","authors":["Pieter Wuille","Ava Chow"],"status":"Deployed","type":"Specification","layer":"Applications","created":"2021-06-27","license":"BSD-2-Clause","requires":[380],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This document specifies pk() , pkh() , and sh() output script descriptors. pk() descriptors take a key and produces a P2PK output script. pkh() descriptors take a key and produces a P2PKH output script. sh() descriptors take a script and produces a P2SH output script.","eli5":"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 descriptor-based wallets describe and recover coins held in these legacy formats.","categories":["encoding"],"filename":"bip-0381.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0381.mediawiki","format":"mediawiki","readingMinutes":2,"inbound":2,"revisions":15,"impact":67,"core":false,"references":[],"lastModified":"2026-09-17"},{"number":382,"title":"Segwit Output Script Descriptors","authors":["Pieter Wuille","Ava Chow"],"status":"Deployed","type":"Specification","layer":"Applications","created":"2021-06-27","license":"BSD-2-Clause","requires":[380],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This document specifies wpkh() , and wsh() output script descriptors. wpkh() descriptors take a key and produces a P2WPKH output script. wsh() descriptors take a script and produces a P2WSH output script.","eli5":"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.","categories":["wallets"],"filename":"bip-0382.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0382.mediawiki","format":"mediawiki","readingMinutes":2,"inbound":3,"revisions":13,"impact":77,"core":false,"references":[],"lastModified":"2026-09-17"},{"number":383,"title":"Multisig Output Script Descriptors","authors":["Pieter Wuille","Ava Chow"],"status":"Deployed","type":"Specification","layer":"Applications","created":"2021-06-27","license":"BSD-2-Clause","requires":[380],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This document specifies multi() , and sortedmulti() output script descriptors. Both functions take a threshold and one or more public keys and produce a multisig output script. multi() specifies the public keys in the output script in the order given in the descriptor while sortedmulti() sorts the public keys lexicographically when the output script is produced.","eli5":"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 wallets reproduce identical multisig addresses.","categories":["wallets"],"filename":"bip-0383.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0383.mediawiki","format":"mediawiki","readingMinutes":3,"inbound":2,"revisions":15,"impact":67,"core":false,"references":[],"lastModified":"2026-09-17"},{"number":384,"title":"combo() Output Script Descriptors","authors":["Pieter Wuille","Ava Chow"],"status":"Deployed","type":"Specification","layer":"Applications","created":"2021-06-27","license":"BSD-2-Clause","requires":[380],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This document specifies combo() output script descriptors. These take a key and produce P2PK, P2PKH, P2WPKH, and P2SH-P2WPKH output scripts if applicable to the key.","eli5":"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 importing an old key.","categories":["wallets"],"filename":"bip-0384.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0384.mediawiki","format":"mediawiki","readingMinutes":1,"inbound":1,"revisions":12,"impact":41,"core":false,"references":[],"lastModified":"2026-09-17"},{"number":385,"title":"raw() and addr() Output Script Descriptors","authors":["Pieter Wuille","Ava Chow"],"status":"Deployed","type":"Specification","layer":"Applications","created":"2021-06-27","license":"BSD-2-Clause","requires":[380],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This document specifies raw() and addr() output script descriptors. raw() encapsulates a raw script as a descriptor. addr() encapsulates an address as a descriptor.","eli5":"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 keys behind it.","categories":["wallets"],"filename":"bip-0385.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0385.mediawiki","format":"mediawiki","readingMinutes":1,"inbound":1,"revisions":11,"impact":37,"core":false,"references":[],"lastModified":"2026-09-17"},{"number":386,"title":"tr() Output Script Descriptors","authors":["Pieter Wuille","Ava Chow"],"status":"Deployed","type":"Specification","layer":"Applications","created":"2021-06-27","license":"BSD-2-Clause","requires":[380],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This document specifies tr() output script descriptors. tr() descriptors take a key and optionally a tree of scripts and produces a P2TR output script.","eli5":"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.","categories":["transactions"],"filename":"bip-0386.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0386.mediawiki","format":"mediawiki","readingMinutes":3,"inbound":2,"revisions":14,"impact":65,"core":false,"references":[341,379,387],"lastModified":"2026-09-17"},{"number":387,"title":"Tapscript Multisig Output Script Descriptors","authors":["Pieter Wuille","Ava Chow"],"status":"Deployed","type":"Specification","layer":"Applications","created":"2024-04-17","license":"BSD-2-Clause","requires":[380],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This document specifies multi_a() and sortedmulti_a() output script descriptors. Like BIP 383's multi() and sortedmulti() , both functions take a threshold and one or more public keys and produce a multisig script. The primary distinction is that multi_a() and sortedmulti_a() only produce tapscripts and are only allowed in a tapscript context.","eli5":"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 wallets describe Taproot multisig wallets consistently.","categories":["transactions"],"filename":"bip-0387.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0387.mediawiki","format":"mediawiki","readingMinutes":2,"inbound":1,"revisions":8,"impact":33,"core":false,"references":[],"lastModified":"2026-09-17"},{"number":388,"title":"Wallet Policies for Descriptor Wallets","authors":["Salvatore Ingala"],"status":"Complete","type":"Specification","layer":"Applications","created":"2023-12-26","license":"BSD-2-Clause","version":"1.1.0","requires":[],"replaces":[],"replacedBy":[],"discussion":["https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020423.html"],"abstract":"Software wallets and hardware signing devices typically partition funds into separate \"accounts\". When signing or visualizing a transaction, aggregate flows of funds of all accounts affected by the transaction may (and should) be displayed to the user. Wallet policies build on top of output script descriptors to represent such accounts in a compact, reviewable way. An account encompasses a logical group of receive and change addresses, and each wallet policy represents all descriptors necessary to describe an account in its entirety. We simplify the language to suit devices with limited memory, where even keeping the entire descriptor in memory could be a major hurdle, by reducing the generality of descriptors to just the essential features and by separating the extended pubkeys and other key information from the descriptor. This results in a more compact representation and simplifies the inspection of the policy by the user. The compilation of wallet policies to the corresponding descriptor is trivial, and the reverse process is easy for supported descriptors, because the language is kept similar to that of output script descriptors.","eli5":"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 and register complex setups like multisig before signing.","categories":["wallets"],"filename":"bip-0388.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0388.mediawiki","format":"mediawiki","readingMinutes":15,"inbound":1,"revisions":34,"impact":74,"core":false,"references":[32,44,48,49,84,86,129,327,379,380,389,390],"lastModified":"2026-04-15"},{"number":389,"title":"Multipath Descriptor Key Expressions","authors":["Ava Chow"],"status":"Draft","type":"Specification","layer":"Applications","created":"2022-07-26","license":"BSD-2-Clause","requires":[380],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This document specifies a modification to Key Expressions of Descriptors that are described in BIP 380. This modification allows Key Expressions to indicate BIP 32 derivation path steps that can have multiple values.","eli5":"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 identical descriptors separately.","categories":["wallets"],"filename":"bip-0389.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0389.mediawiki","format":"mediawiki","readingMinutes":4,"inbound":4,"revisions":12,"impact":84,"core":false,"references":[],"lastModified":"2026-09-17"},{"number":390,"title":"musig() Descriptor Key Expression","authors":["Ava Chow"],"status":"Draft","type":"Specification","layer":"Applications","created":"2024-06-04","license":"CC0-1.0","version":"0.2.0","requires":[380,328],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This document specifies a musig() key expression for output script descriptors. musig() expressions take multiple keys and produce an aggregate public key using BIP-327 .","eli5":"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 lets wallets describe and recover such shared setups.","categories":["signatures","wallets"],"filename":"bip-0390.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0390.mediawiki","format":"mediawiki","readingMinutes":3,"inbound":3,"revisions":17,"impact":80,"core":false,"references":[32,327,389],"lastModified":"2026-09-17"},{"number":391,"title":"Binary Output Descriptors","authors":["SeedHammer"],"status":"Closed","type":"Specification","layer":"Applications","created":"2026-01-27","license":"BSD-2-Clause","requires":[],"replaces":[],"replacedBy":[393],"discussion":[],"abstract":"This document proposes an efficient container format for encoding an output descriptor as defined by BIP 380 and its extensions. Based on key-value maps as defined by BIP 174 , the encoding supports descriptor and key metadata.","eli5":"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 for QR codes, hardware devices, and other space-constrained uses.","categories":["wallets"],"filename":"bip-0391.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0391.mediawiki","format":"mediawiki","readingMinutes":5,"inbound":0,"revisions":1,"impact":0,"core":false,"references":[174,380,389],"lastModified":"2026-04-23"},{"number":392,"title":"Silent Payment Output Script Descriptors","authors":["Craig Raw"],"status":"Draft","type":"Specification","layer":"Applications","created":"2026-02-06","license":"BSD-2-Clause","requires":[341,350,352,380],"replaces":[],"replacedBy":[],"discussion":["https://groups.google.com/g/bitcoindev/c/bP6ktUyCOJI"],"abstract":"This document specifies sp() output script descriptors for silent payments. sp() descriptors take silent payment key material and describe P2TR outputs when combined with sender input public keys as defined in BIP352.","eli5":"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 same standard descriptor tools as other wallets.","categories":["wallets","payments"],"filename":"bip-0392.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0392.mediawiki","format":"mediawiki","readingMinutes":3,"inbound":1,"revisions":1,"impact":27,"core":false,"references":[],"lastModified":"2026-03-05"},{"number":393,"title":"Output Script Descriptor Annotations","authors":["Craig Raw"],"status":"Draft","type":"Specification","layer":"Applications","created":"2026-03-17","license":"BSD-2-Clause","requires":[380],"replaces":[],"replacedBy":[],"discussion":["https://groups.google.com/g/bitcoindev/c/ozjr1lF3Rkc"],"abstract":"This document specifies an optional annotation syntax for output script descriptors as defined in BIP 380 . Annotations are key/value pairs appended to a descriptor expression using URL-like query string delimiters ( ? , & , = ). They convey operational metadata (such as a blockchain scan start height or gap limit) to aid recovery of funds without altering the scripts produced by the descriptor.","eli5":"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 which addresses the descriptor describes.","categories":["wallets"],"filename":"bip-0393.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0393.mediawiki","format":"mediawiki","readingMinutes":3,"inbound":0,"revisions":1,"impact":0,"core":false,"references":[32,352],"lastModified":"2026-04-07"},{"number":431,"title":"Topology Restrictions for Pinning","authors":["Gloria Zhao"],"status":"Draft","type":"Informational","layer":"Applications","created":"2024-01-10","license":"BSD-3-Clause","requires":[],"replaces":[],"replacedBy":[],"discussion":["https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019817.html","https://gist.github.com/glozow/25d9662c52453bd08b4b4b1d3783b9ff","https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020937.html","https://delvingbitcoin.org/t/v3-transaction-policy-for-anti-pinning/340","https://delvingbitcoin.org/t/lightning-transactions-with-v3-and-ephemeral-anchors/418"],"abstract":"This document describes pinning problems that can arise from limitations in mempool policy. It also describes a type of policy with adjusted topology limits which, combined with other policy rules, helps minimize the potential pinning problems. These restrictions simplify the assessment of incentive compatibility of accepting or replacing such transactions, thus helping ensure any replacements are more profitable for the node. Within the context of nodes that implement this policy, fee-bumping is more reliable for users.","eli5":"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 unconfirmed transactions can be chained together, making fee-bumping more reliable for transactions that opt into these rules.","categories":["mempool","network","transactions"],"filename":"bip-0431.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0431.mediawiki","format":"mediawiki","readingMinutes":15,"inbound":0,"revisions":5,"impact":8,"core":false,"references":[],"lastModified":"2025-10-08"},{"number":433,"title":"Pay to Anchor (P2A)","authors":["Gregory Sanders"],"status":"Draft","type":"Informational","layer":"Applications","created":"2025-12-08","license":"BSD-3-Clause","requires":[],"replaces":[],"replacedBy":[],"discussion":["https://github.com/bitcoin/bitcoin/pull/30352","https://bitcoinops.org/en/bitcoin-core-28-wallet-integration-guide/"],"abstract":"This document describes a new standard output script called Pay to Anchor (P2A) and prescribes making spending of this output type standard. This output is \"keyless\" meaning no signature or witness data at all are required to spend this output type.","eli5":"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 transaction confirmed, which is useful for Lightning and similar protocols.","categories":["signatures","transactions"],"filename":"bip-0433.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0433.mediawiki","format":"mediawiki","readingMinutes":2,"inbound":2,"revisions":6,"impact":58,"core":false,"references":[],"lastModified":"2026-09-13"},{"number":434,"title":"Peer Feature Negotiation","authors":["Anthony Towns"],"status":"Complete","type":"Specification","layer":"Peer Services","created":"2026-01-14","license":"BSD-2-Clause","version":"1.0.0","requires":[],"replaces":[],"replacedBy":[],"discussion":["https://gnusha.org/pi/bitcoindev/aUUXLgEUCgGb122o@erisian.com.au/T/#u","https://gnusha.org/pi/bitcoindev/20200821023647.7eat4goqqrtaqnna@erisian.com.au/"],"abstract":"This BIP defines a peer-to-peer (P2P) message that can be used for announcements and negotiation related to support of new peer-to-peer features.","eli5":"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 nodes communicate.","categories":["network"],"filename":"bip-0434.md","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0434.md","format":"markdown","readingMinutes":10,"inbound":1,"revisions":5,"impact":31,"core":false,"references":[],"lastModified":"2026-06-11"},{"number":440,"title":"Varops Budget For Script Runtime Constraint","authors":["Rusty Russell","Julian Moik"],"status":"Draft","type":"Specification","layer":"Consensus (soft fork)","created":"2026-03-25","license":"BSD-3-Clause","version":"0.2.1","requires":[],"replaces":[],"replacedBy":[],"discussion":["https://groups.google.com/g/bitcoindev/c/GisTcPb8Jco/m/8znWcWwKAQAJ","https://delvingbitcoin.org/t/benchmarking-bitcoin-script-evaluation-for-the-varops-budget-great-script-restoration/2094"],"abstract":"This BIP defines a \"varops budget\", which generalizes the \"sigops budget\" introduced in BIP342 to non-signature operations. This BIP is a useful framework for other BIPs to draw upon, and provides opcode examples which are always less restrictive than current rules.","eli5":"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 framework so other proposals can add more powerful script features without risking slow-to-verify blocks.","categories":["consensus","signatures"],"filename":"bip-0440.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0440.mediawiki","format":"mediawiki","readingMinutes":10,"inbound":1,"revisions":2,"impact":28,"core":false,"references":[342],"lastModified":"2026-06-15"},{"number":441,"title":"Restoration of disabled script (Tapleaf 0xC2)","authors":["Rusty Russell","Julian Moik"],"status":"Draft","type":"Specification","layer":"Consensus (soft fork)","created":"2026-03-25","license":"BSD-3-Clause","version":"0.2.2","requires":[440],"replaces":[],"replacedBy":[],"discussion":["https://groups.google.com/g/bitcoindev/c/GisTcPb8Jco/m/8znWcWwKAQAJ"],"abstract":"This BIP introduces a new tapleaf version (0xc2) which restores Bitcoin script to its pre-0.3.1 capability, relying on the Varops Budget in BIP440 to prevent the excessive computational time which caused CVE-2010-5137. In particular, this BIP: Reenables disabled opcodes. Increases the maximum stack object size from 520 bytes to 4,000,000 bytes. Introduces a total stack byte limit of 8,000,000 bytes. Increases the maximum total number of stack objects from 1,000 to 32,768. Removes the 32-bit size restriction on numerical values. Treats all numerical values as unsigned. All opcodes are described in exact (painstaking) byte-by-byte operations, so that their varops budget can be easily derived. Note that this level of detail is unnecessary to users of script, only being of interest to implementers.","eli5":"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 original restrictions, it relies on the computational budget defined in BIP 440.","categories":["consensus"],"filename":"bip-0441.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0441.mediawiki","format":"mediawiki","readingMinutes":17,"inbound":0,"revisions":4,"impact":8,"core":false,"references":[342],"lastModified":"2026-09-15"},{"number":442,"title":"OP_PAIRCOMMIT","authors":["moonsettler","Brandon Black"],"status":"Draft","type":"Specification","layer":"Consensus (soft fork)","created":"2024-12-09","license":"BSD-3-Clause","requires":[],"replaces":[],"replacedBy":[],"discussion":["https://delvingbitcoin.org/t/op-paircommit-as-a-candidate-for-addition-to-lnhance/1216","https://groups.google.com/g/bitcoindev/c/si6ZNIkVfOw/m/29VY_YRrCgAJ"],"abstract":"This BIP proposes a new tapscript opcode, OP_PAIRCOMMIT , which enables efficient and secure commitment to pairs of stack elements using a tagged hash construction. This opcode provides limited vector commitment functionality, facilitating more expressive contracts and improved data availability in Bitcoin scripts.","eli5":"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 protocols more efficient and expressive.","categories":["taproot","consensus"],"filename":"bip-0442.md","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0442.md","format":"markdown","readingMinutes":5,"inbound":0,"revisions":2,"impact":4,"core":false,"references":[],"lastModified":"2026-03-24"},{"number":443,"title":"OP_CHECKCONTRACTVERIFY","authors":["Salvatore Ingala"],"status":"Draft","type":"Specification","layer":"Consensus (soft fork)","created":"2025-05-08","license":"BSD-3-Clause","requires":[],"replaces":[],"replacedBy":[],"discussion":["https://gnusha.org/pi/bitcoindev/CAMhCMoH9uZPeAE_2tWH6rf0RndqV+ypjbNzazpFwFnLUpPsZ7g@mail.gmail.com","https://gnusha.org/pi/bitcoindev/CAMhCMoFYF+9NL1sqKfn=ma3C_mfQv7mj2fqbqO5WXVwd6vyhLw@mail.gmail.com"],"abstract":"This BIP proposes to add consensus support for a new tapscript opcode that enables a new type of output restrictions: OP_CHECKCONTRACTVERIFY ( OP_CCV ). This opcode enables users to create UTXOs that carry a dynamic commitment to a piece of data. The commitment can be validated during the execution of the script, allowing introspection to the committed data. Moreover, a script can constrain the internal public key and taptree of one or more outputs, and possibly the committed data. In conjunction with an opcode for vector commitments , this allows to create and compose arbitrary state machines that define the possible future outcomes of a UTXO. The validity of a state transition depends on the conditions that can be expressed in the program (scripts in the taptree). Vector commitments are cryptographic primitives that allow to commit to a vector of values via a single short value. Hashing and concatenation trivially allow to commit to an entire vector, and later reveal all of its elements. Merkle trees are among the simplest efficient vector commitments, allowing to reveal individual elements with logarithmically-sized proofs. ↩","eli5":"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 spending step must follow predefined rules.","categories":["taproot","consensus"],"filename":"bip-0443.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0443.mediawiki","format":"mediawiki","readingMinutes":13,"inbound":2,"revisions":12,"impact":62,"core":false,"references":[119,327,341,345],"lastModified":"2025-10-08"},{"number":446,"title":"OP_TEMPLATEHASH","authors":["Gregory Sanders","Antoine Poinsot","Steven Roose"],"status":"Draft","type":"Specification","layer":"Consensus (soft fork)","created":"2026-02-06","license":"CC0-1.0","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This document proposes a new operation for Tapscript: OP_TEMPLATEHASH . It introduces the ability to push on the stack a hash of the transaction spending an output.","eli5":"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 block for vaults and payment channel improvements.","categories":["taproot","consensus","transactions"],"filename":"bip-0446.md","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0446.md","format":"markdown","readingMinutes":7,"inbound":1,"revisions":1,"impact":27,"core":false,"references":[119,340,341,342],"lastModified":"2026-03-17"},{"number":448,"title":"Taproot-native (Re)bindable Transactions","authors":["Gregory Sanders","Antoine Poinsot","Steven Roose"],"status":"Draft","type":"Specification","layer":"Consensus (soft fork)","created":"2026-03-11","license":"CC0-1.0","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This document proposes deploying three new operations for Tapscript: BIP 446 OP_TEMPLATEHASH , BIP 348 OP_CHECKSIGFROMSTACK , and BIP 349 OP_INTERNALKEY . These minimal operations introduce modular functionalities which improve existing second layer protocols and make new ones possible through plausible interactivity requirements.","eli5":"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 new ones, improving Lightning and enabling other second-layer protocols.","categories":["taproot","consensus","transactions"],"filename":"bip-0448.md","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0448.md","format":"markdown","readingMinutes":3,"inbound":0,"revisions":1,"impact":0,"core":false,"references":[119,340,341,342,346,348,349,446],"lastModified":"2026-03-17"},{"number":449,"title":"OP_TWEAKADD - x-only key tweak addition","authors":["Jeremy Rubin"],"status":"Draft","type":"Specification","layer":"Consensus (soft fork)","created":"2026-03-05","license":"BSD-3-Clause","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"abstract":"This proposal defines a new tapscript opcode, OP_TWEAKADD , that takes an x-only public key and a 32-byte integer t on the stack and pushes the x-only public key corresponding to P + t*G , where P is the lifted point for the input x-coordinate and G is the secp256k1 generator. The operation mirrors the Taproot tweak used by BIP340 signers and enables simple, verifiable key modifications inside script without revealing private keys or relying on hash locks.","eli5":"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 without revealing private keys, supporting more flexible contracts.","categories":["taproot","consensus"],"filename":"bip-0449.md","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0449.md","format":"markdown","readingMinutes":14,"inbound":0,"revisions":1,"impact":0,"core":false,"references":[],"lastModified":"2026-05-23"},{"number":450,"title":"Formosa—Seed encoding by themed mnemonic stories","authors":["Yuri S Villas Boas","André Fidencio Gonçalves"],"status":"Draft","type":"Specification","layer":"Applications","created":"2026-05-15","license":"BSD-2-Clause","requires":[32,39],"replaces":[],"replacedBy":[],"discussion":["https://gnusha.org/pi/bitcoindev/jQqInjh7VTC5byefTzENidJjigvRqf5Y7UvbrWjKPJykvhdlLETeglGE3zoAiVAxUyAXU8uWHsHEjJ0MHqqPTy4prgaIhgMyIrD9c6ZUuE0=@pm.me/#t","https://gnusha.org/pi/bitcoindev/F4cs-RJRQYBXhjoS9fc_cUc93yLrkQS5DNQAeFRHrLEQ5bScCjKSnaqN-IcXb16fxqO053muqFCx8_GzzKN5XCGCIHD9Ir1_baI5voKYfOo=@pm.me/","https://www.toptal.com/cryptocurrency/formosa-crypto-wallet-management"],"abstract":"This BIP describes Formosa, an expansion of BIP-0039 for the generation of deterministic wallets. Where BIP-0039 maps each 11 bits of entropy to one word drawn from a single 2048-word list, Formosa maps each 33 bits of entropy to a short themed sentence built from several smaller, syntactically-typed wordlists. The sentences carry grammatical structure and semantic coherence, substantially improving memorability while retaining all cryptographic properties of the original scheme. The proposal is fully forward- and backward-compatible with BIP-0039: BIP-0039 is itself a Formosa theme, and seed derivation re-encodes any Formosa mnemonic through the BIP-0039 English wordlist before applying PBKDF2, so existing keys and addresses are preserved.","eli5":"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 with the standard BIP 39 seed phrases most wallets use.","categories":["wallets","addresses"],"filename":"bip-0450.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0450.mediawiki","format":"mediawiki","readingMinutes":16,"inbound":0,"revisions":2,"impact":4,"core":false,"references":[],"lastModified":"2026-08-27"},{"number":451,"title":"Dust UTXO Disposal Protocol","authors":["bubb1es","haris"],"status":"Draft","type":"Specification","layer":"Applications","created":"2026-04-28","license":"CC0-1.0","version":"0.1.0","requires":[],"replaces":[],"replacedBy":[],"discussion":["https://delvingbitcoin.org/t/disposing-of-dust-attack-utxos/2215","https://groups.google.com/g/bitcoindev/c/pr1z3_j8vTc"],"abstract":"This BIP specifies a standardized protocol for safely disposing of dust UTXOs by spending them to an OP_RETURN output with the entire value going to transaction fees. The protocol describes how wallet software should remove unwanted small-value UTXOs received in dust attacks without degrading user privacy. The specification includes transaction format requirements, signature conventions enabling third-party batching, and validation rules for compliant implementations.","eli5":"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, prevents these amounts from being used to link a user's addresses together.","categories":["wallets","consensus","signatures"],"filename":"bip-0451.md","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0451.md","format":"markdown","readingMinutes":12,"inbound":0,"revisions":1,"impact":0,"core":false,"references":[],"lastModified":"2026-05-06"},{"number":461,"title":"Deterministic ECDSA Signatures","authors":["Liam Gilligan"],"status":"Draft","type":"Specification","layer":"Applications","created":"2026-08-12","license":"CC0-1.0","requires":[],"replaces":[],"replacedBy":[],"discussion":["https://groups.google.com/g/bitcoindev/c/boEZRlqczvw"],"abstract":"This document specifies an ECDSA signing algorithm whose output is fully determined by the secret key and the message being signed. Its signatures are at most 70 bytes when DER encoded, rather than 72 for an arbitrary valid ECDSA signature.","eli5":"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 guarantees slightly shorter signatures, saving a little space and fees.","categories":["signatures"],"filename":"bip-0461.md","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0461.md","format":"markdown","readingMinutes":14,"inbound":0,"revisions":1,"impact":0,"core":false,"references":[],"lastModified":"2026-07-28"}]