BIP 110, titled Reduced Data Temporary Softfork, is a closed proposal to temporarily tighten the rules nodes use to accept blocks. A node is a computer that independently checks the history and payments. The proposal aimed to make certain data storage harder and, in its supporters’ view, strengthen the network’s monetary role. That did not automatically make it a rule for all of Bitcoin.
Imagine two node operators receiving the same block. One accepts it under the existing rules; the other rejects it under a new restriction. BIP 110 reached that deep: it would change block validity, not just a node’s willingness to relay a transaction or keep it in its mempool, the local waiting area for unconfirmed payments. On 2026-10-23, specification version 1.0.1 carried the status Closed. A BIP number or a published program is no stamp of network adoption. The proposals registry preserves a document and its history; it does not remotely switch the rules of individual nodes. [1] [2]
Every new transaction output has a scriptPubKey, the script setting conditions for spending it later. The proposal allowed at most 34 bytes, or 83 bytes if it begins with OP_RETURN, an instruction making the output provably unspendable. The entire script counts. A separate 256-byte limit applied to individual OP_PUSHDATA* payloads and argument items in the witness, the accompanying information used to verify a spend. Pushing a redeemScript, the revealed spending-condition script, into a BIP16 scriptSig is an exception. Witness scripts and Tapleaf scripts themselves are not those arguments, although their data-pushing instructions remain restricted. These are limits on particular parts, not on the total length of a transaction or its entire witness. [1]
The proposal also reached into Taproot, a way of expressing spending conditions. It prohibited spending undefined witness or Tapleaf versions, but not creating such outputs. It would disallow the annex, an optional field, and control blocks above 257 bytes: excessively long proofs that a script belongs to the committed structure. Tapscript could not contain OP_SUCCESS* even in unexecuted code, nor execute OP_IF or OP_NOTIF regardless of the condition’s result. For technical comparison, the defined formats include P2WPKH, P2WSH, P2TR with Tapleaf version 0xc0, and P2A with program 0x4e73, the last only with an empty witness stack. These are precise format names, not fields ordinary users must enter into a wallet. [1]
A UTXO is an unspent output: a particular amount with conditions governing its use. The proposal exempts inputs spending UTXOs confirmed before activation. That does not give the same transaction’s new outputs a free pass. Signing a transaction in advance does not protect an output that is only created during the active period. For certain presigned Taproot constructions, the specification acknowledges possible frozen or lost funds if restrictions invalidate the intended paths and no usable alternative remains. This also raises questions for Miniscript, a tool for constructing spending conditions, and BitVM, constructions for verifying computations. It is therefore unsafe to promise that only nonmonetary content would be affected. [1] [3]
A miner can put a support signal in a block: here, bit 4, with a threshold of 1109 out of 2016 blocks, roughly 55 percent. But the proposal went beyond voluntary signaling. If the threshold was not reached earlier, it required signaling at heights 961632–963647, followed by LOCKED_IN from 963648 and ACTIVE from 965664, provided that chain reached those heights. Height is a block’s position in the chain. LOCKED_IN means the transition is committed; ACTIVE means the data restrictions are enforced. The client would already reject nonsignaling blocks during mandatory signaling, so nodes could part ways before the data limits started. Those limits were to last 52416 blocks after actual activation, then become EXPIRED and stop being enforced—not run for an exact calendar year. [1] [4]
Supporters wanted lower node operating costs, less pressure on the UTXO set, less unwanted content and a stronger focus on payments. These explain the motivation; they do not establish the outcome. Critics raised effects on useful scripts, future upgrades and the risk of splitting the network. Data can also be divided into smaller pieces: in the initial discussion, Peter Todd demonstrated a transaction carrying the entire then-current proposal that way. Even the specification does not promise to eliminate steganography, the hiding of information inside other data. Making storage more expensive and preventing it altogether are different results. Likewise, concern about legal liability for content does not by itself establish a particular legal duty. [1] [3]
The PR 2247 record describes a split on 2026-08-08 at height 961632. The main chain contained a block without the required signal, while OCEAN mined a signaling alternative. On 2026-08-09, Murch reported that the minority branch had gained just 2 blocks and stalled, while the main chain had advanced by more than 100 blocks. Such a report needs its date and author: it is neither an independent replay performed for this article nor a statement of the minority branch’s present condition. It also shows why a signaling-driven split must not be confused with reaching ACTIVE and turning on the data restrictions themselves. [5] [6]
The document passed through Complete, meaning a completed specification, and ended as Closed. PR 2245 closing it was merged on 2026-08-10; the specification’s changelog gives 2026-08-09. The dates describe different records, not another activation. Client release v0.4.1 documents EXPIRED and vbrequired, the block-template field indicating a mandatory signaling bit. That client’s existence is not adoption in Bitcoin Core. There are also test vectors, sample transactions with expected outcomes, and functional tests. This article does not run them or verify the current minority chain. Its purpose is to explain the proposal and its documented history, rather than present a historical document as the network’s current shared rules. [7] [1] [4]
One more byte can change the result
Imagine checking a new output under the hypothetical active rules. An ordinary scriptPubKey of 34 bytes passes this length test; at 35 bytes it fails. A script beginning with OP_RETURN may contain 83 bytes; 84 bytes exceeds the limit. We always measure the whole output script, not just the embedded text. Passing this test still does not establish the validity of the whole transaction, and spending an old UTXO does not exempt a new output.
For the clearest picture, read this entry together with Soft Fork, Full Node, Taproot, Bitcoin Script, Transaction Fees, UTXO. The reverse links also lead from OP_RETURN.
01Does Closed mean nobody may run the client anymore?+
Closed is a document status, not a ban on using software. Nodes follow their software’s rules. Someone choosing different rules may nevertheless end up on another chain branch; closing a registry entry does not remove that difference.
02Were data restrictions already enforced during mandatory signaling?+
No. Mandatory signaling precedes LOCKED_IN and ACTIVE. A client can reject a block lacking the required signal before the data rules begin. A calendar date alone is therefore insufficient: validity depends on the state and height of the particular chain.