Reduced Data Temporary Softfork

  BIP: 110
  Layer: Consensus (soft fork)
  Title: Reduced Data Temporary Softfork
  Authors: Dathon Ohm 
  Status: Draft
  Type: Specification
  Assigned: 2025-12-03
  License: BSD-3-Clause
  Discussion: https://groups.google.com/g/bitcoindev/c/nOZim6FbuF8

Abstract

Temporarily limit the size of data fields at the consensus level, in order to correct distorted incentives caused by standardizing support for arbitrary data, and to refocus priorities on improving Bitcoin as money.

Copyright

This document is licensed under the 3-clause BSD license.

Specification

Blocks during a temporary, one-year deployment are checked with these additional rules:

# New output scriptPubKeys exceeding 34 bytes are invalid, unless the first opcode is OP_RETURN, in which case up to 83 bytes are valid. # OP_PUSHDATA* payloads and script argument witness items exceeding 256 bytes are invalid, except for the redeemScript push in BIP16 scriptSigs. # Spending undefined witness (or Tapleaf) versions (ie, not Witness v0/BIP 141, Taproot/BIP 341, or P2A) is invalid. (Creating outputs with undefined witness versions is still valid.) # Witness stacks with a Taproot annex are invalid. # Taproot control blocks larger than 257 bytes (a merkle tree with 128 script leaves) are invalid. # Tapscripts including OP_SUCCESS* opcodes anywhere (even unexecuted) are invalid. # Tapscripts executing the OP_IF or OP_NOTIF instruction (regardless of result) are invalid.

Inputs spending UTXOs that were created before the activation height are exempt from the new rules. Once the softfork expires, UTXOs of all heights are once again unrestricted.

GetBlockTemplate

This deployment uses the GBT deployment name "reduced_data" as defined in BIP 9. During mandatory signaling, the deployment's bit is included in "vbrequired".

Motivation

In order to protect Bitcoin's intended function as the Internet's native money, the Bitcoin community has historically treated techniques for embedding arbitrary data into Bitcoin transactions with antagonism.

Such data embedding must be resisted at all times in order to ensure it doesn't become load-bearing and start to produce negative externalities, especially for node operators.

Starting with the "inscription" hack first exploited in 2022, a trend has emerged around embedding arbitrary data into Bitcoin transactions, creating significant unnecessary burdens on node operators and diverting development focus and incentives away from Bitcoin's fundamental purpose of being sound, permissionless, borderless money.

This BIP aims to set Bitcoin back on the path to becoming the world's money by rejecting the standardization of data storage as a supported use case at the consensus level.

It achieves this by temporarily invalidating several of the most harmful methods of data abuse by consensus, while preserving all known monetary use cases.

Specifically, this proposal invalidates all methods of embedding contiguous arbitrary data larger than 256 bytes; it also invalidates large scriptPubKey and Tapleaf formats that are abused almost exclusively for data embedding; and finally, it restores, in consensus, the long-established 83-byte policy limit on OP_RETURN outputs.

In software development, it is a common practice to disable unsupported use cases, because not doing so quickly becomes unsustainable and causes development to grind to a standstill.

Activation of these new rules thus sends a clear message that arbitrary data storage will continue to be actively resisted, and that such unsupported usage should not be permitted to derail network priorities.

It also reinforces Bitcoin's core function as a censorship-resistant payment system, because data storage competes unfairly with payments, making Bitcoin payments unnecessarily costly. This encourages reliance on third-party payment processors, making Bitcoin payments easier to censor.

Finally, it improves decentralization of the node network by re-establishing the long-held commitment towards minimizing the cost (financial or otherwise) of operating a node.

Bitcoin should "do one thing, and do it well". By rejecting data storage, this BIP liberates Bitcoin developers from endless scope creep, enabling them to focus on what's really important: Bitcoin's success as money.

Rationale

Specification nuance

Why limit scriptPubKeys to 34 bytes?

Unspent scriptPubKeys (OP_RETURN excepted) must be stored indefinitely in the UTXO set, which nodes must store on fast media and cannot prune. Fast storage (usually RAM) is much more costly per byte than slower, non-volatile storage, so as the UTXO set size increases, the burden on node operators increases, harming decentralization. They are also a direct cost to the sender rather than the receiver. For these reasons, modern usage is all 34 bytes or smaller in practice; actual spending conditions have been moved to the witness, and the scriptPubKey simply commits to them in advance with a hash. Furthermore, large scriptPubKeys, in addition to being a data embedding vector, can be abused to create malicious transactions and blocks ("poison blocks") that take a long time to validate. Large scriptPubKeys, thus carrying a large abuse potential and no benefit, are invalidated by this BIP.

What about OP_RETURN? Why not get rid of it entirely?

OP_RETURN outputs are provably unspendable, and nodes do not need to store them in the UTXO set. Historically, up to 83 bytes have been tolerated only to avoid unprovably unspendable spam in other output scripts, and with the possible exception of commitment schemes that use OP_RETURN in coinbase transaction outputs (notably Segwit), using OP_RETURN is not the optimal solution to any known use case. With the advent of pay-to-contract and Taproot, it is now also possible to commit to external data in the Taptree, making even hypothetical use of OP_RETURN deprecated. However, to avoid breaking legacy protocols that still include such outputs, this proposal allows these outputs.

Why limit other data to 256/257 bytes?

With modern compression, it is plausible to represent images in as few as 300-400 bytes. Images are likely the most harmful use case for data storage, as they have huge demand and supporting them can engender high fees and UTXO-set bloat, as well as content that a large majority of node operators might object to.

256 bytes (2048 bits) is also more than sufficient for reasonably large numbers that might be potentially needed in legitimate cryptography, reinforcing Bitcoin's intended purpose as a monetary network.

Won't spammers just spread their data over multiple fields?

While it is impossible to fully prevent steganography, limiting data sizes ensures such abuses are non-contiguous and obfuscated within another intended meaning (script code, structure, etc). As far as Bitcoin is concerned, the data has some meaning other than the spammers' misinterpretation, and any external code to "reassemble" the unintended data is responsible for producing it (it is possible to write code that transforms *any* data into any other data - what matters is that Bitcoin has a well-defined meaning that is distinct from the unsupported one). Requiring users to divide their files into chunks of at most 256 bytes, raising the cost both in fees and in effort, sends a clear message that data storage abuses in general are unwelcome rather than sanctioned or supported.

What are "script argument witness items", referred to in rule 2?

Script argument witness items are the witness stack elements that are placed on the script interpreter's stack as inputs before the script is executed - the witness equivalent of data pushes in scriptSigs.

The following witness stack elements are not script argument witness items, and are thus excluded from rule 2 (though some are limited/invalidated by other rules):

• Some items are part of a spend that invokes the script interpreter, but are popped from the witness stack before the remaining elements are passed to it as inputs:

** Witness scripts and Tapleaf scripts (not limited) ** Control blocks (limited by rule 5) ** Annexes (invalidated by rule 4)

• Others are not part of a script-path spend at all, so the script interpreter is not invoked:

** Taproot key path signatures (limited to exactly 64 or 65 bytes by BIP 341 signature validation) ** Witness stacks in spends of undefined witness versions (invalidated by rule 3)

All other witness stack elements are script argument witness items, and are thus limited to 256 bytes by rule 2.

Why are BIP16 redeemScripts, witness scripts, and Tapleaf scripts exempt from rule 2?

BIP16 redeemScripts, witness scripts, and Tapleaf scripts are scripts, not data. Their contents are subject to the same OP_PUSHDATA* restrictions during execution. Restricting them is not only unnecessary, but would reduce the ability to make use of the intended script capabilities, and could impact legitimate real-world usage.

Why make spending undefined witness/Tapleaf versions invalid?

Since they are undefined, witness stacks spending these versions are completely unlimited currently to allow maximum flexibility in future upgrades. Any future upgrade, however, would need more than a year of coordination, so this softfork will not actually restrict it, and only safeguards against abuse in the meantime.

Why not make it invalid to send to undefined witness versions?

This would require the senders of transactions to check the witness version prior to sending, and require additional coordination when a new witness version is intended to become used.

Why not allow spending undefined witness versions with an empty witness?

This has no use case, but would require nodes to track these UTXOs in case of potential spending. By making spending invalid, it is possible for nodes to store them instead in slow memory not needed until this softfork expires. (With proper planning, it also makes it possible for a future softfork making use of these witness versions to allow users to receive with an upgraded wallet even prior to activation of the upgrade.)

Why make the Taproot annex invalid?

The annex is currently undefined data with unlimited size. It exists for future upgrades, but has no legitimate usage today. Any future upgrade, however, would need more than a year of coordination, so this softfork will not actually restrict it, and only safeguards against abuse in the meantime.

Why is the Taproot control block limited to 257 bytes instead of 256?

The control block is a series of hashes proving the Tapscript is part of the Taptree, plus a single byte with the leaf version and parity bit. See BIP 341 for details.

Why make OP_SUCCESS* invalid?

OP_SUCCESS* is meant for future upgrades. See above regarding undefined witness versions.

Why make OP_IF/OP_NOTIF invalid?

OP_IF/OP_NOTIF originated in pre-Taproot Bitcoin script language as a way to execute different subscripts based on a condition. With Taproot, the conditions can instead be evaluated off-chain, revealing only the intended verification execution path. Furthermore, when the conditions are met, the intent is that the keypath spend path should be used instead, avoiding publishing any scripts at all.

OP_IF is not only redundant for Tapscript, it is also commonly abused today to inject spam that gets skipped at execution. While it is impossible to fully prevent steganography, closing this gap eliminates one common abuse today basically for free, and sends a message that such abuses are not welcome. There are some potential experimental use cases for OP_IF in Tapscript. See the Tradeoffs section for more details.

Why is the proposal so simple?

A more complicated proposal could be envisioned that better balances innovation with safety, but implementing this properly would require extensive refactoring and review, delaying deployment when the change is already urgent. The rules proposed herein have been intentionally kept very simple to minimise review time and avoid unnecessary risks of overlooking unexpected side effects.

Why is this softfork temporary?

The impact of these restrictions would severely constrain future upgrades, potentially forcing them to be designed as a hardfork instead of a softfork. Some restrictions are also not ideal, but an improved limit would be more complicated to develop and test - by deploying these simpler restrictions now, we avoid making the perfect the enemy of the good enough, while still allowing for upgrading the limits to better variants in the future.

Over the next year, interested developers can implement and propose a longer-term solution to address the needs of the protocol without the tradeoffs or blunt/simplified changes.

Tradeoffs

Are there any tradeoffs?

Yes:

# Limiting Taproot control blocks to 257 bytes directly constrains the size of the on-chain, consensus-enforced script tree. This could complicate or possibly even impede advanced smart contracting like BitVM, which relies on a large number of executable scripts. In the worst case scenario, these use cases may just need to wait until this softfork expires. As they are still in early development, testnet and sidechains should be sufficient for the next year while a more scalable rule is implemented. # Upgrade hooks are not available for other softforks. As softforks adding new opcodes typically need at least a year to activate, this shouldn't be a practical issue. # Some wallet software such as Miniscript habitually creates Tapleaves containing OP_IF. To mitigate the risk of these funds being frozen for a year, this proposal exempts inputs that spend outputs that were created before activation, and provides a two-week grace period between lock-in and activation, to give users time to prepare.

Isn't the limit on Taproot control blocks too restrictive?

Possibly. The previous limit allows for 340,282,366,920,938,463,463,374,607,431,768,211,456 scripts, which is obviously way more than anyone could ever need. 257 bytes allows for 128 scripts, which is sufficient for modern and complex transactions. However, it may prove too limiting for advanced off-chain functionality such as used by BitVM. This is an unfortunate tradeoff that (if this softfork is accepted) we have chosen to accept in the short-term for the immediate benefits of this softfork. The intent is to relax this restriction later, when this softfork expires, with a new approach allowing larger trees, yet to be developed.

Do note that non-script (or non-Bitcoin-L1 scripts) usage of the taptree does not have this same limitation: just a single of the 128 leaves could very well be an extension of the merkle tree to greater depths th