Why was -datacarriersize redefined in 2022, and why was the 2023 proposal to exp...

In 2014, Bitcoin Core introduced OP_RETURN with an 80-byte default cap, enforced through the -datacarriersize option. This was intended to allow small data (such as proofs or certificates) while discouraging spam.

After Taproot was activated in 2021, people began embedding large amounts of data in witness fields. These inscriptions bypassed the OP_RETURN cap and were not affected by -datacarriersize.

In 2022, the definition of -datacarriersize was changed so it applied only to raw OP_RETURN outputs. In 2023, a pull request to expand its scope to cover witness data was closed without merging due to controversy and lack of consensus.

In Bitcoin Core v30 (2025), the OP_RETURN cap has been removed, multiple OP_RETURN outputs are allowed, and -datacarriersize is deprecated.

My questions:

1. Why was -datacarriersize narrowed to OP_RETURN only in 2022 instead of expanded to cover witness-based data carrying?
2. What were the main reasons for not merging the 2023 pull request that proposed expanding it?
3. How do the upcoming v30 changes align with the original anti-spam intent of -datacarriersize and OP_RETURN?
4. What guidance would you give to node operators who want stricter limits on data-carrying transactions?

1. 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.

2. 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.

3. 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.

4. 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 by no means means you can't disagree with this.