Home › Browse › Complete BIPs

Complete BIPs

A BIP is Complete when its author considers the specification finished: ready for review, implementation and adoption, but not yet in use. Under BIP 3 this status replaced the older label Proposed.

For a consensus change, Complete says nothing about whether it will activate: that depends on implementations and on the network choosing to run them. See how soft forks are activated.

22 proposals.

  • BIP 434: Peer Feature Negotiation: Complete. Defines a peer-to-peer message that nodes can exchange while first connecting, to announce and agree on support for new network features. This gives a cleaner, uniform way to roll out future…
  • BIP 388: Wallet Policies for Descriptor Wallets: Complete. Wallet policies are a compact, human-reviewable way of describing an 'account' in a wallet, built on top of output descriptors. They are designed especially for hardware wallets with small screens,…
  • BIP 373: MuSig2 PSBT Fields: Complete. Extends the Partially Signed Bitcoin Transaction (PSBT) format so it can carry the data needed for MuSig2, a method where several people jointly produce one ordinary-looking signature. This makes it…
  • BIP 353: DNS Payment Instructions: Complete. Defines how to store Bitcoin payment instructions in DNS, the internet's naming system, so a person can be paid via a human-readable name such as an email-like address. Security extensions to DNS…
  • BIP 352: Silent Payments: Complete. Silent Payments let someone publish one static address that anyone can pay, while each payment lands at a different, unlinkable address on the blockchain. Unlike similar schemes, it needs no extra…
  • BIP 347: OP_CAT in Tapscript: Complete. Brings back OP_CAT, an instruction that joins two pieces of data together, which was disabled in Bitcoin's early days over security concerns. Re-enabled only inside Taproot scripts, this simple…
  • BIP 328: Derivation Scheme for MuSig2 Aggregate Keys: Complete. Explains how to turn a MuSig2 combined public key into a standard extended public key, so wallets can generate many fresh addresses from it. This lets groups using MuSig2 multisig manage addresses…
  • BIP 325: Signet: Complete. Defines Signet, a type of Bitcoin test network where new blocks must be signed by designated parties in addition to being mined. This gives developers a stable, predictable place to test software,…
  • BIP 322: Generic Signed Message Format: Complete. Defines a standard way to sign messages with any type of Bitcoin address, including SegWit and Taproot, not just older legacy addresses. This lets people prove they control an address or its funds…
  • BIP 321: URI Scheme: Complete. Defines the "bitcoin:" link format that wallets use for payment requests in QR codes and clickable links. It specifies how to include an amount, label, message, and alternative payment methods, so…
  • BIP 179: Name for payment recipient identifiers: Complete. Suggests replacing the word "address" with "invoice" or "invoice address." Because Bitcoin addresses are meant to be used only once, the authors argue the new term better discourages address reuse,…
  • BIP 176: Bits Denomination: Complete. Proposes "bits" as the standard name for one millionth of a bitcoin (100 satoshis). The goal is to make everyday amounts easier to express without long strings of decimal places.
  • BIP 129: Bitcoin Secure Multisig Setup (BSMS): Complete. Defines a step-by-step procedure for securely setting up a multisignature wallet, where several devices or people must approve spending. It helps participants verify each other's keys and confirm…
  • BIP 127: Simple Proof-of-Reserves Transactions: Complete. Standardizes a way to construct proof-of-reserves transactions, which demonstrate that someone controls a certain amount of bitcoin without actually moving it. This helps custodians such as…
  • BIP 88: Hierarchical Deterministic Path Templates: Complete. Defines a compact text format for describing which key paths a wallet is allowed to use, for example 'any account number from 0 to 9'. Hardware wallets and software can use these templates to…
  • BIP 87: Hierarchy for Deterministic Multisig Wallets: Complete. Establishes a common key structure for multisignature wallets, where spending requires approval from several keys. Unlike earlier schemes, a single layout covers all script types, which makes it…
  • BIP 69: Lexicographical Indexing of Transaction Inputs and Outputs: Complete. Proposes sorting transaction inputs and outputs in a standard, alphabetical-style order. Because wallets ordered them differently, observers could tell which wallet created a transaction; a shared…
  • BIP 67: Deterministic Pay-to-script-hash multi-signature addresses through public key sorting: Complete. Specifies sorting the public keys in a multisig setup into a fixed order, so the same keys always produce the same P2SH address. Co-signers can then independently compute matching addresses without…
  • BIP 54: Consensus Cleanup: Complete. Bundles fixes for several long-standing protocol weaknesses: the timewarp attack (manipulating block timestamps to speed up coin issuance), blocks that take extremely long to validate, Merkle tree…
  • BIP 45: Structure for Deterministic P2SH Multisignature Wallets: Complete. Defines a key structure for HD wallets shared among several co-signers using P2SH multisig. It lets each participant independently generate the same series of shared addresses without exchanging new…
  • BIP 18: hashScriptCheck: Complete. Another alternative to P2SH that would have restructured how transactions present their locking and unlocking scripts, committing to a hash of the spending script. It aimed to support complex…
  • BIP 8: Version bits with lock-in by height: Complete. An alternative way to activate soft forks (backward-compatible rule upgrades) that measures time in block counts rather than clock timestamps. It also adds an option to guarantee activation at the…

Other statuses: Deployed BIPs · Draft BIPs · Closed BIPs