Home › Topics › Consensus

Consensus

Changes to consensus rules. 55 proposals.

  • 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 50: March 2013 Chain Fork Post-Mortem: Deployed. 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…
  • 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 74: Allow zero value OP_RETURN in Payment Protocol: Closed. Adjusts the BIP 70 Payment Protocol so a merchant's payment request can include an OP_RETURN output carrying zero bitcoin, a way of attaching a small piece of data to a transaction. This lets…
  • BIP 90: Buried Deployments: Deployed. 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…
  • 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 94: Testnet 4: Deployed. 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…
  • 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 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 101: Increase maximum block size: Closed. Proposed replacing the fixed 1 MB block size limit with a limit that grows automatically on a predictable schedule over time. Supporters argued it would let Bitcoin handle more transactions as…
  • BIP 103: Block size following technological growth: Closed. Proposed gradually increasing the block size limit at a rate meant to track improvements in hardware and internet bandwidth. The goal was to allow more transactions while keeping it practical for…
  • BIP 105: Consensus based block size retargeting algorithm: Closed. Proposed a mechanism for changing the maximum block size based on votes or consensus among network participants rather than a fixed number. It aimed to let the limit adapt over time without repeated…
  • BIP 109: Two million byte size limit with sigop and sighash limits: Closed. Proposed doubling the block size limit from 1 MB to 2 MB, alongside new caps on signature checks and data hashing to stop specially crafted blocks from overloading nodes. It was associated with the…
  • BIP 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 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 134: Flexible Transactions: Closed. Proposes a new, tag-based transaction format that would make Bitcoin transactions easier to extend with new fields later. It would also fix transaction malleability (the ability to alter a…
  • BIP 135: Generalized version bits voting: Closed. Extends the version-bits system miners use to signal readiness for upgrades, letting each signal have its own approval threshold, counting window, and waiting period. The aim was to give the network…
  • BIP 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 144: Segregated Witness (Peer Services): Deployed. 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…
  • BIP 145: getblocktemplate Updates for Segregated Witness: Deployed. 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…
  • 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 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 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 324: Version 2 P2P Encrypted Transport Protocol: Deployed. 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…
  • 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 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 338: Disable transaction relay message: Closed. Adds a message letting a node tell a peer that their connection will not be used for transaction relay, only for blocks. This supports block-relay-only connections, which help protect nodes against…
  • BIP 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 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…
  • 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…