DRAFT: PR #X Decouple Datacarrier Size and Output Count Limits for Adaptable OP_RETURN Policy

Status: Draft | Target: Bitcoin Core v30.1 (Q4 2025 - Q1 2026) | Author: @jotapea

Motivation

In Bitcoin Core v30.0, transactions with multiple OP_RETURN/nulldata outputs are relayed by default, allowing up to 100,000 bytes. Effectively, this uncaps the total nulldata size per transaction, as the transaction size limit is hit first.

The scope of this PR is addressing the outcome of these changes, not the reasons for them. And this should be undeniable: all Bitcoin software should incentivize nulldata over unspendable burn outputs for data.

However, the approach taken by v30.0's aggregated datacarriersize cap conflates per-output size with output count. It makes no distinction between a single contiguous data output, or this data being split between multiple outputs. While openly (defaulting to) relaying these data blobs, jumping from 83 bytes, to (<) 100,000 bytes (over 1000x increase).

This PR decouples the number of OP_RETURN outputs from the size of the outputs, to offer more granular limits control, while still supporting all features desired by Bitcoin node participants.

With just one additional configuration for nulldata relaying, Bitcoin Core can adapt to client configurations, and continue as the foundational Bitcoin node software of choice.

Proposed Changes

• -datacarrier (bool, default: 1): A flag to toggle OP_RETURN relay. When set to 0, this disables OP_RETURN transactions entirely. No changes here.

• -datacarriersize (int, default: 83): The maximum allowed byte size for any individual OP_RETURN output. The default is the historical cap of 83 bytes, but it can be any value. A value of 0 means no size limit. (Changed from v30.0, which redefined it as the aggregate of all nulldata outputs, while also making unlimited the default.)

• -datacarriercount (int, default: 1): The maximum number of OP_RETURN outputs allowed per transaction. Setting this to 0 would allow an unlimited number of OP_RETURN outputs. This is the only new configuration. (Prior to v30.0, this was hardcoded to 1.)

The aggregate nulldata size limit becomes datacarriersize * datacarriercount.

Implementation

TBD.

Configurations

For same policy as v30.0 / Libre Relay

datacarrier=1
datacarriersize=0
datacarriercount=0
# unlimited unsplit and split nulldata

Defaults proposed for v30.1 (historical default)

datacarrier=1
datacarriersize=83
datacarriercount=1
# single nulldata output with 83 bytes limit

Compromise: enough incentive over unspendable outputs (a new default possibility, but out of scope for this PR)

datacarrier=1
datacarriersize=83
datacarriercount=0
# unlimited split nulldata

Knots default

datacarrier=1
datacarriersize=42
datacarriercount=1
# single nulldata output with 42 bytes limit

"Knots extreme"

datacarrier=0
# no nulldata transactions relay

&lt;Customizable&gt;

datacarrier=1
datacarriersize=100
datacarriercount=50
# total size limit: 100*50 = 5000 bytes

Benefits & Trade-offs

Pros:

• Extends customization of OP_RETURN relay policy, with separate size and count limits, which cover the spectrum of nulldata carrying configurations used by Bitcoin node software.

• Retains money-first defaults for datacarriersize and datacarriercount that mimic historic consensus.

• The capacity to openly relay nulldata outputs is kept (no feature is lost from v30.0, is just reverting the defaults).

Cons:

• Minor increase in configuration complexity due to the introduction of one more parameter, though this is mitigated by better configurability.

• Reverts the datacarrier defaults from v30.0, making any reason for that change a possible argument against this PR. But that should be a separate issue pertaining the New Datacarrier Defaults.

---

---

Thank you for reading.

This can be a bit unusual, as there is no code yet for this. But that is the least of my worries.

I just wanted to do something before this highly controversial release.

All feedback is welcomed.

concept NACK, I don't think this extra configuration complexity adds anything useful to the software or the network as a whole. Miners are already including transactions without restriction on size, which is the whole reason why #32406 was proposed, discussed, written, reviewed, and merged.

The "extra complexity" is actually a fix to improved configuration. The current aggregated solution reusing datacarriersize has all signs of a hack. And is not surprising, as in the original goal was to deprecate.

The new feature allowing multiple OP_RETURN outputs warrants having its own very (simple and straightforward) configuration. And the usefulness is explicit: more control, not less.

Miners can do whatever they want, from using Knots, to Libre Relay. But changing the defaults for the CORE software is not some trivial change. @pinheadmz why diminish the controversy you must be very aware of the v30 changes? Isn't is obvious the repo discussion will support the controversial change?

I just don't understand the motivation. v30 users can set -datacarriersize=83 to keep the previous policy.

The motivation is respect the consensus. -datacarriersize=83 isn't even the default any more.

The usefulness is control of the number of outputs separated from the size per output. Having both be one is sloppy. Multiple nulldata outputs is a new feature, which should be configurable.

The new config would be simple, seen from v30.1:

For same policy as v30.0 / Libre Relay

datacarrier=1
datacarriersize=0
datacarrierlimit=0

Defaults proposed for v30.1 (same result as historical consensus)

datacarrier=1
datacarriersize=83
datacarrierlimit=1

Knots (extreme)

datacarrier=0

(customizable)

datacarrier=1
datacarriersize=100
datacarrierlimit=100
# aggregate 100*100 = 10000 bytes

This is a perfect paper trail for the litigious

Concept NACK, issue looks like LLM slop

@delta1 Let me help clarify anything you might need help understanding. Ai slop is generally useless. This is the opposite, a concise and straightforward upgrade to improve OP_RETURN relay policy configuration.

@jotapea it may not necessarily "imrpove" configuration but by definition does make it more complicated. What it will certainly do is reduce the quality of transaction relay and compact block propogation -- as explained repeatedly over the past several months in posts like these:

https://delvingbitcoin.org/t/addressing-community-concerns-and-objections-regarding-my-recent-proposal-to-relax-bitcoin-cores-standardness-limits-on-op-return-outputs/1697

I encourage you to ask further questions on that post. I also think this issue should be closed.

@jotapea no issues understanding anything. It's apparent you used an LLM to write this. You should close this issue.

@delta1 You are partially right, ai was used as assistance to the original post. I can recommend it if you have similar needs, specially if is not your native language... Now, do you have anything concrete about the draft to discuss? @pinheadmz Thank you for productively engaging. But please allow some discussion before deciding to close the issue.

By definition any additional configuration is adding complexity... ok I could agree. It is an extremely simple one though.

reduce the quality of transaction relay and compact block propogation

Can you elaborate? The link you sent is quite long, so not sure where you want me to focus. The general idea I get is that it justifies the removal of OP_RETURN limits, mixing valid arguments with opinions.

quality of transaction relay: How are you measuring quality? compact block propagation: Reading that this is dependent on txids, not the transaction content itself.

Maybe you refer to benefits of having all mempools sharing the same policies?

Go ahead and make your PR for this 👍 let’s see how it’s received

Status: Draft | Target: Bitcoin Core v30.1 (Q4 2025 - Q1 2026) | Author: @jotapea

I think there are several misunderstandings about the development process. You can refer to CONTRIBUTING.md to learn more about it, but to summarize:

• It is not possible to open a feature or breaking change pull request directly to a release branch. If this was done, the change would be missing on the main staging branch for the next release and the feature or breaking change would "undo itself".
• Point releases do not have strict target release aims, like major releases. They happen when they are needed. However, any code in point releases will have to be reviewed at least twice: When it is merged into master, and then again, when it is backported. However, the review process does not follow deadlines either.

ai was used as assistance to the original post. I can recommend it if you have similar needs,

Generally I am happy to review stuff, but if it is clear that most of it is just LLM generated and is even missing to read the contributing md file, I get less excited about providing feedback.

I think this PR would be better titled as "Make policy acceptance of multiple datacarrier outputs a configurable option", with the idea being to either introduce a boolean ("-multipledatacarrier=1" by default, allowing multiple datacarrier outputs; "-multipledatacarrier=0" as an option, reverting to the 29.x and earlier default of allowing one output per transaction, and "-datacarrier=0" to not allow any such outputs) or a count ("-datacarriercount=10000" by default, being effectively unlimited, "-datacarriercount=1" giving the the 29.x and earlier default behaviour, and other values also being possible).

I don't think this is a valuable feature to have, however.

datacarriersize=100
datacarriercount=50
# total size limit: 100*50 = 5000 bytes

datacarriersize is (and should remain) a cumulative limit for the entire transaction, so this should be expressed as datacarriersize=5000 datacarriercount=50 allowing for either 50 100-byte outputs (effectively 97-bytes of data each for 4850 bytes total) or a single 5000-byte ouput (effectively 4996-bytes of data).

The feature request didn't seem to attract much positive attention in the past. Thus, closing due to lack of interest, progress and direction. It is possible to re-open this issue or create a new issue referencing it, if there is fresh interest.