Good question. I think I have covered that topic here already: #971342

It seems to me that it is more of a continuation of the disconnect caused by the project’s approach to and communication around Inscriptions than about the current issue at hand.

A lot of Bitcoiners have strong emotions about Bitcoin’s sole use for payments and feel that their concerns about data transaction were not sufficiently considered by Bitcoin Core contributors in the past couple years. Bitcoin Core contributors need to do a better job of participating in the community conversation to regain some of the lost trust, although the disagreement seems somewhat inevitable due to the gap between idealistic stances and the trade-offs that present themselves in practice.

I think all three of these are already covered here:

Why is the 80-byte OP_RETURN limit being removed, and what are the main risks and benefits of this change?

#971287, #971299

Will node operators still be able to set their own OP_RETURN size limits, or is the configuration option also being removed?

#971285

How does removing the OP_RETURN limit impact UTXO set bloat and network health compared to current workarounds?

#971357, #973248

I don’t think there was any urgency attached to this pull request until it blew up on social media. The next Bitcoin Core release is planned for October. Whether the change were to get merged in May or in August, it wouldn’t come out before October.

The sense of urgency was generated by opponents claiming that immediate action was necessary to save Bitcoin.

Bitcoin Improvement Proposals are specifications that describe a new concept, protocol feature, or standard that its authors recommend for adoption to the Bitcoin community. The topic must be relevant to multiple software projects.

Usually, mempool policy defaults are selected by projects without coordination, unless they are picked coordinate interaction with other projects (see e.g. BIP 431). There are multiple node implementations that differ in mempool policy in a number of different ways. As such, a mempool policy change in Bitcoin Core might be discussed on the mailing list, but lower impact changes might even just be decided at the project level.

BTW, some BIP Editors have contended that mempool policy is generally not BIPable.

:)

Let's not let Murch's work be in vain! Having a common set of facts will only benefit our understanding of the truth and lead to more meaningful conversations. Please share individual links to these threads, where applicable, to help clear up misinformation.

Dunno, it seems to get a few clicks.

A configuration makes sense when you can give a recommendation in which case it should be used and what values should be set. In this case, it makes sense to keep the configuration option at least for some time because it had existed and it would feel like taking something away, but if I’m honest, I don’t think I would ever recommend using it.

1. The main reason for the PR (in my opinion) is that it achieves harm reduction. Similar to how local governments might provide a drug addict clean needles, giving data embedders the option to utilize OP_RETURN is better than having them stuff witnesses. This is because (1) OP_RETURN is provably unspendable and does not bloat the UTXO set and (2) does not leave dust outputs behind like witness stuffing (i.e. inscriptions). Secondly, removing the limit reduces the need for nodes to need to pull transactions at block-sync time because the next block will be made up of transactions already in your local mempool. Finally, because mining pools don't care about standardness, relay should not either. I think it was gmax that said what is relayed should closely match what is mined.
2. IBD solutions already exist today. I forgot the name of one of them but it essentially has UTXO set hints that allow you to parallelize the process of sync. This is the main reason why IBD is slow today, and if you setup a node from scratch you'll see that CPU/networking are not utilized to their full potential. Libbitcoin is another example of how parallelizing can make it such that your network speed is the bottleneck for sync.
3. If we do nothing then block updates are slightly worse for everyone as mentioned before. Additionally, if your code relies on mempool estimates for fees it will have a less accurate prediction of what to use for a fee rate. It would be similar to someone running the ordisrespector patch. Even if the transactions they don't like are not in their own mempool, they will need to store it anyway when a block is mined that contains them. Finally, if we do nothing there is a very real likelihood that a third party may resort to VERY BAD data storage methods like Bitcoin Stamps which utilize fake pubkeys and stuff data in them. These are much worse because they permanently bloat the UTXO set with each transaction created.

Bitcoin Core currently considers a single OP_RETURN output with 80 bytes data standard. Above 143 bytes, it’s cheaper to use inscriptions.

There may be some use case that needs multiple OP_RETURN outputs which previously used several transactions instead of doing a single transaction. If they would have created let’s say three transactions instead of a single transaction with three OP_RETURN outputs, they can achieve the same thing with less blockspace, so they pay a bit less, but they also demand less blockspace.

It might open up the avenue for some people creating larger OP_RETURNs that wouldn’t have bothered to do so if it were non-standard even though they could have just submitted it to Mara’s Slipstream before.

Overall, I think the novelty will wear off, and in the long run, valuable payment transactions will price out frivolous data transactions. We cannot really prevent data transactions that are very valuable to their senders either way.

Murch for president.

Hah, thanks for your support. I’m not sure I’d be the right guy, I’d feel bad golfing so much.

That’s fair. Instead of referring to transactions that fail Bitcoin Core’s mempool policy as non-standard, we should really be talking about "transactions that are [not] accepted by Bitcoin Core’s mempool policy defaults". It’s a bit of a mouthful, though.

Is it true that this type of update could affect Bitcoin's decentralization?

If there are transactions that regularly get mined but do not get relayed, we are incentivizing the users that are invested in such transactions to run less strict mempool policies and mining pools to build out tooling for direct submissions. The largest mining pools have the most resources to build out such tooling and are most likely to get direct submissions. Our choice is to let the largest mining pools benefit disproportionally or to make these transaction fees available to any node that wants to build a block template. In so far, yes, this change could slightly improve decentralization by mitigating some centralization pressure. Other than that, I don’t see how it would affect decentralization, and especially claims that it would have a negative effect seem to be based in hyperbole.

You appear to make several unstated assumptions. At least you seem to think that dropping the OP_RETURN limit will increase the total of OP_RETURN bytes added to the blockchain, that additional OP_RETURN bytes will increase the overall blockchain size, and that additional OP_RETURN data increases the cost for processing the blockchain.

1. OP_RETURN data is cheap to validate, because it does not contain any signature operations.
2. OP_RETURN data is not discounted, therefore an increased amount of OP_RETURN data probably displaces some witness data and would lead to overall smaller blocks.

I will grant that dropping the limit might increase the future OP_RETURN use, but it is not obvious to me that it would increase it beyond what would otherwise be embedded per inscriptions or fake pubkeys or fake pubkey hashes.

There are numerous off-chain solutions for arbitrary data storage that don't burden the Bitcoin network, including sidechains, layer 2 solutions, and purpose-built data storage blockchains. The proposal doesn't sufficiently explore why these alternatives are inadequate.

Storing data off-chain does not fulfill the criteria of on-chain data availability, so while it were preferable that data not be stored on-chain, it’s clearly not a replacement if on-chain data availability is a design goal.

Absolutely. Bitcoin Core does not have an auto-update feature, because the users should always consciously choose which rules they want to enforce.

I would recommend running a maintained version though, if your node is part of any wallet infrastructure. Even so, you can run one of the two latest major branches.

Other mempool policies are targeting DoS issues, detrimental use, and protect upgrade hooks. The OP_RETURN limits are the last obviously paternalistic, "we’d rather you don’t use Bitcoin for this thing that some people want to use it for" rules. I don’t anticipate that this is just the start of other mempool policies being removed.

Generally, a configuration option should be provided when one can provide recommendations when the configuration option should be used and how it should be adjusted. Historically, it looks like the vast majority of Bitcoin Core nodes use the default configuration. When at least about 10% of nodes accept a transaction, it propagates somewhat reliably to all nodes in the network that accept them.

This means that if the default configuration for the OP_RETURN limit were raised or removed altogether, such transactions would soon after the release reliably propagate and, perhaps a little later, also get mined by a larger proportion of the block authors. Node operators setting a lower limit would do so at their detriment: they would download the transactions after an announcement from their peers, reject adding it to their mempool, then download the same transactions again when a block includes them, incurring increased bandwidth and extra latency on the updating to the latest chain tip.

Some proponents of the increased limit argue that the configuration option should not have been added in the first place, as it is ineffective to locally configure a different limit, and that the configuration option is even less useful after dropping the limit. Other contributors argue that setting a lower limit only harms the node operator, and removing the configuration option takes away control needlessly.

If the blocks were generally not full, and this change would cause the blocks to be full again, I would see how there would be an argument that the blockchain is growing faster than necessary, but blocks have been almost consistently full for the past 27 months. I’m honestly not sure why opponents of this change think that the proposed change would make nodes more expensive to run. If a lot of OP_RETURNs were added to the blockchain, it would make the resulting blocks easier to validate and reduce the overall blocksize compared to blocks with a higher proportion of witness data. It seems to me that there are some misconceptions here.

I think it is a reasonable idea to drop the OP_RETURN limit at this time. I left the following concept ACK:

Concept ACK on removing the limit on OP_RETURN size and count.

The limit on OP_RETURNs size is ineffectual, causes increased node traffic, and drives mining centralization. While I have no personal desire for more large OP_RETURNs on the blockchain, it is preferable to have data be written into OP_RETURNs than the UTXO set, and it is preferable to see the transactions I’m competing with in my mempool, than to incentivize build-out of mechanisms for direct submission to the largest mining pools.

Regarding Knots, I would not let my money be touched by a node that is maintained by a single developer as a side project via picking open (unfinished) Bitcoin Core pull requests to a 1000+ commit patch set.

While most Bitcoin Core contributors do not seem particularly excited about ordinals, inscriptions, runes, or similar projects, most of them appear to agree that the ability to embed data in the Bitcoin blockchain is a product of other characteristics of the Bitcoin network such as censorship resistance and a flexible scripting system.

Fighting "spam" transactions at the mempool policy level is ineffective, especially when such transactions have spent over $280M in transaction fees in the past two years which translates to plenty of financial incentive for mining pools to accept such (consensus-valid!) transactions out-of-band to pad their revenue.

The only way to properly make inroads on curbing spam would be to soft fork out the spam mechanisms. However, even going back to a small amount of whitelisted output script templates would not prevent data payloads in fake pubkeys or fake public key hashes, signatures per grinding, or other transaction fields that can hold arbitrary data.

When inscriptions were discussed as a concern for the Bitcoin network at a Bitcoin Core contributor meeting, the prevalent position was that making this quixotic fight the main priority of the project was not the best use of the project’s limited resources.

Since transactions with larger OP_RETURN outputs or multiple OP_RETURN outputs are consensus valid, they will appear in blocks as long as they find their way to mining pools and mining pools choose to include them. Any nodes that don’t allow such transactions in their mempool will download them twice: once when the transaction is first offered to them by a peer, where they download it, evaluate it, and drop it due to their mempool policy, and then a second time when they receive the block announcement that includes the transaction.

Whenever nodes are missing transactions from a compact block announcement, they have to request the missing transactions which increases the latency until they can relay the block. The relay is delayed more when large transactions are missing. Nodes that run a mempool policy that is stricter than what regularly appears in blocks therefore use more bandwidth and relay blocks more slowly.

Slower block propagation benefits larger mining pools by increasing the number of stale blocks and delaying other miners in switching to the new chaintip. Bigger miners disproportionally win over competing blocks and the block author doesn’t suffer from the propagation delay when a block is found.

For the record, this pull-req wasn't my idea. I was asked to open it by an active Core dev because entities like Citrea are using unprunable outputs instead of OP_Return, due to the size limits. And yes, that's the thing that has changed since.

If there would be a hard fork, the outputs funding the lightning channels would exist in the UTXO sets of both networks. If both channel participants run Lightning Network software compatible with each network, they could maintain both versions of the Lightning Network channel. However, it would probably require a novel solution to distinguish the channels on the two separate networks. If at least one of the participants does not want to use the channel one one of the networks, they would likely try to close it. If transactions between the two networks are replay-safe, they could close it only on one network, otherwise, they might close it on both and open a new one only on one network once they have acquired coins that only exist on one network.

Unlikely. Inscriptions / witness stuffing is more economical past about the 100 byte mark due to cost. Witness is 4x discounted while OP_RETURNs are not.

We have had multiple phases in Bitcoin’s history in which colored coin protocols, NFTs, or other schemes started using Bitcoin as a data layer. While some of them temporarily increased demand for blockspace, the mempool has so far always emptied eventually. Currently, the one-week average feerate in blocks is below 4 satoshis/virtualbyte.

OP_RETURNs are more expensive than inscriptions for larger amounts of data, and the data payload is not subject to segwit’s witness discount. Previous uses of OP_RETURN were shortlived as they became to expensive for the operators and either switched to other networks or were optimized out of existence. It is not clear to me what scenario the writer is picturing in which loosening the OP_RETURN limits would lead to a substantial amount of OP_RETURN data that could be classified as "opening the shitcoin floodgates".

Some Bitcoin node implementations such as Libre Relay have less strict mempool policies and relay transactions that would be considered non-standard by Bitcoin Core. Some mining pools use similar mempool policies and additionally accept direct submissions out-of-band.

As transactions with multiple OP_RETURN outputs or larger OP_RETURN outputs are permitted by the consensus rules, blocks that include these non-standard transactions are accepted by all nodes.

There are currently three ways of embedding data in the Bitcoin blockchain in use.

1. Inscriptions are written to an unexecuted branch of a taproot leaf script. This data appears in the witness stack of inputs. Witness data is only validated once when a node first validates a transaction’s scripts and is stored as part of the full blockchain record. When a pruning node performs IBD using the assumevalid option, witness data doesn’t have to be downloaded or evaluated at all. Witness data is discounted by 75% compared to other transaction data, but is malleable until a transaction is confirmed.
2. OP_RETURN data appears in the output script. OP_RETURN outputs are only validated once when the node first sees the transaction. The data in output scripts is not discounted and not malleable, as signatures on the inputs generally commit to the exact output scripts. As OP_RETURN outputs are unspendable, they are stored as part of the transaction in the blockchain data, but do not get added to the UTXO set.
3. Some schemes (e.g., Stamps) embed data in payment output scripts using either fake public keys or fake hashes. The data for output scripts is not discounted. As these output scripts are not clearly unspendable, these output scripts must be retained in the UTXO set.

Citrea recently announced that they plan to write data to payment outputs because they need non-malleable transaction data that gets confirmed timely in excess of the current OP_RETURN standardness limit. As the use of payment output scripts cannot be easily prevented, encouraging them to use OP_RETURN outputs instead would be harm reduction as at least the data would not be written to the UTXO set that every node has to retain forever.

The proponents in the mailing list thread and pull request further argue that it is more expensive to write large data payloads to OP_RETURN outputs than inscriptions and therefore use cases that already use inscriptions are not incentivized to use OP_RETURN. The break-even point for that appears to be 143 bytes above which payloads are more expensive to be embedded into OP_RETURN outputs.

I am not aware of any effects on LN development.

Thank you for taking the time to read this. :)

I can't speak for the "spam companies and projects", but as far as we're concerned:

I'm not going to emphatically say "no" because who knows, maybe in the future we'll have some application where it makes sense but we currently do not. We have released and sold two inscription collections (that both put data in witness data). In both of those cases, it's not clear to me that having the data in OP_RETURNs would have been better. The main reason we put the data in witness data was for compatibility with the ordinals protocol. Our collectors want to be able to manage, store, and trade our collection in wallets they're already using -- and there are several ordinals-specific wallets out there, and any wallet with coin control could technically be used. You could add opreturns to ordinals, but it would be weird. imo, having inscription data in the input instead of the output makes the protocol cleaner and easier to implement.

So for our collections, compatibility is a bigger concern than something like the witness discount. High-value inscriptions are actually reasonably price-insensitive when we're talking about a 4x cost premium. We did a LOT of work on Quantum Cats to bring the cost down, but that was by a factor of about 100, not 4.

Outside of digital collectables, we've done a lot of work with OP_RETURNs holding data commitments for multi-transaction protocols using OP_CAT or other covenants. In those cases, usually we're putting one or two merkle roots and maybe a little metadata tag in an opreturn. So we actually haven't felt any real pain with the 80-byte limit. We actually run into consensus limits more often than we run into the OP_RETURN limit.

In general, if we did want to stick a bunch of data into an opreturn it would probably be something where:

• we are not inspecting it in a future transaction (a la the OP_CAT state caboose trick)
• it's something where either its an op_return-specific protocol or something other than ordinals (maybe something we cook up, maybe something our customers want)
• its something where we really care about malleability (opreturns get covered by SIGHASH_ALL, witness data does not)

Nothing currently fits that bill, so I don't think so, but you never know. Maybe some of the people mad about this have a fun idea they can share.

Citrea is ramping up to launch a rollup on Bitcoin that would use Bitcoin as the data availability layer. It does not require a consensus change to deploy, i.e., they don’t need to ask for permission. I did not study their protocol in detail previously. Skimming their technical specs, they mention that one type of proof is committed every ten minutes (i.e. 144 txs per day), but I also read that they store all necessary data on Bitcoin, therefore it is not clear to me whether there are more transactions that would write to the Bitcoin blockchain.

If it is just those 144 txs per day, their scheme would be unlikely to significantly impact the fees for other users, but I’ve previously seen an overview of dozens of other similar projects in the making (probably with various degree of success), so there may be multiple other schemes in the future for which we’d prefer that if they must, they only write to the blockchain and not both the UTXO set and the blockchain.

https://groups.google.com/g/bitcoindev/c/d6ZO7gXGYbQ/m/QwkPB2HtEQAJ

tl;dr: you could make data publication much more expensive by requiring transactions to prove that data in them isn't arbitrary. But even that will not totally stop data publication. Also, not all “spam” requires data to be published.

Bitcoin Core does not accept "non-standard transactions" into its mempool. Bitcoin Core 29.0 and earlier consider transactions with more than one OP_RETURN output or an OP_RETURN output of more than 80 bytes of data payload non-standard.

Neither the count nor the size of OP_RETURN outputs is limited at the consensus level, so all nodes accept such transactions when they appear in blocks.

Currently, Bitcoin Core does not accept transactions with more than one OP_RETURN output to its mempool.

Peter Todd’s pull request proposes to allow transactions with multiple OP_RETURN outputs into the mempool.

Bitcoin Core 29.0 or earlier do not accept transactions with more than one OP_RETURN output or with an OP_RETURN output of more than 80 bytes of data payload to its mempool. Neither the count nor the size is limited at the consensus level. Peter Todd’s pull request proposes to drop both the limit on the count of OP_RETURN outputs and to drop the limit on the data payload.

The GitHub repository is the workspace of the Bitcoin Core contributors. We welcome constructive contributions from anyone, and spend a lot of time encouraging others to also make it their workplace.

Think of the repository like a co-working space: you can rent a desk for the day, you can work on something by yourself or collaborate, but if you hold a riot in the co-working space, shouting at people trying to do work, you are probably gonna be asked to step outside.

We use pull requests to review and evaluate proposed changes to the Bitcoin Core code base. We discuss the proposed change conceptually, evaluate the approach, and collaborate to hone the implementation of the idea. There are about 40 part-time and full-time Bitcoin Core contributors, and maybe a hundred occasional contributors.

GitHub pull requests are linear comment threads, and it is not at all designed to scale to social media level engagement. A lot of us get an email every time someone comments on a pull request we are participating in. When suddenly hundreds of people start engaging with a pull request, this quickly adds a lot of noise to our inboxes and the technical review comments quickly get lost in the flood of other comments. The moderators step in to fade out some of the repetitive or abrasive comments, in order to increase the visibility of constructive comments. Eventually someone feels mistreated and this supercharges the parallel discussion on social media.

Overall, there are probably better venues to have this sort of conversation. For example the Mailing List, Delving Bitcoin, Stacker News, or Reddit. (Twitter and Nostr seem to contribute more to the outrage, so I’m not sure discussions are all that productive there. ;))

For the Bitcoin Core repository, if you contribute relevant new arguments or other constructive comments, please by all means, go ahead. But before posting, please try to catch up on the state of the debate by reading the mailing list thread and all (visible) comments on the pull request before yours.

Citrea does not require an increase of the OP_RETURN limit.

AFAIU, Citrea is planning to launch a ZK Rollup on Bitcoin. To that end, they intend to write a proof into the Bitcoin blockchain every ten minutes. This proof takes 100 bytes of data. Their current plan is to write that data into one OP_RETURN output accompanied by a fake pubkey hash. Outputs with fake pubkey hashes cannot be safely discarded, therefore this unspendable payment output would pollute the UTXO set for all times. This would just work for them with the currently established mempool policies.

One of the motivations for the pull request would be that it could be suggested to Citrea that they instead write all data to a single slightly larger OP_RETURN output and we at least do not incur the unspendable outputs in the UTXO set.

Overall, the OP_RETURN limit was introduced to guide the use of Bitcoin away from excessive blockspace use for data while the available blockspace was only partially demanded. In the past 27 months, there have only been a few block that have not been full, so undemanded blockspace is no longer a thing. OP_RETURN outputs would have to compete for blockspace with other transactions at all times. The limit is neither as important nor as effective today as when it was introduced. Instead of providing mining pools with a financial incentive to accept oversized OP_RETURN outputs out of band, and to have debates to slightly loosen the limit further every once in a while, it seems easier to get rid of the incentive and debates by dropping it altogether.

Transactions have been shown to somewhat reliably propagate to all nodes that accept them if at least 10% of the node population accept them to their mempool. Even a strong majority of the nodes of up to 90% of all nodes would have little to no impact on the propagation of consensus valid non-standard transactions relayed by the other 10% of the nodes..

Additionally, Libre Relay nodes, an implementation with less strict mempool policy than Bitcoin Core, preferentially peer with other Libre Relay nodes which means that they effectively relay transactions among each other even with much smaller network penetration, and some mining-pools accept direct submissions through web interfactes or APIs that do not rely at all on network propagation.

Not that I’m aware of.
Neither Jameson Lopp nor Peter Todd are regular Bitcoin Core contributors. All arguments that I have seen were based on where the data would be stored, whether the OP_RETURN limit is still effective, and whether we want to have this debate every few years.

I think this answer covers the same topic already: #972077

Yes, in the sense that when you configure your node to have a more strict mempool policy than that of its peers, it will not add offending transactions to its mempool, and therefore also not relay them.

However, each node makes at least 8 outbound connections through which transactions are relayed, and listening nodes can even have more than 100 connections. A single peer announcing transactions is sufficient for a node to hear about them, so it is sufficient for about 10% of nodes to relay transactions for them to reliably reach miners that want them.

In conclusion, your node might not be participating in the relay of such transactions, but the relay of offending transactions is only prevent if almost all nodes on the network participate.

The UTXO set represents all spendable pieces of Bitcoin. A fullnode must have all UTXOs in order to be able to validate transactions. If some nodes were to discard some UTXOs and these UTXOs later get spent in a transaction, the network would fork as some nodes follow the blockchain in which the coins get spent and others would start forming an alternative chaintip.

There have been several cases of "blockchain graffiti" in which messages were left in pubkey hashes, and counterparty/Stamps deliberately used 1-of-3 bare multisig outputs to store data in two of the public keys (leaving the UTXO spendable per the third key). Recently, Citrea announced that they would store some data in pubkey hashes to embed non-malleable data in transactions with timely confirmation. A part of the motivation for dropping the OP_RETURN limit is that some consider it harm reduction to allow OP_RETURN payloads of 100 bytes instead of Citrea forging ahead with writing permanently to the UTXO set.

We could:

• try to forbid the inscription envelope at the mempool level, which would probably lead to more nodes running less strict mempool policies, or more direct submissions to mining pools.
• soft fork out the inscription envelope specifically, but it would be trivial to come up with another similar construction that allows embedding data in the witness stack, and given the time line of soft forks, it would be hard to effectively ban new constructions that evade the soft fork rules. Some argue that being willing to ban the construction would be a sufficient signal for NFT activity to move to another network, but I am not convinced that this is true.
• soft fork in a much smaller limit on witness data, but that would simply increase the overhead for storing data, not actually prevent it.
• whitelist only single-sig payment output scripts, forbid all other scripts at the consensus level, but that would still allow people to embed data in fake pubkey hashes or fake pubkeys.
• whitelist only single-sig payment output scripts, and require that signatures prove that the scripts are spendable, but data could still be embedded by grinding signatures or stuffing them into transaction fields that hold arbitrary data like the input sequences.

Overall, it seems unfeasible that we make data payloads prohibitively expensive while payment transactions remain incredibly cheap. In the long run, small valuable payment transactions will outspend frivolous data transactions, and valuable data transactions will outspend valueless payment transactions.

Because of all the drama, I'm adding another reason to this:

A potentially concerning reason would be a group of emotionally charged people who didn’t get their way with Bitcoin's direction on the datacarrier flag. They are willing to burn money and act against their economic interests to try to prove themselves right, at least in the short term.

Bitcoin Core’s mempool data structure is limited to 300 MB by default. If a node’s mempool is full, it will start evicting the transactions with the lowest feerates. Transactions get into the mempools of nodes much the same way as they get into blocks: if they offer a higher feerate, they are added to the mempool, potentially displacing lower feerate transactions, whether they are big or small transactions.

OP_RETURN transactions do not have any advantage in the competition for blockspace, and OP_RETURN data appears in the output script. The output script is not subject to segwit’s witness data discount, and therefore each byte of OP_RETURN data incurs 1 kvB (4 wu) of blockspace.

The OP_RETURN output type was introduced as a harm reduction to divert users from storing data in unspendable bare multisig outputs that would stay in the UTXO set forever. Bitcoin Core has limited standard transactions to one OP_RETURN output of at most 80 bytes data payload for many years. When people started putting inscriptions into witness stacks, some people argued that such inputs should be "filtered" in a similar manner.

"Fix the filters" is a demand that Bitcoin Core developers amend mempool policy to limit or forbid all data carrying transactions.

Larger OP_RETURNs may slightly reduce the friction for users to embed small amounts of data into the blockchain. Since OP_RETURN data is written into an output script, such a data payload is not subject to the witness discount. This means that larger OP_RETURNs would be significantly more expensive than inscriptions which are already happening.

After watching the NFT enthusiasts spend over $280M in transaction fees over the past 27 months, it seems to me that there are strong financial incentives for miners to facilitate such use. As the block subsidy is exponentially shrinking, these incentives will only grow. It will inherently be possible to embed data in the Bitcoin blockchain. We can make it a tiny bit harder by adding friction at the mempool level, which will incentivize mining pools to facilitate private relay and out-of-band submissions, benefiting the largest mining pools. We can make it significantly harder by restricting outputs to a small whitelist of payment output scripts at the consensus level, but that would neuter Bitcoin’s scripting system. The question boils down to what trade-offs we are willing to make and how much overhead there will be to inserting data—we cannot completely prevent it.

Bitcoin’s scripting system is what will allow us to build innovative scaling solutions and is necessary for the network to succeed in the long run. Mining decentralization was at its high point in 2017 and has been trending toward more centralization. Censorship resistance seems more important than fighting a few monkey pictures.

So, to me, it is preferable that a modicum of data be written to OP_RETURN outputs rather than to unspendable payment outputs that will linger in the UTXO set forever, and I don’t think it’s worth to make sacrifices regarding the scripting system or mining decentralization just to bring down the hammer on some Bitcoin users that happen to enjoy trading graffiti. Either way, the worst of the most recent colored coin and NFT wave appears to have passed. Feerates are down, and blockspace demand from runes and inscriptions appears to have jumped the shark:

Yes, cultural aspects can weigh into this. Funnily enough, most Bitcoin Core contributors would prefer if Bitcoin were only used for monetary transactions.

I think where the main disconnect lies is that there are more goals beyond just preventing data transactions. Mining decentralization, censorship resistance, and having a flexible scripting system are also important aspects of the Bitcoin system, and many Bitcoin Core contributors expect that the arms race of trying to prevent data transactions will take too much time from other important work.

Finally, monetary transactions alone have not been providing enough blockspace demand to keep blocks full, but have still been too expensive for many uses at the same time. It seems to me that overall we still need to find more scalability improvements, especially for small payments. I don’t think the network would thrive in the long run if we were to shrink-freeze consensus rules on the status quo just to combat monkey pictures.

The consensus rules specify what a node must accept in a block. These rules must match perfectly across all node implementations. If a block or a transaction in a block are evaluated differently by some nodes, the network would experience a consensus failure as some nodes accept the block while others fork off.

A node’s mempool policy defines what the node will relay and consider for the block templates it produces. We use mempool policy to e.g. discourage transactions that are expensive to validate or might trigger security issues for some nodes, and the premature use of upgrade hooks. Generally, mempool policy is more strict than consensus rules and may diverge across nodes. When many nodes agree on mempool policy, it reduces the amount of bandwidth necessary to propagate transactions and blocks across the network, and reduces the overall latency of block propagation, because most nodes can reconstruct the full block from compact block announcements.