momotahmasbi on Nostr: Here’s a more detailed explanation of why I’ve changed my view and now support ...

Here’s a more detailed explanation of why I’ve changed my view and now support removing the OP_RETURN limit.

In a private chat with provoost (npub1s6z…wk4c) at the Bitcoin FilmFest , I asked if using Knots instead of Core poses any danger. He said "danger" is a strong word, but explained that when a new block is propagated, Knots may not recognize some transactions because its mempool rejected them due to default policy. As a result, there's latency—you have to fetch missing transactions from peers before you can mine the next block.

This means a miner who filters spam is slower to react and loses edge to miners who don’t. So spam ends up on-chain anyway, and only large miners benefit—whether through out-of-band payments or simply accepting high-fee transactions with bigger OP_RETURNs.

Even if most of the network runs Knots, one big miner is enough to mine such transactions. And not all OP_RETURN use is spam. Ocean, for example, used to block coinjoin transactions due to their OP_RETURN usage. I wouldn’t want to run a node that censors legitimate use cases.

When I supported the OP_RETURN limit, I even asked Sparrow to add Knots public nodes (https://github.com/sparrowwallet/sparrow/issues/1716#issuecomment-2872672114). craigraw (npub1hea…g9v2) kindly responded that Knots doesn’t support BIP47, so it’d break features for users. That was another practical downside.

Also, if spam is destined for the chain, I’d rather mine it and earn the higher fees. I don’t care if someone’s NFT or bridge fails —I’m paid in sats. Let the fee market and block size be the filter. I’m not here to make economic judgments for others.

One concern I had was whether a higher OP_RETURN limit enables malicious code. But if attackers want to embed such arbitrary data required for the attack, they can use bare multisig to do so anyway. Limiting OP_RETURN won’t stop that.

I asked Kloaec (npub1c2d…kxar) whether we could disable bare multisig. He said it would require censoring pubkeys, raising the question: who decides what’s censored? A slippery slope. In that light, the cure is worse than the poison.

In my thinking, if a real existential threat emerges (for example the ability to crash the nodes by embedding malicious code as arbitrary data), then and only then a limit on OP_RETURN and bare multisig can be justified and that has to be done on the protocl level, not on the policy leve.

But if the side-effect of saving arbitrary data is higher transaction fees for a short time, I'm happy to collect those sats!

As history shows, crazes like Inscriptions fade. We’re already back to 1–3 sats/vByte. The high-fee spam phase is behind us.

And despite popular belief: mempools always clear. That’s a hill I’m willing to die on.