Home › Browse › Consensus (soft fork)
Consensus (soft fork)
- BIP 12: OP_EVAL: Closed. Proposed a new script command, OP_EVAL, that would let the receiver of coins define the conditions for spending them instead of the sender. It was abandoned over security concerns and replaced by…
- BIP 16: Pay to Script Hash: Deployed. Introduced Pay to Script Hash (P2SH), letting a sender pay to a short fingerprint of spending rules that the recipient reveals only when spending. This shifted the cost and complexity of setups like…
- BIP 17: OP_CHECKHASHVERIFY (CHV): Closed. A competing proposal to P2SH that would have added a script command, OP_CHECKHASHVERIFY, letting recipients set their own spending conditions. The community chose BIP 16 instead, and this approach…
- BIP 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 30: Duplicate transactions: Deployed. Added a rule forbidding a block from including a transaction with the same ID as an earlier one whose outputs are not fully spent. Such duplicates can overwrite earlier coins and make them…
- BIP 34: Block v2, Height in Coinbase: Deployed. Upgraded blocks to version 2 and required each block's coinbase transaction (the one paying the miner) to include the block's height. This makes every coinbase unique, preventing duplicate…
- BIP 42: A finite monetary supply for Bitcoin: Deployed. A tongue-in-cheek proposal fixing a software quirk that would have made the block reward reappear and coin issuance restart a couple of centuries from now. It ensures the roughly 21 million coin…
- 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 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 62: Dealing with malleability: Closed. Proposed a set of rules to stop third parties from altering a transaction's ID without changing what it does, a problem called malleability. It was withdrawn after Segregated Witness (SegWit) solved…
- BIP 65: OP_CHECKLOCKTIMEVERIFY: Deployed. Adds OP_CHECKLOCKTIMEVERIFY, a script command that keeps coins unspendable until a chosen date or block height. It enables time-locked savings, escrow with deadlines, and payment channels such as…
- BIP 66: Strict DER signatures: Deployed. Required all signatures to follow one strict encoding format, known as DER. Different software interpreted loosely encoded signatures differently, which risked splitting the network and let…
- BIP 68: Relative lock-time using consensus-enforced sequence numbers: Deployed. Gives transactions a "relative lock-time," so a coin cannot be spent until a set number of blocks or amount of time has passed since it was confirmed. This is an essential building block for payment…
- BIP 91: Reduced threshold Segwit MASF: Deployed. Proposed a way to activate SegWit with support from a simple majority of mining power instead of the 95 percent originally required. Participating miners would reject blocks that did not signal for…
- 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 110: Reduced Data Temporary Softfork: Closed. Proposes a temporary soft fork that would limit the size of arbitrary data fields allowed in transactions under Bitcoin's core rules. Supporters argue this would discourage using block space for…
- BIP 112: CHECKSEQUENCEVERIFY: Deployed. Introduces CHECKSEQUENCEVERIFY, a script instruction that lets coins be locked until a certain amount of time has passed since they were received. This 'relative timelock' is a key building block…
- BIP 113: Median time-past as endpoint for lock-time calculations: Deployed. Changes how Bitcoin measures time for timelocked transactions, using the median time of the previous 11 blocks instead of a single block's timestamp. Because this value only moves forward, miners…
- BIP 114: Merkelized Abstract Syntax Tree: Closed. Proposed MAST, which organizes a script's possible spending conditions into a tree so that only the condition actually used needs to be revealed. This saves space and improves privacy by hiding…
- BIP 115: Generic anti-replay protection using Script: Closed. Proposed a new script instruction that makes a transaction valid only on a blockchain containing a specific block. This would protect users during chain splits by preventing a transaction on one…
- BIP 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 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 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 119: 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 140: Normalized TXID: Closed. Proposes a "normalized" transaction ID calculated without the signature data, so the ID cannot be changed by tampering with signatures. This would eliminate transaction malleability, which…
- BIP 141: Segregated Witness (Consensus layer): Deployed. Defines Segregated Witness (SegWit), which moves signatures into a separate "witness" section of each transaction while remaining compatible with older nodes. This fixed transaction malleability,…
- BIP 143: Transaction Signature Verification for Version 0 Witness Program: Deployed. Changes how signatures are calculated for SegWit transactions so that verifying them no longer requires re-hashing the same data many times. It also makes the signature commit to the amount being…
- BIP 146: Dealing with signature encoding malleability: Closed. Tightens the rules on how digital signatures may be formatted, so a third party cannot slightly alter a signature's encoding and thereby change a transaction's ID. Removing this form of malleability…
- BIP 147: Dealing with dummy stack element malleability: Deployed. Fixes a quirk in Bitcoin's multisignature opcode, which consumes an extra unused value that anyone could modify without invalidating the transaction. Requiring that value to be empty removes one…
- BIP 148: Mandatory activation of segwit deployment: Deployed. Proposed a user-activated soft fork (UASF), where nodes would reject blocks that did not signal support for SegWit after a set date. It was a way for users, rather than miners alone, to push SegWit…
- BIP 149: Segregated Witness (second deployment): Closed. Proposed a second attempt at activating SegWit using version-bits signaling with guaranteed lock-in after a deadline. It was offered as an alternative path in case the original SegWit deployment…
- BIP 300: 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 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 341: Taproot: SegWit version 1 spending rules: Deployed. Taproot introduces a new kind of Bitcoin output that can be spent either with a single signature or by revealing just one of many possible alternative spending conditions, kept hidden in a tree…
- BIP 342: Validation of Taproot Scripts: Deployed. Specifies Tapscript, the updated scripting rules used when a Taproot output is spent through one of its hidden alternative conditions. It switches signature checks to Schnorr, removes some old…
- BIP 343: Mandatory activation of taproot deployment: Closed. Describes an alternative way to switch on Taproot in which nodes would have begun enforcing the new rules at a fixed deadline even if miners had not signaled readiness (known as 'lock-in on…
- BIP 345: OP_VAULT: Closed. Proposes two new script instructions that let users lock coins in a 'vault': any withdrawal must first wait out a delay, during which the owner can redirect the coins to a pre-chosen safe recovery…
- BIP 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 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 348: 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 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 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 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 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 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 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 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 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 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 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…