I've been asking a lot of questions here on SN about the controversy of a recent pull request made on Bitcoin Core, so here is a look at my best representation of both sides of the aisle.
Stephan Livera on his x account gives this explanation of Core's proposed
op_return changes, using the following analogy:Picture a city with a strict limit on how much graffiti can be painted on a designated public art wall. Because the space is so restricted, some artists start spray-painting their work on nearby buildings, creating permanent damage that’s costly to clean. To reduce this, the city decides to expand the art wall, allowing more graffiti in a space designed for it, where it can be easily painted over or removed without harming the city’s infrastructure.
The city doesn’t support unchecked graffiti, but by expanding the art wall, it redirects the activity to a less harmful place. Similarly, removing OP_RETURN limits in Bitcoin Core channels spammer's data into pruneable, provably unspendable outputs, minimizing pollution in the UTXO set without endorsing spam itself.
This is a fair and concise way to put it, except that it uses 'art' in a way that may contribute to some misunderstandings for reasons explained below. Furthermore, while Core may not be 'endorsing spam' in the way of jpegs, they do seem to be fairly open and vocal about validating Citrea's harships (#968877).
Core
One issue that motivates the change to
op_return limits is UTXO bloat, since the unprunable UTXO sets being used in lieu of the restrictive op_return outputs (i.e. op_false and op_if or 'taproot inscriptions') are a burden to noderunners. All UTXOs need to be included when a node syncs to the network, and a bloated UTXO set, due to non-monetary uses of block space, contributes to the very large initial block download (~1TB). You can see from the graph (below) that close to a majority of utxos are unspendable, or dust (<1000k sats), which is a symptom of non-transactional use-cases of bitcoin block space.Since larger (>143 btye) data becomes uneconomical when using
op_return compared to the other means of storing non-transactional data on Bitcoin (taproot witness scripts, aka inscriptions), then the steelman case for Core would be that eventually the Ordinals, Runes and other 'spam' using Bitcoin as a data anchor eventually get priced-out and datacarrier storage starts to only get used for the 'interesting' projects (like Citrea's) that buy block space for non-transactional reasons. Dropping the op_return configuration option will make it easier for these projects to include their data in mempools that use Core.
Knots
The other side will say that Core is bending the knee to (or otherwise 'embracing') a private company that is interested in anchoring data in Bitcoin nodes. And those that find this objectionable will run Knots, which ostensibly is against dropping the
op_return datacarrier config option.They also raise cultural objections to being permissive to projects that use bitcoin for anything except its monetary properties.
Concerning Mining Centralization
My understanding based on some digging I've been doing is that the Knots mining pools will only be able to restrict what gets into their mempool, but will not (pun unintended) determine what kind of transactions other miners pick up and include in blocks. The reason for this is that all miners have the economic incentive to include transactions with the highest paying fees and will seek out private mempools when it is in their economic best interest to do so. This change would allow smaller miners running Core to profit by the non-transactional
op_return data.The claim is, larger mining pools are already finding larger
op_returns in 'private mempools' that come from non-Core implementstions of Bitcoin, and this gives them a leg up on smaller mining pools. The latter have less means (manpower, resources) to adapt to this and face the threat of getting priced out. It would follow that Core's push for dropping the op_return datacarrier configuration will allow all mining pools running Core to profit from the non-transactional data that would then be permitted in their mempools.It would follow that miners running on Knots, if they are excluding these
op_return outputs will not allow these fee-paying outputs into their mempools. The blocks they mine, therefore, will also exclude these fee-paying outputs. However, the op_return data will be stored on their nodes, even if they exclude it from their mempools, since other miners (i.e. those running less restrictive policy
implementstions) will be continue to include it into blocks.Conclusion
Miners have a choice as to which implementation of Bitcoin they will run. Core, the most pervasive, wants to make changes so that miners who choose them will profit from the non-transactional use-cases of block space. Knots will allow miners the config option to exclude this kind of data from their mempools, but they still have no power to stop others from mining blocks with this data.
Ordinals, Runes and other large data files, are not stored in
op_return outputs, but in taproot witness scripts. Even with the propsed change, if their data exceeds 143 bytes, op_return doesn't seem to be a viable option for them. Relaxing op_return limits should incentivize small data storage use-cases, such as Citrea's, to take up fewer UTXOs in block space and curb the amount of unprunable data that node runners need to download and store on their machines.
OP_RETURN(as you've said), because witness discounts make other opcodes cheaper.OP_RETURNlimits eased?' the response is, 'well, they probably won't but they should (especially Citrea), because of UTXO bloat.' (see Sjor's latest message in mailing list); when this was asked of Todd, he was very explicit in citing the needs of Citrea (#968877)