--- title: "BIP-444 (Now BIP 110): Reduced Data Temporary Softfork Explained" url: "https://bip39-phrase.com/bip-444-reduced-data-temporary-softfork/" language: "en" published: "2026-01-20T00:00:00+00:00" updated: "2026-10-19T00:00:00+00:00" --- [ BIP Standards ](/topics/bip-standards/) Published January 20, 2026 Updated October 19, 2026 # BIP-444 (Now BIP 110): Reduced Data Temporary Softfork Explained ![BIP-444 (Now BIP 110): Reduced Data Temporary Softfork Explained](/images/blog/bip-110-reduced-data-temporary-softfork-hero.webp) BIP-444 is the name the Reduced Data Temporary Softfork was widely known by in late 2025: a [Bitcoin Improvement Proposal](/bitcoin-improvement-proposal/) to limit the data in new transactions at the consensus level for about one year. The BIP editors formally assigned it number 110, so the specification is now BIP 110\. Its activation attempt failed in August 2026, and the BIP is **Closed**. Behind it is a long-running dispute among Bitcoin users over whether the blockchain should carry only financial transactions or arbitrary data as well. ## BIP-444 at a Glance | Question | Answer | | ---------------- | ------------------------------------------------------------------------------- | | Official number | BIP 110, assigned on December 3, 2025; 444 was proposed but never assigned | | Author | Dathon Ohm, with the original draft credited to Luke Dashjr | | Type | Specification BIP for a consensus soft fork | | What it would do | Make seven kinds of data-carrying scripts and transactions invalid while active | | Duration | 52,416 blocks, about one year, then the rules expire | | Status | Closed since August 2026, after a chain split with stalled mining | ## Why Is It Called Both BIP-444 and BIP 110? Dathon Ohm opened the proposal as a [pull request to the BIPs repository](https://github.com/bitcoin/bips/pull/2017) on October 24, 2025 and announced it on the [bitcoin-dev mailing list](https://groups.google.com/g/bitcoindev/c/nOZim6FbuF8); the BIP credits Luke Dashjr (Luke-Jr) with the original draft. Within days it was being called “BIP-444”. BIP editor Jon Atack [explained on the pull request](https://github.com/bitcoin/bips/pull/2017#issuecomment-3453363167) that he had proposed 444 to the other editors and noted it internally, but did not consider the number formally assigned. Under [BIP 3](https://github.com/bitcoin/bips/blob/master/bip-0003.md), which sets the rules of the BIP process, only BIP editors assign numbers, and a number counts as assigned only once an editor announces it publicly in the pull request. That announcement came on December 3, 2025, with number 110, and the pull request was renamed “BIP 110: Reduced Data Temporary Softfork”. Coverage from before December, and many headlines since, still use the old name, but both refer to the same document: the repository has no BIP 444. ## Why Was BIP-444 Proposed? The announcement tied the timing to Bitcoin Core 30.0, which [made multiple OP\_RETURN outputs standard and raised the default datacarriersize to 100,000 bytes](https://bitcoinops.org/en/newsletters/2025/10/17/#bitcoin-core-30-0), a change to relay policy, the rules a node applies to the unconfirmed transactions in its [mempool](/bitcoin-mempool/), rather than to consensus. Core contributors saw it as fixing an incentive bug; critics read it as an endorsement of data embedding, as [Bitcoin Optech’s 2025 review](https://bitcoinops.org/en/newsletters/2025/12/19/#increasing-or-removing-bitcoin-core-s-op-return-policy-limit) summarizes. The BIP itself traces the problem to the “inscription” technique of [Bitcoin Ordinals](/bitcoin-ordinals/), first exploited in 2022, saying the data-embedding trend it started burdens node operators and pulls development away from Bitcoin as money. Its rules would apply for 52,416 blocks (about one year) after activation and then expire, because permanent rules this blunt would constrain future upgrades. ## What Would the Soft Fork Restrict? BIP 110 adds seven consensus rules that apply to blocks while it is active. The headline limits: new output scripts (scriptPubKeys) may be at most 34 bytes, except OP\_RETURN outputs, which may be up to 83 bytes, restoring in consensus the long-established 83-byte policy limit. Data pushes and script-argument witness items are capped at 256 bytes, and several upgrade hooks are switched off for the duration. Coins created before activation are exempt from all of the new rules (“UTXO grandfathering”), so existing coins cannot be frozen by the fork. The BIP does not claim to end data embedding: data can still be split into 256-byte pieces, which it argues raises the cost and signals that data storage is unsupported. ![BIP-444 (BIP 110) Reduced Data Temporary Softfork overview](/wp-content/uploads/2026/01/bip-444-bip-110-reduced-data-temporary-softfork-overview.jpg) ### The Seven Temporary Rules | # | Invalid while BIP 110 is active | Note from the BIP | | - | ------------------------------------------------------------ | ------------------------------------------------------------------- | | 1 | New output scriptPubKeys over 34 bytes | OP\_RETURN outputs may be up to 83 bytes | | 2 | Data pushes and script-argument witness items over 256 bytes | BIP16 redeemScripts, witness scripts and Tapleaf scripts are exempt | | 3 | Spending undefined witness or Tapleaf versions | Creating such outputs stays valid | | 4 | Witness stacks with a Taproot annex | The annex is reserved for future upgrades | | 5 | Taproot control blocks over 257 bytes | Spendable leaves are limited to depth 7, a 128-leaf tree | | 6 | Tapscripts containing OP\_SUCCESS opcodes, even unexecuted | These opcodes are reserved for future upgrades | | 7 | Tapscripts that execute OP\_IF or OP\_NOTIF | Often used to wrap data that is skipped at execution | ## What Did Supporters Argue? The BIP’s first argument is node cost. Except for OP\_RETURN outputs, unspent output scripts stay in the UTXO set, which nodes keep on fast media and cannot prune, and large scriptPubKeys can be abused to build “poison blocks” that are slow to validate. Since the scripts behind every [address type](/what-is-a-bitcoin-address/) in use today fit in 34 bytes, the cap is presented as protecting decentralization without limiting real payments. The second is the fee market. A data transaction’s fee goes to one miner, while every node operator keeps storing and serving the data. In the BIP’s view, data storage competes unfairly with payments, makes them more expensive and pushes users toward third-party processors that are easier to censor. The third is content. The BIP names images as likely the most harmful use of data storage, partly because they can include content “that a large majority of node operators might object to”. Early drafts and the author’s comments on the pull request framed this as a legal and moral risk for node operators. Relay policy, the BIP adds, cannot fully stop miners who include such data themselves. ### Supporters and Critics: Goals and Concerns | Group | Key Objective | Primary Concern | | ---------- | ------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ | | Supporters | Keep block space and node resources focused on payments | Data storage raises node costs and fees and can carry objectionable content | | Critics | Keep consensus rules narrow and avoid confiscation risk | Frozen funds in edge cases, a contentious expiry, chain-split risk and little effect on data embedding | ## What Did Critics Argue? A central criticism was confiscation risk, which Bitcoin Optech’s [summary of the early discussion](https://bitcoinops.org/en/newsletters/2025/11/07/#temporary-soft-fork-to-reduce-data) singled out. Grandfathering protects existing coins, but as [Murch pointed out](https://bitcoinops.org/en/newsletters/2026/06/26/#why-would-forbidding-op-if-in-tapscript-be-a-problem), nobody can tell which Taproot outputs rely on OP\_IF (miniscript-based degrading multisig wallets are one example), so users of such setups could unknowingly lock up funds received after activation. The BIP itself concedes that some pre-signed Taproot funds could in theory be frozen or lost, and that its 128-leaf limit could hinder contracts such as BitVM. Critics also doubted that the rules would work. Optech reported that Peter Todd encoded the text of the proposed BIP into a transaction valid under its rules. Answering a Bitcoin Stack Exchange question on why BIP 110’s decentralization benefit would not outweigh its cost to transaction neutrality, Pieter Wuille [argued](https://bitcoinops.org/en/newsletters/2026/07/31/#why-does-bip110-s-decentralization-benefit-not-outweigh-its-impact-on-transaction-neutrality) that the ban would not lower node costs: the block weight limit already caps resource use, data bytes are among the cheapest to process, and blocked patterns would simply be replaced by others. Others questioned the design. If the expiry became contested, Optech noted, letting the rules lapse would turn into a contentious hard fork. And Murch [walked through](https://bitcoinops.org/en/newsletters/2026/06/26/#does-a-softfork-always-succeed) what happens when a soft fork with mandatory signaling has only a minority of the [hash rate](/hash-rate/): the signaling chain falls behind on proof of work and stalls, a split of the kind our guide to the [longest chain rule](/longest-chain-in-blockchain-explained-security-consensus-forks/) describes. ## How Was It Supposed to Activate, and What Happened? BIP 110 uses a modified BIP9 deployment with a 55% signaling threshold instead of the usual 95%, no timeout and no FAILED state. If [miners](/how-bitcoin-mining-works/) did not lock it in voluntarily, enforcing nodes would reject non-signaling blocks for one retarget period, forcing lock-in on their chain. The reference implementation is a modified Bitcoin Knots branch; Bitcoin Core [does not enforce the rules](https://bitcoinops.org/en/newsletters/2026/06/26/#how-to-set-up-bitcoin-core-to-mine-a-valid-block-after-the-bip110-activation-in-august-2026). ### Deployment Parameters | Parameter | Value in BIP 110 | | --------------------------- | ------------------------------------------------------- | | Deployment name and signal | reduced\_data, version bit 4 | | Signaling start | About December 1, 2025 | | Early lock-in threshold | 1,109 of 2,016 blocks (55%) | | Mandatory signaling | Blocks 961,632–963,647 | | Latest lock-in / activation | Block 963,648 / block 965,664 (about September 1, 2026) | | Duration once active | 52,416 blocks (about one year), then the rules expire | The BIP was merged as a Draft in February 2026 and marked Complete in June. According to BIP editor Jon Atack’s [mailing-list post](https://groups.google.com/g/bitcoindev/c/b%5FaV3JUtUqg/m/HwFbYFJwCAAJ), the chain split on August 8, 2026, when mandatory signaling began: the BIP 110 chain started rejecting every block that did not signal bit 4, and block production on it stalled. The BIP’s changelog records the move to Closed “following a chain split with stalled mining”, and Optech [described the update](https://bitcoinops.org/en/newsletters/2026/08/14/#bips-2225) as following an unsuccessful activation attempt. At least one participant objected on the mailing list, arguing that BIP 110 had activated. Under [BIP 3](https://github.com/bitcoin/bips/blob/master/bip-0003.md), Closed marks a BIP as being of historical interest only, and the document stays in the repository. BIP 110 turned an old argument about Bitcoin’s purpose into concrete rules and a real activation attempt. The attempt failed, but the [BIP 110 specification](https://github.com/bitcoin/bips/blob/master/bip-0110.mediawiki), with its rationale, trade-offs and test vectors, remains a documented reference for future proposals on the same question. **Explore the BIP series:** [What are Bitcoin Improvement Proposals?](/bitcoin-improvement-proposal/) · [BIP-32: Hierarchical Deterministic Wallets](/bip-32/) · [BIP-39: The Seed Phrase Standard](/bip39-the-foundation-of-crypto-wallet-security/) · [BIP-44: Multi-Account Hierarchy](/bip-44-multi-account-hierarchy-for-deterministic-wallets/) · [BIP-157: Client-Side Block Filtering](/bip-157-client-side-block-filtering/) · [BIP39 vs BIP32 vs BIP44 compared](/crypto-seed-standards-bip39-vs-bip32-vs-bip44/) [ Back to Blog ](/blog/)