docs: Undeprecate datacarrier and datacarriersize configuration options

bitschmidty commented at 10:40 am on September 22, 2025: none

Removes the deprecation for the datacarrier and datacarriersize options by reverting commit 0b4048c73385166144d0b3e76beb9a2ac4cc1eca from #32406

Many current Bitcoin Core users want to continue using this option This statement is based on public postings from many Bitcoin Core users and not a formal survey. AJ Towns’ observation from #32406 that “for now there seem to be a bunch of users who like the option” has only become more apparent in the months since.

The deprecation intent is unclear to users This echo’s Ava Chow’s comment from #32714 that “IMO we should not have removal warnings if there is no current plan to actually remove them.” In months since that comment, partially due to increased feedback from Bitcoin Core users wanting to keep this option, there is even less likelihood of a near term plan to remove these options. That leaves Bitcoin Core users in an unclear situation: the option could be removed in the next version or perhaps never. Removing the deprecation gives clarity for their planning purposes. Deprecating the option in the future, preferably with a removal schedule to better inform users, would still be possible.

Minimal downsides to removing deprecation As a best practice, Bitcoin Core has avoided an option when the developers cannot articulate when they should be used. There is non-zero maintenance cost to keeping this code around (although leaving the options deprecated for a long time has the same effect). “Don’t offer users footguns” is also a good principle, but with this option, there seems to be only small impacts that can quickly be remedied by changing the option value by Bitcoin Core users. There already exist in Bitcoin Core more potentially-user-harmful options/values than what datacarrier might cause.

datacarrier: Undeprecate configuration option

Reverts commit 0b4048c73385166144d0b3e76beb9a2ac4cc1eca

451ba9ada4

DrahtBot commented at 10:40 am on September 22, 2025: contributor

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/33453.

Reviews

See the guideline for information on the review process.

Type	Reviewers
ACK	moonsettler, ajtowns, darosior, instagibbs, ismaelsadeeq, jonatack, Zero-1729, Raimo33, Ademan, ryanofsky, vasild, marcofleon
Concept NACK	reardencode, polespinasa, chrisguida, waketraindev
Concept ACK	jlopp, delta1, CodeShark, kevkevinpal, RandyMcMillan, kristapsk, ariard, IdotMaster1, hMsats, alfredopalhares

If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

bitschmidty commented at 10:41 am on September 22, 2025: none

I open this PR with the goal of having the deprecation removed for the upcoming v30 release, in order to minimize any additional confusion around this option.

I ask that any Bitcoin Core users that want to indicate support or opposition to this PR without providing technical feedback use the 👍 or 👎 reactions rather than an ACK/NACK in hopes of keeping this PR easy and expeditious to review.

Disclaimer: I am the executive director of Brink, an organization that funds some Bitcoin Core developers, some of which may review this PR. I have emailed them separately letting them know that any review feedback here (positive or critical) will not impact their standing, funding, or employment with Brink. Independent review and open discussion are critical for Bitcoin Core, and Ive encouraged them to engage as they would with any other contributor.

jlopp commented at 10:59 am on September 22, 2025: contributor

Concept ACK.

Defaults are strong; we should expect relatively few users will change this setting.
We understand that transaction propagation requires relatively few nodes with loose policy rules.
I think it’s minimal impact and gives users more freedom to operate their node as they wish.

delta1 commented at 11:00 am on September 22, 2025: none

Concept ACK

portlandhodl commented at 11:11 am on September 22, 2025: contributor

Concept Ack assuming a long window before revaluation to deprecate

The value to the reduced social DoS would be higher than the cost of keeping the deprecation.
Not that it’s needed but further proof that deprecation doesn’t always lead to deprecation ultimately which is a good thing.
Would give devs more time to understand the core users of this option after removal of previous limits.

Concern: That if decided to be deprecated in the future this could lead to campaigns by other implementation maintainers to socially discredit Bitcoin Core thus causing another round of social DoS. Basically looping on the flat circle of time.

moonsettler commented at 11:12 am on September 22, 2025: none

ACK https://github.com/bitcoin/bitcoin/commit/451ba9ada41f687c0e4bb34d5925374a68a8f8a3

The arguments about the burden to further maintain the option are way overstated and therefore incredibly weak.

CodeShark commented at 11:19 am on September 22, 2025: contributor

Concept ACK

Some users clearly still want this option and keeping this option in doesn’t negatively impact any other users nor make the code harder to maintain than having the option marked as deprecated. It’s a really bad idea to alienate users over this.

I also suggest making it clear to endusers as well as packagers and node-in-a-box vendors that this option is still around and to make it easy for them to use it. Regardless of whether we think using this option has the purported effects some users claim, why have them abandon Bitcoin Core over this?

kevkevinpal commented at 11:27 am on September 22, 2025: contributor

Concept ACK

I agree that removing the deprecation does not have a major effect on users, and it also gives users who want to use this flag a signal that it will not be removed in a future release. I see no issue in offering flexibility for node runners.

Is this able to be added to the v30 milestone? https://github.com/bitcoin/bitcoin/milestone/72

reardencode commented at 11:30 am on September 22, 2025: none

Concept NACK

bitcoin core is not here to be everyone’s everything implementation. It’s here to be the best software for operating the network.
Adding, or in this case not removing, code with only negative effects on the actual operation of users’ nodes is not responsible stewardship of bitcoin.
Bowing to demands from people who do not understand what they are asking for (as repeatedly demonstrated in online argumentation) is not how any successful project can operate.

These issues are understandable by non-technical users with intelligence and open mind. Those are the users to cater to. https://x.com/CitizenBitcoin/status/1969421147293839618

0xB10C commented at 11:34 am on September 22, 2025: contributor

fwiw: If/when this is merged, the draft release notes should be updated. They mention: Both -datacarrier and -datacarriersize options have been marked as deprecated and are expected to be removed in a future release.

edit: Nvm, this PR is against master. While the tweet mentions “The tactical goal is to get the change into the forthcoming Bitcoin Core v30 release.” - this isn’t relevant until back-ported. As pointed out in #33453 (comment)

RandyMcMillan commented at 12:04 pm on September 22, 2025: contributor

Concept ACK

RandyMcMillan commented at 12:27 pm on September 22, 2025: contributor

you should probably rewrite/revert

https://github.com/bitcoin/bitcoin/pull/32406/commits/63091b79e70b8e230a122fa6fb3dac91c80638e7

and other considerations:

https://github.com/bitcoin/bitcoin/commit/2885bd0e1c4fc863a7f28ff0fd353f5cffb03442

as well

ajtowns commented at 12:42 pm on September 22, 2025: contributor

ACK 451ba9ada41f687c0e4bb34d5925374a68a8f8a3

I don’t think getting upset about the presence or absence of a deprecation note is sensible, so my ACK shouldn’t be taken as an indication that I’ll be upset if this PR isn’t merged.

There were a few rationales given for deprecation, I think the strongest being:

the philosophy that “all user options should either come with clear recommendations for how to use them or, if no recommendation can be made, they should not exist or be discouraged” (ref)
the expectation that the option will be removed in the next release or shortly thereafter (ref)

As far as the first point goes, I think we can actually make clear recommendations for when to use the datacarrier options:

if you wish to avoid including large OP_RETURN outputs in blocks you mine, then reducing the datacarriersize will allow you to do that
if you wish to be more strongly compatible with the 29.x and earlier relay policy, reducing the datacarriersize to 83 will get you most of the way there
if the new default policy causes unforseen problems, then reducing the datacarriersize may allow you to avoid/mitigate those problems without needing to deploy a new release of the software

I think the latter two recommendations generalise fairly well, and thus that it’s probably a bad idea to both change a configuration option’s default and remove/deprecate that option at the same time.

As far as the first point goes, I don’t believe a deprecation notice without a definitive removal timeline specified should be taken as an expectation that the option will be removed soon (ref, ref), and I don’t believe there’s any significant value in removing this option, as the maintenance cost for keeping it is extremely low.

I wrote previously that “the reason to recommend not using it is because it will likely harm the efficiency of block reconstruction, slowing down block relay”, but I don’t think the effect there is particularly significant: with compact blocks working efficiently we expect blocks to be relayed across the network in perhaps 500ms (200ms one-way latency to the other side of the world, plus a couple of 150ms sets as nodes actually validate the block), which gives an implied orphan rate of about 0.08% or about 1 in 1250 blocks, which is pretty close to what we see. When compact block relay requires a request, that forces 1.5 round trips (tripling the latency versus the one-way value) so that may give a value from 900ms to 1500ms, with an implied orphan rate between 0.15% and 0.25%. If you’re currently mining with an orphan rate of 0.08% then an orphan rate of 0.25% would be a decrease in revenue of 0.17%. For comparison, the difficulty increase from early May to now (given the same hashrate) implies a decrease in revenue of 19.5%, more than 100x as much. I think it makes sense to set defaults to maximise even small amounts of revenue, but that’s a “picking up pennies” saving, not a “small miners will be put out of business” situation.

DrahtBot requested review from moonsettler on Sep 22, 2025

kristapsk commented at 12:54 pm on September 22, 2025: contributor

Concept ACK

instagibbs commented at 1:45 pm on September 22, 2025: member

@bitschmidty to be clear are you considering this as something to backport (30 et al), or just for following releases from master.

Assuming this is merged no one who will bother setting this argument in 30.0 will be unable to find relevant drama and the resolution of the PR in the affirmative.

~~)concept NACK on backport,~~ truly ambivalent on undeprecating because I can see how it’s confusing to honestly curious users to not have a timeline to do so (and maybe bad project hygiene), but also it’s just not very important.

darosior commented at 1:46 pm on September 22, 2025: member

I think Bitcoin Core should strive to limit its extensive and growing number of startup options. Optionality for the sake of it is counterproductive. On this basis, the -datacarrier and -datacarriersize options controlling a long obsolete relay policy limit are in my opinion prime candidates for removal.

That said, certain users care strongly about using those options. In these conditions, i do not see the project removing the option anytime soon. Therefore i think it’s technically incorrect (and confusing) to mark it as deprecated. utACK 451ba9ada41f687c0e4bb34d5925374a68a8f8a3 on removing the deprecation.

fwiw: If/when this is merged, the draft release notes should be updated.

Well, only if it gets backported to 30.0?

0xB10C commented at 2:04 pm on September 22, 2025: contributor

fwiw: If/when this is merged, the draft release notes should be updated.

Well, only if it gets backported to 30.0?

Correct, I’ve edited my comment to reflect that.

bitschmidty commented at 2:28 pm on September 22, 2025: none

are you considering this as something to backport (30 et al)

That is preferred IMHO. But that is the judgment of you all and those responsible for the release process (assuming this PR gets support).

instagibbs commented at 2:34 pm on September 22, 2025: member

Ultimately that’s a maintainer’s call (burden of backporting, badgering for review, and cutting RCs), I will not put up a fuss either way.

ajtowns commented at 3:03 pm on September 22, 2025: contributor

As it stands, this PR is based on the most recent common commit between 30.x and master, so it can be merged as-is into both branches, without any additional backporting needed.

jimmysong commented at 3:10 pm on September 22, 2025: contributor

While I agree with the logic for un-deprecation, I don’t think this PR goes far enough as the functionality of the datacarriersize argument is fundamentally different than what it was in v29. Multiple OP_RETURN outputs are still allowed by this change, creating a situation where users cannot get the same behavior from their nodes’ relay policy from previous versions through configuration.

It’s still a mystery to me why multiple OP_RETURNs are being allowed since an extra OP_RETURN costs at least 9 more vbytes and the same data can be stored in one OP_RETURN with some sort of (perhaps multi-byte) delimiter. Perhaps there are use-cases for multiple OP_RETURNs that can’t be done in one OP_RETURN that I’m not aware of?

instagibbs commented at 3:11 pm on September 22, 2025: member

crACK 451ba9ada41f687c0e4bb34d5925374a68a8f8a3

Ambivalence aside

instagibbs commented at 3:14 pm on September 22, 2025: member

It’s still a mystery to me why multiple OP_RETURNs are being allowed since an extra OP_RETURN costs at least 9 more vbytes and the same data can be stored in one OP_RETURN with some sort of (perhaps multi-byte) delimiter. Perhaps there are use-cases for multiple OP_RETURNs that can be done in one OP_RETURN that I’m not aware of?

The motivation for doing this is for situations where you cannot commit to all data efficiently otherwise. Think SIGHASH_SINGLE | ACP scenarios. The datacarriersize argument applies to payloads themslves, so yes, if someone wants to do ~80 bytes of payload and can do it in one output, they should just do that.

jimmysong commented at 3:27 pm on September 22, 2025: contributor

The motivation for doing this is for situations where you cannot commit to all data efficiently otherwise. Think SIGHASH_SINGLE | ACP scenarios. The datacarriersize argument applies to payloads themslves, so yes, if someone wants to do ~80 bytes of payload and can do it in one output, they should just do that.

That’s fair.

Was this use case an explicit goal of the previous PR? Because I don’t think users are aware of whatever potential benefits this might have. Personally, I don’t currently see this as a worthwhile enough use-case for changing the functionality of the datacarriersize option, but I’m open to the possibility that this use case is worth making the configuration option non-backwards compatible.

The other possibility is to add another configuration option for the number of OP_RETURN outputs allowed, which would achieve both goals, but then would run up against the desire to minimize configuration options.

ismaelsadeeq approved

ismaelsadeeq commented at 3:29 pm on September 22, 2025: member

utACK 451ba9ada41f687c0e4bb34d5925374a68a8f8a3 🛰️

Per my review on the initial PR #32406#pullrequestreview-2814921270

glozow added the label Docs on Sep 22, 2025

glozow renamed this:
~~datacarrier: Undeprecate configuration option~~
docs: Undeprecate datacarrier and datacarriersize configuration options
on Sep 22, 2025

Kruwed commented at 4:08 pm on September 22, 2025: none

Many current Bitcoin Core users want to continue using this option This statement is based on public postings from many Bitcoin Core users and not a formal survey. AJ Towns’ observation from #32406 that “for now there seem to be a bunch of users who like the option” has only become more apparent in the months since.

Popularity is not a sufficient reason alone, can you provide any of the underlying reasons why these users want to continue using this option?

adam3us commented at 4:30 pm on September 22, 2025: none

While I agree with the logic for un-deprecation, I don’t think this PR goes far enough as the functionality of the datacarriersize argument is fundamentally different than what it was in v29. Multiple OP_RETURN outputs are still allowed by this change, creating a situation where users cannot get the same behavior from their nodes’ relay policy from previous versions through configuration.

It’s still a mystery to me why multiple OP_RETURNs are being allowed since an extra OP_RETURN costs at least 9 more vbytes and the same data can be stored in one OP_RETURN with some sort of (perhaps multi-byte) delimiter. Perhaps there are use-cases for multiple OP_RETURNs that can’t be done in one OP_RETURN that I’m not aware of?

you can get the same behavior - use one op return. the data-carrier size with multiple op returns is the sum of the data across them. limiting number of op returns isn’t protective, people who want to can create multiple transactions, which is higher overhead than one transaction with multiple op returns. obviously a single op return is lower overhead than multiple, but people can create multiple transactions too fi they want so it’s not something logical to attempt to discourage with policy.

jonatack approved

jonatack commented at 4:31 pm on September 22, 2025: member

ACK 451ba9ada41f687c0e4bb34d5925374a68a8f8a3

Agree with the change, reviewed, verified that it is clean revert of 0b4048c73385166144d0b, built/ran tests locally.

Note: it looks like the translation files would need updating (not in this PR).

bitschmidty commented at 4:35 pm on September 22, 2025: none

Popularity is not a sufficient reason alone, can you provide any of the underlying reasons why these users want to continue using this option?

Sure, from what Ive seen: Some miners want to use Bitcoin Core for block template building but dont want to include large op_returns. Relay nodes/node runners do not want to relay unconfirmed large op_returns.

Zero-1729 commented at 4:41 pm on September 22, 2025: contributor

crACK 451ba9ada41f687c0e4bb34d5925374a68a8f8a3

Agree with the rationale in the OP. This is a step in the right direction IMHO.

Kruwed commented at 4:53 pm on September 22, 2025: none

Sure, from what Ive seen: Some miners want to use Bitcoin Core for block template building but don’t want to include large op_returns. Relay nodes/node runners do not want to relay unconfirmed large op_returns.

Why should Bitcoin Core support a config option to perform targeted censorship of large OP_RETURNs?

in src/init.cpp:907 in 451ba9ada4

902@@ -903,10 +903,6 @@ bool AppInitParameterInteraction(const ArgsManager& args)
903         InitWarning(_("Option '-checkpoints' is set but checkpoints were removed. This option has no effect."));
904     }
905 
906-    if (args.IsArgSet("-datacarriersize") || args.IsArgSet("-datacarrier")) {
907-        InitWarning(_("Options '-datacarrier' or '-datacarriersize' are set but are marked as deprecated and are expected to be removed in a future version."));

polespinasa commented at 4:55 pm on September 22, 2025:

Maybe just remove the "expected to be removed in a future version" sentence.

0        InitWarning(_("Options '-datacarrier' or '-datacarriersize' are set but are marked as deprecated and the use of it is discouraged."));

jb55 commented at 3:13 pm on September 23, 2025:

ACK this ^

The main complaint I see from people is this phrase. I believe it is still useful to mention it’s deprecated/discouraged.

glozow commented at 7:34 pm on September 23, 2025:

I’d agree with this approach

Raimo33 commented at 5:23 pm on September 22, 2025: none

ACK 451ba9ada41f687c0e4bb34d5925374a68a8f8a3

I believe Bitcoin Core should remain neutral and allow full configurability at the policy level, while still providing the best defaults for network efficiency. It is not Core’s role, or Knots’, or anyone’s to decide which options P2P participants may use.

Removing configurability from the reference implementation raises the barrier for non-technical users who want to run Bitcoin with their preferred settings. This restricts freedom of choice without solving the underlying ““issue””, since such filtering cannot be enforced. Anyone can still run older Core versions and set parameters like datacarriersize manually, but doing so means giving up the performance improvements of newer releases.

imo this is a step in the right direction.

polespinasa commented at 5:31 pm on September 22, 2025: contributor

Concept NACK

As per wikipedia definition: “Deprecation is the discouragement of use of something human-made, such as a linguistic term a proper name a feature, design, functionality, piece of code, or practice.”

This is exactly what was intended to do with the original (merged) PR. IMHO if we want to build software that we consider good for the users, as we stated in the relay-policy post, we should stay in that position and keep taking decisions based on what we think is the best and not for “drama” consequences.

The campaign against Core is big and a change like this can be seen as a “we are not that bad” and a try to make them stop complaining.

This change is clearly not enough for the users whose ultimate goal is to get the default value and behavior back. This PR will not change anything in that way, but it can give the message, to people who supported the change (and supported Core devs), that it may not be worth to support us next time because public pressure and FUD can easily change our minds. And anyway, because of what I mentioned already, the people who are complaining don’t use Core and won’t start using it after this change.

I would prefer a PR improving the deprecation message to make it clear that we are discouraging the use of the option, but not planning to remove it (for the moment). Re-opening #32714 with the deprecation message back sounds like a better idea to me.

If we consider that “filtering” transactions is bad, we must discourage doing it.

Crypt-iQ commented at 5:43 pm on September 22, 2025: contributor

@ajtowns wrote:

For comparison, the difficulty increase from early May to now (given the same hashrate) implies a decrease in revenue of 19.5%, more than 100x as much. I think it makes sense to set defaults to maximise even small amounts of revenue, but that’s a “picking up pennies” saving, not a “small miners will be put out of business” situation.

Is the argument that poor compact block reconstruction rates leads to miner centralization overblown then if the loss in revenue due to orphans is dwarfed by the increasing difficulty? I thought this argument was one of the reasons for both uncapping OP_RETURN limits and for allowing sub-1sat/vb relay?

moonsettler commented at 7:41 pm on September 22, 2025: none

I would prefer a PR improving the deprecation message to make it clear that we are discouraging the use of the option, but not planning to remove it (for the moment).

That is also fine. I have not changed my mind on this, I considered removing the option a bad move to begin with. This option being configurable made even less practical sense in the past than it has going forward.

BitcoinMechanic commented at 7:50 pm on September 22, 2025: none

Slating configurability for removal is one of three issues with #32406 which this fixes and is strictly an improvement.

The other two issues - datacarriersize no longer working correctly and the setting of it to a malicious default - both remain.

In that context, all this specific PR serves to do is help manufacture consent for an unjustified change in attitude towards arbitrary data by making the most mild concession possible to those against it, while still achieving the overall goal: giant OP_RETURNs that pose an enormous risk to Bitcoin.

32406 needs to be reverted entirely for Core to regain credibility.

bitschmidty commented at 8:02 pm on September 22, 2025: none

this specific PR

This specific PR seeks clarity in the datacarrier options’ future availability, in favor of removing the deprecation, as the deprecation designation definition is unclear, potentially incorrect (if the definition is will be removed), and causes uncertainty for Bitcoin Core users around timing.

Ademan commented at 8:29 pm on September 22, 2025: none

utACK 451ba9a

I’d strongly caution against backporting this unless there’s clear precedent, however. (I’m not claiming there is or isn’t clear precedent)

glozow commented at 9:17 pm on September 22, 2025: member

This specific PR seeks clarity in the datacarrier options’ future availability

+1. I think the comments so far are largely on topic, but let’s try to avoid rehashing the motivations around the policy change itself or re-litigating what the default value should be. Reminder that delving bitcoin, mailing list posts, and a meta topic on the bitcoin-core discussions page exist. Thanks!

chrisguida commented at 9:36 pm on September 22, 2025: none

NACK

This is too little, too late.

It does not matter whether this option is deprecated or not. With the merging of #32406, core has already signaled that it is absolutely unwilling to address data spam, ever, and is now accelerating towards spam maximization.

Since our hostility to spam is the main deterrent against spam (see: why Vitalik stopped trying to build Ethereum on bitcoin: “I did not want to build on a base protocol whose dev team would be at war with me”), the only thing that would cause dissenters to significantly move back to core would be a reversal of #32406 and a merging of #28408.

In the absence of some kind of signal from core that they are willing to be just as militant against spam as they were in 2014, this change would, if anything, just slightly slow down the next best solution, which is Knots becoming the supermajority client.

I don’t expect this PR to actually cause anyone to change their minds about switching, though, since it’s at most a meaningless gesture.

parabitdev commented at 10:35 pm on September 22, 2025: none

Removal of and are expected to be removed in a future version for technical accuracy is an admirable objective (no clear plan/timeline to do so, meaning this is untrue at this time). A complete removal of deprecation is a bit hasty unless someone plans to resolve the behavior changes this flag exhibits with regards to things like multiple op_returns in a single transaction.

I only support this change if someone plans to champion that work, otherwise this feature is deprecated in the truest sense and failing to mark it as such would be irresponsible.

Code is a simple revert of a commit and appears to have no meaningful technical drawbacks.

ariard commented at 2:51 am on September 23, 2025: none

Concept ACK.

To give a single data point, it took 3.5 years to go from an initial proposal about -mempoolfullrbf during the release cycle of v22.0 to a release completely deprecating the ability for a full node operator to police its processed transactions with the opt-in RBF policy (v29.0). If there is no consensus, it’s wiser to take time to build consensus…

ajtowns commented at 4:03 am on September 23, 2025: contributor

Is the argument that poor compact block reconstruction rates leads to miner centralization overblown then if the loss in revenue due to orphans is dwarfed by the increasing difficulty? I thought this argument was one of the reasons for both uncapping OP_RETURN limits and for allowing sub-1sat/vb relay?

The comparison is that losing $1.70 out of every $1000 in revenue is effectively just noise or a rounding error in an environment where you’re getting $195 swings due to other factors, so is unlikely to be a make-or-break effect. But that said, $1.70 is still better than $0 (or losing $193.50 is better than losing $195), so it’s still worth trying to improve things. Over a year, 0.17% of revenue for a miner with 1% of global hashrate is $300k at current prices, for instance.

The introduction of compact block relay saw a much larger decrease in block relay times – on the order of perhaps 6 seconds down to 0.5 seconds, which corresponds to implied orphan rates of 1% (one a day) reducing to 0.08% (one a week), so the saving there is closer to $10 out of every $1000, which is more impactful. But that change wasn’t just due to avoiding round trips, but also due to reduced bandwidth usage, relaying after checking proof of work but before full validation, and other improvements in validation performance. So I think it makes sense that inefficiencies here don’t take us all the way back to the bad old days of 2016, and we don’t need to worry that every non-optimal in this area choice might have large centralizing effects.

The “degrades compact block performance” argument applies to any relay policy differences where there is significant number of txs that make use of the distinction; so likely applies to all of fullrbf, OP_RETURN, sub-1sat relay, TRUC, ephemeral anchors, and ancestor/cluster limits. It’s potentially particularly strong for sub-1sat relay, since that often involves enough transactions that it not only adds a round-trip, but the amount of data that needs to be relayed for blocks that are mostly sub1sat may also become impactful, particularly for the first few listening peers to see the block that need to relay the block data to over 100 peers each.

Kruwed commented at 7:41 am on September 23, 2025: none

This specific PR seeks clarity in the datacarrier options’ future availability, in favor of removing the deprecation, as the deprecation designation definition is unclear, potentially incorrect (if the definition is will be removed), and causes uncertainty for Bitcoin Core users around timing.

Why shouldn’t the datacarrier options be removed? My earlier question remains unaddressed:

Why should Bitcoin Core support a config option to perform targeted censorship of large OP_RETURNs? @Sjors made a concise point on how deprecation/removal are tied together: #32406 (comment)

It briefly retains it, typically deprecation is followed by removal one release later. So if you’re opposed to direct removal, then everyone will understand that you’re also opposed to deprecation, so there’s nothing new to say.

Sjors commented at 8:26 am on September 23, 2025: member

Concept meh, I think removing the deprecation warning sets the wrong expectation.

Those who fully want to embrace filtering should be looking for alternative software, rather than demand that Bitcoin Core implements it for them.

The current code is deprecated in the sense of being unmaintained, even if it’s not going to be removed anytime soon. Pull requests that try to expand or “improve” their functionality have consistently been closed.

So perhaps the following can be softened, from:

marked as deprecated and are expected to be removed in a future version.

To:

marked as deprecated and may be removed in a future version.

Sjors commented at 8:35 am on September 23, 2025: member

Additionally, maybe dropping the startup warning also makes sense. It’s arguably premature when there is no concrete plan to remove the option (the new wording could then be moved to the release notes).

ajtowns commented at 8:39 am on September 23, 2025: contributor

The current code is deprecated in the sense of being unmaintained

Why do you believe it is unmaintained? It is still tested, and there are still contributors who are willing to keep it operational.

luke-jr commented at 9:22 am on September 23, 2025: member

The entire change (#32406) needs to be reverted. Un-deprecating it doesn’t make any sense as long as it’s being sabotaged with new bugs. The default change is the big problem.

ryanofsky commented at 9:34 am on September 23, 2025: contributor

Code review ACK 451ba9ada41f687c0e4bb34d5925374a68a8f8a3

As a best practice, Bitcoin Core has avoided an option when the developers cannot articulate when they should be used.

I like this PR, and think ideally a followup could improve the documentation more to address this problem. I think the documentation could mention the previous default, and that it was changed to improve network efficiency and censorship resistance, but that there are practical and philosophical disagreements about how to deal with network abuse, and many node operators will choose to set a lower value and limit what they relay despite some costs. Would be good to keep code documentation short and link externally to an updated developer statement, or a markdown doc, or a wiki page that conveys the different views accurately and responsibly (e.g. focusing on technical and philosophical aspects and avoiding legal speculation.)

I could imagine developers who think having technically unnecessary options is “counterproductive” may also think documenting those options is counterproductive, but IMO we will waste a lot more time trying to take away options some people want, than acknowledging genuine differences of opinion, accepting some small technical overhead, and trying to provide the best tools and information we can to people using software we release.

I also understand that PRs improving the documentation will not satisfy people who want to revert to the previous default behavior or even remove the ability to configure it at all. But having the option at least gives people who favor restrictive relay policy a chance to positively advocate for their views, explain and demonstrate them, and convince other people of their benefits. To the extent both sides can step away from coercive measures and simply present the best case for their views, I think that is a good thing.

vasild approved

vasild commented at 10:10 am on September 23, 2025: contributor

ACK 451ba9ada41f687c0e4bb34d5925374a68a8f8a3

Thanks!

PS: I think this would better be included in 30.0

waketraindev commented at 10:14 am on September 23, 2025: none

Concept NACK

The peeps wanting to reject transactions with this option don’t want it.

And in general the extra pool is too small to “cache” a large number of transactions causing rejecting nodes to redownload already seen transactions.

Best to just remove the footgun

moonsettler commented at 12:04 pm on September 23, 2025: none

Those who fully want to embrace filtering should be looking for alternative software, rather than demand that Bitcoin Core implements it for them.

Keeping the option makes it a lot easier to maintain such software over time. There are more people who want to set it to non-default value today than ever before.

Kruwed commented at 1:35 pm on September 23, 2025: none

There are more people who want to set it to non-default value today than ever before.

This is a justification for why the deprecated options should be removed as quickly as possible, not a justification for making a footgun available to these people.

moonsettler commented at 1:38 pm on September 23, 2025: none

This is a justification for why the deprecated options should be removed as quickly as possible, not a justification for making a footgun available to these people.

It’s not any more a “footgun” than blocksonly. Which is not deprecated. That word should be reserved for situations that can result in loss of funds.

waketraindev commented at 1:40 pm on September 23, 2025: none

This is a justification for why the deprecated options should be removed as quickly as possible, not a justification for making a footgun available to these people.

It’s not any more a “footgun” than blocksonly. Which is not deprecated. That word should be reserved for situations that can result in loss of funds.

Blocks only doesn’t request transactions that after are denied only to be downloaded again when they are confirmed or have a child

moonsettler commented at 2:02 pm on September 23, 2025: none

Even if I conceded that it is a footgun (which I’m not) to set datacarriersize I would still prefer no “gun control”. Especially in a case where “self-harm” is the only real concern.

Kruwed commented at 2:13 pm on September 23, 2025: none

Even if I conceded that it is a footgun (which I’m not) to set datacarriersize I would still prefer no “gun control”. Especially in a case where “self-harm” is the only real concern.

The real concern is that the people wanting to set the datacarrier options are under the delusion that they can use it maliciously to censor others’ transactions. The self harm is not their main goal, it’s just a side effect.

edit: Can you steelman any legitimate use cases for these options that would justify reversing their deprecation status/future removal?

moonsettler commented at 2:28 pm on September 23, 2025: none

Can you steelman any legitimate use cases for these options that would justify reversing their deprecation status/future removal?

Idk about a steelman, but I think it was a mistake and correcting a mistake is preferable. There is clearly demand now for the setting whether you think it’s misguided or not. There is demand for software that ships with different defaults. I see no value in making the maintenance of such software harder and harder over time, when the alternative has no real cost.

l0rinc commented at 6:24 pm on September 23, 2025: contributor

I keep flipping between acking or nacking this change. I actually considered proposing something similar a few weeks ago but ultimately decided against it, so I understand the motivations here.

While we all want Bitcoin to succeed as the best form of money ever created, and we all understand that transactions need to generate sufficient fees to keep miners alive, I don’t see how deliberately misconfiguring our nodes to reject transactions that will likely be mined anyway helps achieve these goals. Adding options to deliberately mispredict acceptance is not a feature I am enthusiastic about.

We need exceptionally strong technical justifications for deviating from consensus rules. Every time we add filters to prohibit something that would otherwise be valid on-chain (simply because some of us personally dislike it), we’re narrowing the design space and potential use cases of Bitcoin. This is particularly concerning given that Bitcoin likely cannot survive long-term in its current state with consistently low mempool activity - we need transaction demand from wherever it comes. Things will settle over time, but “optimizing” for short-term consistency has too many unwanted consequences.

The role of relay policy should be descriptive, not prescriptive - we should aim to predict what will be mined, not try to influence what we think should be mined. In that context, adding logs, warnings, and deprecations to discourage people from using these options as makeshift censorship tools is actually part of our educational responsibility to users. We’re helping them understand that these settings, when misused, make their nodes less effective at their primary job while not achieving what they claim to use them for.

We do have legitimate cases where we limit certain transaction patterns for clear technical reasons, like the recently added 2500 sigop limit that prevents certain ugly DoS attacks. But expanding subjective filtering beyond these narrow technical necessities puts us on a dangerous slippery slope toward a centralized network. We already have networks that don’t contain garbage, but this is the only uncensorable network - let’s focus on making honest users happy instead of wanting to punish participants we happen to disagree with.

In summary, I don’t object to removing the deprecation warning in the next major release, so ACK for that aspect. However, I’m leaning towards a NACK for backporting this change to v30. The people who strongly oppose the v30 relay policy changes won’t be satisfied by merely removing a deprecation warning - they want the default behavior reverted entirely. Meanwhile, those who support the v30 changes will view this backport as caving to social pressure, applying cosmetics to silence opposition. It’s a lose-lose situation that satisfies no one while creating additional release management burden.

glozow commented at 7:45 pm on September 23, 2025: member

This is the 3rd PR since #32406’s merge discussing what the config options’ docs should say. Given how much collective effort this has required, I think we should be realistic about what this PR achieves.

I believe this PR tries to align the documentation with what users can expect. Usage of these options can cause the node to reject transactions that are likely to be mined, so the docs should discourage their use (to me, that means deprecated). However, it seems that removal in the near future is (1) unlikely and (2) has a few technical objections like #33453 (comment). I cannot predict the future, but I would guess it is more accurate to remove the sentence saying to expect their removal.

This PR does not pave a path towards changing the default again, commit the project to maintaining any particular configuration, or by itself give users a clearer understanding of the node’s datacarrier policies and what to expect. We still have lots of communication to do.

Fwiw I don’t think it makes sense to target this for v31 and not v30. AFAIK there is already a PR for rc2 (see #33424, #32275) and I personally don’t think it’s worth holding up the release for this PR. So the merge + backport + release notes changes need to happen very quickly for this to be incorporated.

00w1 commented at 8:25 pm on September 23, 2025: none

I just wanted to share the reason why this pull request is open and not closed by maintainers:

pinheadmz commented at 8:30 pm on September 23, 2025: member

@00w1 personal attacks are off topic and result in a ban re: moderation policy. Technical and conceptual discussion is the only type of comment that is allowed.

darosior commented at 9:26 pm on September 23, 2025: member

AFAIK there is already a PR for rc2 (see #33424, #32275) and I personally don’t think it’s worth holding up the release for this PR.

+1. I ACK’d the change because i believe it is technically correct to say we won’t be removing the option anytime soon, but i don’t think a small documentation change is worth holding up the release for.

fanquake commented at 10:45 pm on September 23, 2025: member

AFAIK there is already a PR for rc2 (see #33424, #32275)

Given it’s been 2 weeks since rc1, and there’s going to be an rc3 in either case, I’m going to tag an rc2 shortly, and when it’s decided what to do here, it could be incorported into rc3.

hMsats commented at 9:04 am on September 24, 2025: none

I’ve used -datacarrier and -datacarriersize in the past but have removed them based on all the recent discussions (especially Gregory Maxwell on Reddit) and am in favor of the recent default settings in Bitcoin Core 30.0. However, I strongly oppose removing these options which so many people find useful to express their disgust for non-financial data in the block chain and therefore refuse to relay them. I also believe this documentation change is worth holding up the release for.

Concept ACK

Kruwed commented at 9:11 am on September 24, 2025: none

However, I strongly oppose removing these options which so many people find useful to express their disgust for non-financial data in the block chain and therefore refuse to relay them.

“Expressing disgust” is not a reasonable use case. Why do you think that Bitcoin Core should cater towards emotional outbursts?

bitschmidty commented at 10:10 am on September 24, 2025: none

This is the 3rd PR since #32406’s merge discussing what the config options’ docs should say.

Thank you to all who have reviewed and provided thoughtful feedback on this PR.

I believe this PR tries to align the documentation with what users can expect. Usage of these options can cause the node to reject transactions that are likely to be mined, so the docs should discourage their use (to me, that means deprecated). However, it seems that removal in the near future is (1) unlikely and (2) has a few technical objections like #33453 (comment). I cannot predict the future, but I would guess it is more accurate to remove the sentence saying to expect their removal.

IIUC, there seems to be support for removing the “expected to be removed in a future version” sentence, and leaving the options as deprecated. The sentence removal addresses ambiguity around availability of the option in the near and medium term, and the deprecated status of the option indicates only discouragement of using the options. This reflects the reality of the situation IMHO. Tangibly, that would mean closing this PR and a new one to change the sentence as outlined by @polespinasa in https://github.com/bitcoin/bitcoin/pull/33453/files#r2369422871 ? I am happy to do that, although someone else may be able to do it more expeditiously. Let me know @glozow.

Given the widespread interest in the option by Bitcoin Core users, Id suggest any future work around this option, including any plans around its removal, include a clear timeline. I believe thats already customary in the project, but wanted to reiterate.

This PR does not pave a path towards changing the default again, commit the project to maintaining any particular configuration, or by itself give users a clearer understanding of the node’s datacarrier policies and what to expect. We still have lots of communication to do.

Agreed on communication and that is downstream from any related changes here. Happy to help on this. I think the “deprecated but not currently scheduled for removal” will be a near term confusion for Bitcoin Core users, should the suggestion you made above be accepted. But again, mostly separate work from this repository.

Fwiw I don’t think it makes sense to target this for v31 and not v30. AFAIK there is already a PR for rc2 (see #33424, #32275) and I personally don’t think it’s worth holding up the release for this PR. So the merge + backport + release notes changes need to happen very quickly for this to be incorporated.

I defer to you and the other maintainers on this. I think merging a PR with some version of the wording suggestion above to the codebase, regardless of whether it is released in v30 or v31 “should” have the desired clarification.

theDavidCoen commented at 11:06 am on September 24, 2025: none

This is the 3rd PR since #32406’s merge discussing what the config options’ docs should say.

Thank you to all who have reviewed and provided thoughtful feedback on this PR.

I believe this PR tries to align the documentation with what users can expect. Usage of these options can cause the node to reject transactions that are likely to be mined, so the docs should discourage their use (to me, that means deprecated). However, it seems that removal in the near future is (1) unlikely and (2) has a few technical objections like #33453 (comment). I cannot predict the future, but I would guess it is more accurate to remove the sentence saying to expect their removal.

IIUC, there seems to be support for removing the “expected to be removed in a future version” sentence, and leaving the options as deprecated. The sentence removal addresses ambiguity around availability of the option in the near and medium term, and the deprecated status of the option indicates only discouragement of using the options. This reflects the reality of the situation IMHO. Tangibly, that would mean closing this PR and a new one to change the sentence as outlined by @polespinasa in https://github.com/bitcoin/bitcoin/pull/33453/files#r2369422871 ? I am happy to do that, although someone else may be able to do it more expeditiously. Let me know @glozow.

Given the widespread interest in the option by Bitcoin Core users, Id suggest any future work around this option, including any plans around its removal, include a clear timeline. I believe thats already customary in the project, but wanted to reiterate.

This PR does not pave a path towards changing the default again, commit the project to maintaining any particular configuration, or by itself give users a clearer understanding of the node’s datacarrier policies and what to expect. We still have lots of communication to do.

Agreed on communication and that is downstream from any related changes here. Happy to help on this. I think the “deprecated but not currently scheduled for removal” will be a near term confusion for Bitcoin Core users, should the suggestion you made above be accepted. But again, mostly separate work from this repository.

Fwiw I don’t think it makes sense to target this for v31 and not v30. AFAIK there is already a PR for rc2 (see #33424, #32275) and I personally don’t think it’s worth holding up the release for this PR. So the merge + backport + release notes changes need to happen very quickly for this to be incorporated.

I defer to you and the other maintainers on this. I think merging a PR with some version of the wording suggestion above to the codebase, regardless of whether it is released in v30 or v31 “should” have the desired clarification.

“deprecated but not currently scheduled for removal” makes no sense to me from a user point of view.. Also, suggesting that the use is discouraged but without providing clear communication is wrong imo, considering also that, as @ajtowns suggested here #33453 (comment) , with compact blocks the effects of setting datacarriersize or disabling datacarrier might not be particularly significant. #33453 (comment)

Why don’t you simply merge the PR as it is, so we can have it in v30? When / if there will be a plan to actually deprecate those options with clear communication from the proponents, we could simply change the description again to match the plan.

ryanofsky commented at 11:13 am on September 24, 2025: contributor

Tangibly, that would mean closing this PR

FWIW, I like the current PR more than these other ideas. I see these options as basically the same as other options. Not particularly dangerous, not particularly interesting, likely to be kept if used and there are contributors willing to maintain them, and likely to be removed if not used or they impose significant costs. I think having a warning which draws special attention to these options just amps up partisans on both sides and does not help the project move forward.

bitschmidty commented at 12:56 pm on September 24, 2025: none

“deprecated but not currently scheduled for removal” makes no sense to me from a user point of view

I can understand where youre coming from. Confusion around this is partly due to different definitions of deprecated. Most include ‘discouraged for use’, yet some also add something like ‘slated for future removal’. Two separate considerations in one single flag. So can end up to some as a sort of Schrödinger’s deprecation.

marcofleon commented at 3:31 pm on September 24, 2025: contributor

ACK 451ba9ada41f687c0e4bb34d5925374a68a8f8a3

I think this warning makes sense to remove for v30 if there’s not yet a clear timeline for deprecation. I don’t think the wording matters too much for now, and can be decided on later along with a deprecation plan and better documentation wrt this setting.

Could be good to set various arbitrary values on some monitoring nodes and see what the impacts are (potentially more stale blocks?). Ultimately, if users, miners included, want to set this to a specific value, they will.

IdotMaster1 commented at 5:42 pm on September 24, 2025: none

Concept ACK, but turn the default OP_RETURN back to normal.

alfredopalhares commented at 10:02 pm on September 24, 2025: none

Concept ACK

Come to your senses devs, the users have spoken.

waketraindev commented at 5:10 am on September 25, 2025: none

This PR is more of an example of the brink foundation leveraging and rallying their members to get a nonsensical help text change pushed and backported for V30.

The change itself is senseless and should not be something accepted in any kind of engineering.

Don’t know who this attempts to please but it’s clearly group think and group push from Brink.

-1 and concept nack and sure minimize this

glozow commented at 2:31 pm on September 26, 2025: member

Tangibly, that would mean closing this PR and a new one to change the sentence Let me know @glozow.

It looks like you have conceptual support from folks to change the string, but strong preferences for one of two approaches. Your call whether you want to change your PR, leave it as is, open a new one, etc. Not everyone will agree.

docs: Undeprecate datacarrier and datacarriersize configuration options #33453

Code Coverage & Benchmarks

Reviews