Home › Browse › Draft BIPs

Draft BIPs

A Draft BIP is a work in progress: the author is still writing it and gathering feedback, so details can change. Every BIP starts here once the editors assign it a number.

Drafts are where the current debates live, such as covenant proposals and post-quantum outputs. Being a Draft is not an endorsement: anyone can write a BIP. Learn how the process works.

56 proposals.

  • BIP 461: Deterministic ECDSA Signatures: Draft. Specifies a way of producing ECDSA signatures, Bitcoin's original signature type, where the result depends only on the private key and the message, removing reliance on a good random number source.…
  • BIP 451: Dust UTXO Disposal Protocol: Draft. Specifies a standard way for wallets to get rid of 'dust', tiny unwanted amounts often sent to track users, by spending them entirely as miner fees. Doing so carefully, without mixing the dust with…
  • BIP 450: Formosa—Seed encoding by themed mnemonic stories: Draft. Formosa is an alternative way of writing a wallet's backup phrase as short themed sentences instead of a list of unrelated words. The sentences are designed to be easier to remember while remaining…
  • BIP 449: OP_TWEAKADD - x-only key tweak addition: Draft. Proposes OP_TWEAKADD, a script instruction that adjusts a public key by adding a given number to it, mirroring the 'tweak' technique Taproot already uses. It would let scripts verifiably derive new…
  • BIP 448: Taproot-native (Re)bindable Transactions: Draft. Bundles three small script instructions, OP_TEMPLATEHASH, OP_CHECKSIGFROMSTACK and OP_INTERNALKEY, into a single proposed upgrade. Together they would let transactions commit to specific future…
  • BIP 446: OP_TEMPLATEHASH: Draft. Proposes OP_TEMPLATEHASH, a Taproot script instruction that produces a fingerprint of the transaction spending a coin. Scripts can use it to require that coins be spent only in a specific pre-agreed…
  • BIP 443: OP_CHECKCONTRACTVERIFY: Draft. Proposes OP_CHECKCONTRACTVERIFY, an instruction that lets coins carry embedded data and restrict where they can be sent next and with what data. This lets users build multi-step contracts, such as…
  • BIP 442: OP_PAIRCOMMIT: Draft. Proposes OP_PAIRCOMMIT, a script instruction that combines two pieces of data into a single secure fingerprint (hash). This compact way of committing to data could make certain smart contracts and…
  • BIP 441: Restoration of disabled script (Tapleaf 0xC2): Draft. Proposes a new Taproot script version that restores many of Bitcoin's original script instructions disabled in 2010 and greatly loosens limits on data size. To avoid the denial-of-service risks that…
  • BIP 440: Varops Budget For Script Runtime Constraint: Draft. Proposes a 'varops budget' that caps how much computational work a script may do, based on the size of the transaction, extending the existing limit on signature checks to all operations. It is…
  • BIP 433: Pay to Anchor (P2A): Draft. Defines Pay to Anchor, a tiny standard output that anyone can spend without a signature. Its purpose is to act as a hook for fee-bumping: by spending it in a follow-up transaction, any party can add…
  • BIP 431 (TRUC transactions): Topology Restrictions for Pinning: Draft. Explains 'pinning', a problem where someone can block a transaction from being replaced with a higher-fee version, which can endanger time-sensitive protocols like Lightning. It describes stricter…
  • BIP 393: Output Script Descriptor Annotations: Draft. Introduces optional tags that can be attached to a descriptor, such as the block height to start scanning from or how many unused addresses to check. These hints speed up and simplify wallet…
  • BIP 392: Silent Payment Output Script Descriptors: Draft. Defines an 'sp()' descriptor for Silent Payment wallets, describing the keys needed to detect and spend payments sent to a reusable Silent Payment address. This lets such wallets be backed up and…
  • BIP 390 (MuSig2 descriptors): musig() Descriptor Key Expression: Draft. Adds a 'musig()' expression to descriptors, which combines several people's public keys into a single shared key using the MuSig2 method. The resulting coins look like an ordinary single-key payment…
  • BIP 389: Multipath Descriptor Key Expressions: Draft. Extends descriptors so one key expression can represent several related derivation paths at once, such as a wallet's receiving and change addresses. This shortens wallet backups and avoids having to…
  • BIP 379: Miniscript: Draft. Miniscript is a structured way of writing Bitcoin scripts, the small programs that define how coins can be spent. It lets software analyze spending conditions, combine them safely, and sign for them…
  • BIP 376: Spending Silent Payment outputs with PSBTs: Draft. Adds fields to version 2 Partially Signed Bitcoin Transactions (PSBTs) for spending coins received via Silent Payments. Those coins require a special adjustment to the recipient's key when signing,…
  • BIP 375: Sending Silent Payments with PSBTs: Draft. Adds fields and rules to the version 2 Partially Signed Bitcoin Transaction (PSBT) format so wallets can send to Silent Payment addresses. Since a Silent Payment's final address depends on the…
  • BIP 374: Discrete Log Equality Proofs: Draft. Standardizes a short cryptographic proof that someone used the same secret key in two related calculations, without revealing the key itself. This is useful, for example, to prove that a shared…
  • BIP 372: Pay-to-contract tweak fields for PSBT: Draft. Adds fields to the Partially Signed Bitcoin Transaction (PSBT) format for 'pay-to-contract' data, extra information used when a key has been mathematically adjusted to commit to some contract or…
  • BIP 361: Post Quantum Migration and Legacy Signature Sunset: Draft. Outlines a phased plan, once a quantum-resistant address type exists, to retire today's signature types. First, sending coins to quantum-vulnerable addresses would be blocked; later, after a…
  • BIP 360: Pay-to-Merkle-Root (P2MR): Draft. Proposes a new output type, Pay-to-Merkle-Root, that works like Taproot but removes the option to spend directly with a single public key. Since only hashes are exposed until spending, coins in…
  • BIP 349: OP_INTERNALKEY: Draft. Adds a small script instruction that places a Taproot output's 'internal key', the main key behind the output, onto the script's working data. It saves space by avoiding repeating that key inside…
  • BIP 348 (OP_CHECKSIGFROMSTACK): CHECKSIGFROMSTACK: Draft. Adds an instruction letting Bitcoin scripts verify a signature over any piece of data, not just over the spending transaction itself. That opens the door to things like delegating spending rights,…
  • BIP 346: OP_TXHASH: Draft. Proposes a new script instruction, OP_TXHASH, that lets a script look at selected details of the transaction trying to spend it, such as its outputs or amounts. Combined with a way to check…
  • BIP 337: Compressed Transactions: Draft. Proposes a compression scheme that can shrink Bitcoin transactions to less than half their usual size. This is useful when bandwidth is very limited, such as broadcasting transactions over satellite…
  • BIP 332: Stale Tip Relay: Draft. Defines an optional message for nodes to tell peers about recent stale blocks, valid blocks that did not end up in the main chain. Sharing them helps researchers and operators monitor mining…
  • BIP 331: Ancestor Package Relay: Draft. Lets nodes request and share an unconfirmed transaction together with the parent transactions it depends on, as a single package. This helps low-fee parents get relayed when a child pays extra fees…
  • BIP 330 (Erlay): Transaction announcements reconciliation: Draft. Specifies a method for two nodes to efficiently work out which transactions the other is missing, instead of announcing each one individually. It is a building block for Erlay, which would let nodes…
  • BIP 329: Wallet Labels Export Format: Draft. Defines a common file format for exporting wallet labels, the personal notes users attach to addresses and transactions. It lets users move these notes between wallets, preserving records that help…
  • BIP 326: Anti-fee-sniping in taproot transactions: Draft. Recommends that Taproot wallets sometimes use a transaction's sequence field, instead of its lock-time field, for their anti-fee-sniping protection (a measure discouraging miners from rewriting…
  • BIP 323: 24 nVersion bits for general purpose use: Draft. Reserves 24 bits of the block header's version field as extra space miners can vary while searching for a valid block. This lets fast mining hardware keep working on just the block header without…
  • BIP 320: nVersion bits for general purpose use: Draft. Reserves 16 bits of the block header's version field for miners to use freely, removing their meaning for upgrade signaling. This formalizes a practice that helps mining hardware search for valid…
  • BIP 310: Stratum protocol extensions: Draft. Defines a general way to add extensions to Stratum, the protocol mining pools use to send work to miners. Its main extension allows "version rolling," letting mining hardware vary certain…
  • BIP 301: Blind Merged Mining (Consensus layer): Draft. Blind Merged Mining would let Bitcoin miners earn fees from sidechains without running any sidechain software. Sidechain users assemble blocks and bid for a miner to include a commitment to them,…
  • BIP 300 (Drivechain): Hashrate Escrows (Consensus layer): Draft. Proposes "hashrate escrows," which would let bitcoin move to and from sidechains with withdrawals approved gradually by miners over months rather than by a trusted federation. The goal is to allow…
  • BIP 197: Hashed Time-Locked Collateral Contract: Draft. Describes a script for collateral-backed loans built on hashed time-locked contracts, based on the Atomic Loans design. It lets a borrower lock bitcoin as collateral for a loan with rules enforced…
  • BIP 178: Version Extended WIF: Draft. Extends Wallet Import Format (WIF), the common text format for a single private key, to also record which address type the key belongs to. This helps wallets import a key and correctly find its…
  • BIP 177: Redefine Bitcoin's Base Unit: Draft. Proposes redefining "one bitcoin" as the smallest indivisible unit, currently called a satoshi, so amounts are shown as whole numbers instead of with eight decimal places. Supporters argue this…
  • BIP 172: Define Bitcoin Subunits as Satoshis: Draft. Formally defines a "satoshi" as the smallest unit of bitcoin, one hundred-millionth of a coin, with "sats" as the standard short form. Agreeing on the name helps wallets, exchanges, and…
  • BIP 138: Compact Encryption Scheme for Non-seed Wallet Data: Draft. Specifies a compact way to encrypt wallet backup details, such as descriptors (a recipe describing which addresses a wallet uses), without including any private keys. Anyone holding one of the…
  • BIP 136: Bech32 Encoded Tx Position References: Draft. Defines "TxRef," a short, human-friendly code that points to a confirmed transaction by its location in the blockchain (block and position) rather than by its long ID. It uses the same…
  • BIP 128: Timelock-Recovery Storage Format: Draft. Proposes a standard file format for 'timelock recovery plans', pre-signed transactions that move funds to a backup location after a delay unless cancelled. Shared formats let one wallet create a…
  • BIP 126: Best Practices for Heterogeneous Input Script Transactions: Draft. Recommends best practices for transactions that combine coins from different addresses, which can unintentionally reveal that those addresses belong to the same person. Following these guidelines…
  • BIP 122: URI scheme for Blockchain references / exploration: Draft. Proposes a standard link format for referring to blocks, transactions and addresses, which software can open in any blockchain explorer the user chooses. It also lets the link specify which…
  • BIP 119 (OP_CHECKTEMPLATEVERIFY): CHECKTEMPLATEVERIFY: Draft. Proposes CHECKTEMPLATEVERIFY, a script instruction that restricts coins so they can only be spent in a transaction matching a predetermined template. This 'covenant' could enable vaults that protect…
  • BIP 118: SIGHASH_ANYPREVOUT for Taproot Scripts: Draft. Proposes SIGHASH_ANYPREVOUT, a signature type for Taproot scripts that does not commit to the exact coin being spent, so one signed transaction can be attached to any compatible coin. This would…
  • BIP 117: Tail Call Execution Semantics: Draft. Proposed letting a script hand off execution to another script supplied at spending time, a 'tail call'. Combined with BIP 116, this would allow contracts with many possible spending conditions…
  • BIP 116: MERKLEBRANCHVERIFY: Draft. Proposed MERKLEBRANCHVERIFY, a script instruction that checks whether a piece of data belongs to a committed set using a Merkle proof. It would let complex contracts reveal only the spending…
  • BIP 98: Fast Merkle Trees: Draft. Specifies a faster and safer version of the Merkle tree, the data structure Bitcoin uses to summarize many items in one fingerprint so that any single item can be proven to be included. The design…
  • BIP 95: Testnet 5: Draft. Proposes Testnet 5 to replace Testnet 4, removing a special rule that let blocks be mined at minimum difficulty, which had been heavily abused. It also raises the minimum difficulty and applies the…
  • BIP 93: codex32: Checksummed SSSS-aware BIP32 seeds: Draft. Introduces codex32, a format for backing up a wallet seed that includes a strong error-detecting checksum and can be checked or created by hand with paper tools. It optionally supports splitting the…
  • BIP 77: Async Payjoin: Draft. Introduces a second version of Payjoin that works asynchronously, so sender and receiver do not need to be online at the same moment. An untrusted relay called a directory server passes encrypted…
  • BIP 53: Disallow 64-byte transactions: Draft. Proposes making transactions that are exactly 64 bytes long (excluding signature data) invalid. Such transactions can be confused with internal pieces of a block's Merkle tree, the structure…
  • BIP 46: Address Scheme for Timelocked Fidelity Bonds: Draft. Defines how HD wallets create time-locked addresses for "fidelity bonds," where coins are locked for a period to prove a costly commitment. Such bonds can help resist fake identities in systems like…

Other statuses: Deployed BIPs · Complete BIPs · Closed BIPs