OP_RETURN: let's analyze a little bit

some technical consideration beyond ethical debates

The role of OP_RETURN in Bitcoin has long been a point of debate among developers, miners, and businesses building on top of the protocol. Introduced as a standard mechanism for embedding small pieces of arbitrary data in a provably unspendable output, OP_RETURN has historically been constrained by strict relay policies, most notably the long-standing 80-byte limit enforced by Bitcoin Core. Up to version v29, Bitcoin Core maintained conservative restrictions to discourage on-chain data storage and preserve Bitcoin’s primary function as a decentralized monetary network.

With the release of Bitcoin Core v30, however, these rules have undergone their most significant shift in nearly a decade: the maximum permitted OP_RETURN payload has been dramatically increased, and transactions are now allowed to include multiple data-carrying outputs. These changes—still firmly within policy, not consensus—have opened the door to new use cases while simultaneously raising fresh concerns about bandwidth, storage costs, and the potential for blockchain bloat.

At the same time, Bitcoin Knots, an alternative Bitcoin implementation known for stricter validation rules and a more conservative stance on data-carrying transactions, continues to enforce tighter limits on OP_RETURN. This divergence between Bitcoin Core and Knots highlights a broader discussion within the Bitcoin ecosystem about data embedding, node resource requirements, miner incentives, and the trade-offs between flexibility and long-term sustainability.

This article examines how OP_RETURN worked up to Bitcoin Core v29, what has changed in v30, how Bitcoin Knots approaches data-carrying outputs, and the benefits and risks associated with each model. The goal is to provide a clear, factual, and balanced analysis for developers, node operators, and Bitcoin infrastructure providers evaluating the implications of these evolving policy choices.

Limits on op_return on both Bitcoin Core and Knots

The limit on the data carrier size, which relates to the op_return field in a transaction, is a key point of debate between Bitcoin Core and Bitcoin Knots implementations.

• Bitcoin Knots: The default setting for the data carrier size (or op_return limit) in the mempool is 42 bytes. This small amount of data allows people to embed certain information, such as a little bit of text, but not a huge amount. Knots offers additional configurability for the mempool, allowing users to change this setting. For instance, a user can set the limit to zero bytes to filter out all op_return transactions from their mempool.

• Bitcoin Core (v29): The previous implementation of Bitcoin Core (v29) has a default data carrier size of about 83 bytes.

What Bitcoin Core v30 actually changes about OP_RETURN

released october. The main changes:

1. -datacarriersize Default Raised to 100,000 Bytes

   • In v30, the default value for -datacarriersize is increased to 100,000 bytes.

   • According to the release notes, at that size “the maximum transaction size limit will be hit first,” meaning the OP_RETURN limit is no longer the bottleneck for “standardness” under many circumstances.

   • You can still override this to the previous behavior by setting -datacarriersize=83 to revert to the older limit

2. Multiple OP_RETURN Outputs Allowed

   • v30 allows multiple data-carrier (OP_RETURN) outputs in the same transaction (for relay and mining).

   • The -datacarriersize limit applies to the aggregate size of those OP_RETURN scriptPubKeys (i.e., it sums over all those outputs), not individually.

3. Policy Change, Not Consensus Change

   • These changes are policy-level, not consensus rules. That means they affect what a node will relay or accept into its mempool, not whether a block is valid.

   • Because of that, there’s no risk of a chain split solely due to this change

4. -datacarriersize Option Still Present

   • Even though the default is increased, the -datacarriersize configuration option remains available.

   • There was discussion of deprecation of -datacarriersize, but based on a late-stage change (PR #33453), the deprecation warning was removed.

   please checkout: https://github.com/bitcoin/bitcoin/issues/33595

   One of the many problems cited with this implementation is that it allows users to put in full JPEGs, small MP4s, audio, or illicit material into the blockchain. Historically, increasing this limit (as seen with BSV, which increased it to 100 kilobytes) resulted in child abuse imagery being embedded in that blockchain.

Differences between what happens to a transaction in mempool compared to what happens when a transaction is included in a block

The processing of a transaction differs significantly between the mempool (implementation layer) and inclusion in a block (consensus layer).

mempool is a temporary waiting space for transactions after they are broadcast to the network. It is the “waiting room before it gets put into a block”. They are governed by Mempool Policy. These are optional, subjective decisions and filters set by the individual node runner.

Consensus Rules. These are the base layer rules that all miners must accept as valid. A node uses its filters to decide if it will accept and relay a transaction to its peers. If a transaction violates the node’s policy (e.g., fee too low or op_return too large), it is rejected from that node’s mempool. A miner includes transactions from their mempool into a block they mine, and this block is added to the blockchain. Effect Policies result in different mempools across the network; no mempool looks exactly the same. Filtering can make it more difficult or expensive for transactions to get mined. Inclusion in a block is permanent.

If a transaction violates consensus rules, it does not get included in any mempool. If a transaction is consensus-valid but violates many mempool policies, a miner can still include it, bypassing the filtering mechanism of most nodes.

Mempool policy configuration is often described as self-defense of a node’s resources (disk, bandwidth, RAM) against spam. While filtering can make things more difficult and align incentives by increasing the economic friction for certain transactions, it cannot fully censor a consensus-valid transaction, as a miner can still choose to include it.

The mempool policy is like your individual email spam filter—you can set it strictly to protect your inbox (your resources), but that doesn’t stop the sender from mailing the same letter to someone else who uses a laxer filter.

What does Slipstream Mara do?

Slipstream is a product that facilitates submitting a transaction directly to a miner, completely bypassing the standard mempool policy filters of the network.

• Function: Users can use Slipstream to submit transactions, often those containing a really high op_return or large amounts of data.

• Provider: The service is provided by the massive mining pool Mara.

• Cost: Mara charges a massive premium to include transactions submitted via Slipstream, sometimes double the current mempool fee rate.

• Internal Filters: Despite enabling users to bypass network-wide mempool filters, Slipstream itself has terms and conditions that act as filters. Users are prohibited from using Slipstream to engage in activities that violate applicable laws, including participating in money laundering or uploading illegal content (such as illicit images). This policy is necessary because, without it, the ability to put massive op_returns into the blockchain could lead to the inclusion of illegal material.

Please let me know what is your opinion about what described in this article. What will be the future of Bitcoin and your position on how spam should be handled in this debate.