- Why was -datacarriersize narrowed to OP_RETURN only in 2022 instead of expanded to cover witness-based data carrying?
To the best of my knowledge, it was never narrowed in meaning. It refered to a specific type of output (scriptPubKey starting with OP_RETURN and a single push) when it was introduced, and with minor modifications (total size rather than push size, and aggregating over multiple outputs), still does today in Bitcoin Core v30.
- What were the main reasons for not merging the 2023 pull request that proposed expanding it?
I personally believe node policy isn’t an appropriate approach for morally judging quality of transactions.
In 2022 I considered the -datacarriersize a legacy from a different period in time, when very different concerns plagued Bitcoin development: blocks weren’t full, and it was worth discouraging the development of solutions to take advantage of unused block space; by 2022, when blocks were regularly full, due to organic growth, this concern simply didn’t exist anymore, and the prevention of unbounded resource growth on node operators had been taken over by the more appropriate technique: consensus rules (specifically, the block size, and later block weight limit).
In 2022, I would have been of the opinion to keep the status quo, as long as the old default policy rule didn’t seem harmful. In 2025, it is apparent to me that it is widely ignored anyway, and thus does more harm than good, and thus I’m of the opinion that node operators are better off not enforcing such a rule.
- How do the upcoming v30 changes align with the original anti-spam intent of -datacarriersize and OP_RETURN?
They do not. I believe those are outdated notions. The market is now in a better position to judge how worthwhile transactions are than developers or operators.
- What guidance would you give to node operators who want stricter limits on data-carrying transactions?
I would advise you to try to understand the technical reasons for why Bitcoin Core developers believe it is not beneficial for you to try to enforce policy rules that are regularly ignored anyway.
If those reasons do not convince you, I sincerely hope you modify the settings to what you believe is best for you, or run other software. While I think those are inferior options that primarily hurt yourself, you are not required to follow my advice, and you shouldn’t feel an obligation to run code you believe is harmful.
I think as developers we have a responsibility to create software that serves our users best, which includes not providing options for things for which my advice would be “never use this”. However, that in no means you can’t disagree with this.
