The trees obscure the forest

A summary:

Ways to insert data:

1) OP_RETURN outputs (“nulldata”)

You put the bytes in a non-spendable output (scriptPubKey starting with OP_RETURN).

Advantages: does not widen the UTXO set; easy to detect/filter; highly visible in explorers.

2) In the witness (SegWit/Taproot) — e.g., inscriptions

The content is serialized within an unexecuted conditional (“envelope” OP_FALSE OP_IF ... OP_ENDIF).

Advantages: witness bytes “weigh 1 WU/byte” (≈¼ of a vbyte), so it is much cheaper per byte than non-witness/OP_RETURN.

Disadvantages: pruned nodes may discard old witnesses (you don't rebuild them locally).

3) Data in spendable scriptPubKey (“fake” multisig, etc.)

Like the famous case in the whitepaper (2013): bytes distributed across 947 outputs within the scriptPubKey.

Problem: if those outputs remain unspent, the bytes live in the UTXO set ⇒ unspendable until they are spent. This is the least recommended approach today.

4) Coinbase (miner's transaction input script)

Miners can put text/tags in the coinbase scriptSig (in addition to the mandatory height per BIP34).

Useful for messages or pool identifiers; not a general approach for large files.

5) Commitments via Taproot key tweak

You don't store the blob, you cryptographically commit to it (e.g., to its hash) by “putting” it in the Taproot key tweak.

Advantages: cheap and clean (no bulky data on-chain), revealable whenever you want.

Use: protocols/assets on Bitcoin (Taproot Assets, etc.).

Now come the uncomfortable questions.

Do you think spammers will use op_return if it is four times more expensive than witness? Do you think spammers will act in good faith as Core assumes? Since when do spammers act in good faith?

And here's the key: Core has given up on fighting spam, it doesn't run filters on Witness, so why run any kind of limit on op_return?

OP_RETURN is a general policy change. OP_RETURN is just one more thing, in the same way that Knots comes with permitbaremultisig disabled and Core has it enabled.

Currently, Knots filters more than 98% of transactions, while Core no longer filters anything.

Neither violates the consensus rules; they simply have different policies.

So the final decision rests in the hands of the users, knowing that the filters do work, although their effectiveness depends on the percentage of nodes that run them. The more nodes, the more effective they are, but even with 20% of nodes running the filters, as is currently the case, a percentage of spam transactions are not mined.

That said, not running filters and removing the op_return limit opens up new attack vectors.

Perhaps the biggest problem is the campaign of lies that the entire core environment has orchestrated, and obviously one has to wonder who benefits from this.

Did the filters do any harm? Of course, now they will come up with the excuse of compact blocks and mempool homogenization.