Looking At The OP_RETURN Debate In Bitcoin

Have you ever entered a place and felt like you were out of your depth and didn’t belong there? That’s how I feel in regard to the ongoing OP_RETURN “debate” pitting Bitcoin Core node runners against Bitcoin Knots runners.

Why did I put debate in quotations? I’ll explain that later.

But first, I want to provide some quick background info: I fell down the Bitcoin rabbit hole in February of 2024.

I have an obsessive personality and love to learn, read and research. Upon finding the rabbit hole, I turned gravity to 9001, equipped my hands with diamond bits, and got to work digging deeper as intensely as possible. I don’t have a lot of longevity in the Bitcoin space, but I’d estimate around 1500 hours spent since February 2024 down the rabbit hole.

Great, now you know a bit about me.

So, what does a relatively new but passionate, informed and educated Bitcoiner like myself think of the ongoing OP_RETURN chaos?

I find it messy, confusing, unproductive, and the overall environment toxic.

In general, the technical side of Bitcoin can be overwhelming and confusing. Focusing in on a smaller and particular piece such as OP_RETURN is even more so as it blends the technical with the ideological.

Looking At Pro-Knots

From what I see, the people who are pro-Knots oppose Bitcoin Core and the increase of the OP_RETURN limit from 80-bytes to 100,000-bytes for 2 primary reasons:

• not wanting to relay spam across the network and have it in their node’s mempool

• wanting to have the freedom to choose how they run their node and the freedom to set filters

The first point is important and valid from a policy standpoint, and users should have the freedom to choose how their node functions.

The first point also seems crucial from a technical standpoint.

However, in reality, setting a lower limit on OP_RETURN doesn’t really matter for stopping non-financial metadata from being put on the blockchain.

Technical Look At OP_RETURN

OP_RETURN was introduced to Bitcoin Core in 2014 in order to stop non-financial data from bloating the UTXO set, as people were storing data on the blockchain as UTXOs.

OP_RETURN transaction outputs are provably unspendable, which means they are not a UTXO. As such, an OP_RETURN transaction does not pollute the UTXO set nor make it more memory intensive to run a node. This metadata will contribute to block size though, and will become part of the blockchain, increasing the overall storage size of the blockchain.

I don’t like that spammy metadata can take valuable block space away from financial transactions.

However, OP_RETURN doesn’t and can’t stop this metadata from entering blocks, 80-byte limit or not. Transactions can be sent directly to miners for inclusion into blocks, bypassing filters and mempools.

Metadata can also be placed into blocks using Taproot. Metadata attached to coins via Taproot also needs to be relayed by nodes, it cannot be filtered out. In the case of Taproot (and really, in general), is that the metadata put into a block is limited to the hard-cap of block size.

In general, the true limit is the hard-cap block size limit. OP_RETURN or not, metadata can always make its way into blocks, if the price is willing to be paid.

Back To Knots

With the technical talk out of the way, I do agree with the pro-Knots community that people should have the freedom to choose how they run their nodes.

While running a node with spam filters won’t achieve the end goal of spam in blocks, it’s important to have the freedom of choice, and the freedom of expression. In this case, the expression of running your node the way you want to.

I also agree with the sentiment that block space should be for financial data, and that relaying non-financial transactions goes against this ethos. In this case, maintaining a lower limit on OP_RETURN for your node is purely a moral undertaking.

The whole OP_RETURN saga has brought attention to the fact that the vast majority of the node network is running Bitcoin Core and that more options for node runners are needed. Hopefully, this pushes people to develop new node software, as well as bring maintainers to Knots.

Looking At Pro-Core

When this debate came to be, I was uninformed on the matter, and my initial reaction and view was that Core seemed to be acting irrationally.

I had also seen hostility (and continue to see) from some Core developers towards people who opposed the change, which I don’t think is necessary nor productive.

There's a lot of flaming occurring, which I don't see the need for. Why insult others who want to do something different if you're confident your way of doing things is best and will continue to dominate the market? Seems like a waste of energy. Though, to each their own.

Anyway, after doing my due diligence and gaining a better understanding of the technical side, increasing the OP_RETURN limit seems logical.

What I don’t understand, however, is why Core has marked the OP_RETURN filter as deprecated.

My intuition tells me it’s because the limit is technically irrelevant, so why include it? Another part of me thinks the reasoning could also be because Core operates under the assumption that they know what’s best (which, yeah, everyone does) and they don’t think the limit is necessary.

I see a lot of people on Nostr declaring that Core has gone rogue, with some of the developers being corrupted and having incentives to remove the limit beyond what’s best for Bitcoin.

I’m out of my depth and over my head when it comes to those takes, so I don’t have anything to say about them.

Overall Observations

Looking at the whole, it seems that the entire OP_RETURN saga has long departed from being a debate and is now just a massive heap of noise, insults and talking past each other.

It seems to me that there is no debate to be had but rather pro-Knots calling Core the devil and the destroyers of Bitcoin, and Core thinking pro-Knots don’t understand anything and shouldn’t have a say in the matter.

I don’t think it’s helpful for newer Bitcoiners like me to get involved, as I have neither the time in the space nor the proof-of-work to carry weight or offer a legitimate take. 

I’ll write about it here because this is my space to do what I want, but I don’t engage in the arguments on Nostr.

I don’t think it’s helpful to weigh in and argue, and that it just adds additional noise to an already ravaged landscape.