Remove redundant -datacarrier option

[vostrnad]

The -datacarrier option is redundant, as disabling the relay and mining of transactions creating OP_RETURN outputs can be accomplished by setting -datacarriersize=0. Its removal was supported by several people in the discussion of #27261 (e.g. #27261 (comment), #27261 (comment)) and implemented in #28130, but that PR was rejected due to making other, more controversial changes.

Being a breaking change, this will of course need a release note. I'd recommend anyone concerned that they might accidentally start relaying and mining OP_RETURN transactions to proactively set -datacarriersize=0 now.

[DrahtBot]

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

Code Coverage

For detailed information about the code coverage, see the test coverage report.

Reviews

See the guideline for information on the review process.

Type	Reviewers
Concept NACK	luke-jr

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

Conflicts

Reviewers, this pull request conflicts with the following ones:

• #29520 (add -limitdummyscriptdatasize option by Retropex)
• #29309 (Add a -permitbarepubkey option by vostrnad)
• #29086 (refactor: Simply include CTxMemPool::Options in CTxMemPool directly rather than duplicating definition by luke-jr)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

[maflcko]

Being a breaking change, this will of course need a release note. I'd recommend anyone concerned that they might accidentally start relaying and mining OP_RETURN transactions to proactively set -datacarriersize=0 now.

Not sure about saving 4 lines of code for a breaking change. There are other redundant options such as -signet and -chain=signet, so I don't see why this one should be removed?

(Edit: I know I changed my opinion on this, compared to #27261 (comment), but I think it is clear that some users may be using this option and saving a few lines of code may not be worth it in the end, considering this is a breaking change. However, flattening the optional can still be done, because it is not a breaking change and comes with most of the benefits of what this pull is trying to achieve?)

[vostrnad]

The main benefit really is not having two options with similar names that can do the same thing. As you yourself said in the linked comment:

Having two ways to achieve the same is just confusing and can lead to issues.

Seems to me a one-time breaking change (with very little impact) is preferred to keeping the confusing set of options forever.

[DrahtBot]

🚧 At least one of the CI tasks failed. Make sure to run all tests locally, according to the
documentation.

Possibly this is due to a silent merge conflict (the changes in this pull request being
incompatible with the current code in the target branch). If so, make sure to rebase on the latest
commit of the target branch.

Leave a comment here, if you need help tracking down a confusing failure.

_{Debug: https://github.com/bitcoin/bitcoin/runs/24160281628}

[vostrnad]

Another difference from -chain is that it is possible to set both -datacarrier=0 and a positive -datacarriersize without so much as a warning (-chain immediately crashes when in conflict with another option).

Here are also a few examples of users confused about the two options:

https://twitter.com/FieldNas/status/1782498776671768807
https://twitter.com/betoche1984/status/1782452190063337681

[maflcko]

Another difference from -chain is that it is possible to set both -datacarrier=0 and a positive -datacarriersize without so much as a warning (-chain immediately crashes when in conflict with another option).

Right. However, after this pull request, the same is true if -datacarrier=0 is set in a config file. (See #15021). That is, it is possible that this is silently ignored for a user that has it intentionally set.

Here are also a few examples of users confused about the two options:

It looks like those are examples of users using the options, so their configs will be broken. If the docs are hard to understand, an alternative would be to improve the docs.

I am happy to review the optional flattening, if you split it up into another pull request, but this pull request as-is will probably have a hard time finding reviewers.

[laanwj]

This particular option was introduced 10 years ago (in e44fea5, v0.10.0 apparently). FWIW i think we would need a stronger reason to remove it than a bit of redundancy.

[maflcko]

Are you still working on this?

[vostrnad]

What is there to work on? CI passes and there are no merge conflicts. I know you suggested alternative approaches, but those can be implemented in different PRs if this one gets closed.

[luke-jr]

It seems there is a benefit to redundant options, in that we had to do the whole prune-prev thing to preserve the disabled size in the GUI (which is actually kindof weird, since disabling pruning is a pretty big change).

But the confusion isn't nothing either.

Inclined to leave it alone since it's been this way for years. = Weak Concept NACK.