I don't understand the arguments for Bitcoin Core v30

[Clearpilled]

My main points against it would be:


1. Increasing the size of OP_RETURN allows CSAM to be stored in a non obfuscated way

2. Arbitrary data presents "unknown unknown" attack vectors, some are going to be immediately obvious, like malware, but we should expect bad actors to be more clever than even us.

3. If it causes the average block size to increase, it could strain nodes pointlessly.


The arguments I have seen FOR v30 is something like this:

1. We shouldn't censor data, Bitcoin is about freedom!

2. People can already store arbitrary data, this will just make it easier!


Both of these, I think, are lousy arguments. First, there are things we should censor, I know that 'censor' is a dirty word, but most people would agree we should censor CSAM, I don't think people's moral or legal responsibility to not store CSAM is absolved if it's done to run a Bitcoin node or not. The second argument, I think can also be used in reverse, if people really want to store arbitrary data, they will find a way, without an increase in OP_RETURN, it will be obfuscated enough that Bitcoin nodes won't have legal or moral obligations.

A higher level point I have is about what I would identify as the root cause of both of these arguments, a philosophy along the lines of "Why should we decide what data people want to store, as long as they are paying for the block space, it's no different"

To show why that's wrong, let's ask a question: Why have any scaffolding to the structure of Bitcoin at all? Why not let it be just a chain of hashes, freely interpretable in any way that's desired? Well, then it wouldn't exist. The reason Bitcoin exists that it is financial, because it is financial, you can engineer the incentives of it. It's called Bitcoin after all

I am willing to change my mind, and would appreciate anyone who disagrees representing the other side in more depth.

[Ambatman]

You can gloss over this thread Removing OP_return limits seems like a huge mistake
Where it was actively discussed
Though I doubt both side were really convinced since they pretty much have their reasons.

I am willing to change my mind, and would appreciate anyone who disagrees representing the other side in more depth

This below does have valid points as well as others in the above thread.
My issue is we still assume that people would rather pick cheaper alternative and also breeding the concept 'Cloud storage' rather than 'money'
Don't mind me a lil pessimistic sometimes
 

Why? It's in the interest of the whole network.

There's probably a technical reason?

No. It is related to the Open Source world in general. People are implementing what they want to implement, and they are often unpaid, and spend their free time to code things they want to code. Why should they waste time on bringing NFT-friendly features, when the whole Script can be disabled during transition to quantum-resistant addresses? And now, one of the criterias, when picking quantum algorithms, is JPEG resistance. In general, it is easier to focus on regular payments first, let NFTs use whatever they want (because spammers are going to spam, as you can see, when they put ASCII hex characters inside OP_RETURN, instead of at least packing things in binary, and making it 50% smaller).

What positive use cases would we have if indeed OP_RETURN limits were removed?

For example it is cheaper, and it takes less bytes, when you use OP_RETURN for some particular messages. And in general, by having just OP_RETURN, you don't need any Segwit or Taproot envelope. I don't remember exactly, but for something up to 150 bytes, OP_RETURN is cheaper, and then, after making a message bigger than that, Taproot becomes cheaper, because of Segwit discount. Which means, that if OP_RETURN limit would be raised, then it would be mo

[achow101]

1. Increasing the size of OP_RETURN allows CSAM to be stored in a non obfuscated way

This can already be done with an inscriptions-like construction. Furthermore, this can be done by any miner since there are no consensus rules governing arbitrary data.

2. Arbitrary data presents "unknown unknown" attack vectors, some are going to be immediately obvious, like malware, but we should expect bad actors to be more clever than even us.

As above, this is not a new risk, and OP_RETURN does not make it worse.

3. If it causes the average block size to increase, it could strain nodes pointlessly.

OP_RETURN actually makes the average block size smaller, and it reduces the validation required, so it's actually better for the network.

Since OP_RETURN outputs are output data only, OP_RETURNs consume 4 weight units per physical byte of space consumed. This means that a block filled predominantly with OP_RETURNs will be smaller than one that isn't. Additionally, OP_RETURN outputs are provably unspendable. This means that nodes validating a transaction that contains OP_RETURN outputs do not need to consume RAM or disk I/O in order to insert the output into the UTXO set. instead, they skip it. This means validation of such transactions is marginally faster.

First, there are things we should censor, I know that 'censor' is a dirty word, but most people would agree we should censor CSAM, I don't think people's moral or legal responsibility to not store CSAM is absolved if it's done to run a Bitcoin node or not.

The issue is that any kind of censorship leads to providing the technical ability to censor things which we do care about being censored.

The second argument, I think can also be used in reverse, if people really want to store arbitrary data, they will find a way, without an increase in OP_RETURN, it will be obfuscated enough that Bitcoin nodes won't have legal or moral obligations.

It's already possible to store arbitrary data, and more of it for less in fees, without increasing the OP_RETURN limit. However, there are some specific data storage techniques which people are (planning to) using which are harmful to the network. Specifically, there are people who wish to store more than 80 bytes of data in output data, primarily because they need to have some kind of commitment be broadcast publicly and widely. But since it is more than 80 bytes, they can't use an OP_RETURN and would instead use multiple Taproot outputs with the pubkeys as the data. Since those Taproot outputs are not provably unspendable, they will exist in the UTXO set forever, and that is damaging to the network in the long term. By increasing the OP_RETURN limit, we are encouraging them to use OP_RETURNs so that the data does not need to be stored in the UTXO set by all nodes for eternity.

[ABCbits]

1. Increasing the size of OP_RETURN allows CSAM to be stored in a non obfuscated way

It's already possible to search and view arbitrary data with website that show OP_RETURN and Ordinal data. But running full node software alone wouldn't let you search or view any arbitrary data.

2. Arbitrary data presents "unknown unknown" attack vectors, some are going to be immediately obvious, like malware, but we should expect bad actors to be more clever than even us.

FWIW, it's possible to add arbitrary data with size bigger than 80 bytes using OP_RETURN if you can get miner to submit it to their block directly.

3. If it causes the average block size to increase, it could strain nodes pointlessly.

I get the concern. Although looking at block weight size in past year[1], block usually reach it's maximum allowed weight size.

[1] https://statoshi.info/d/000000002/blocks?orgId=1&from=now-1y&to=now&timezone=browser

[d5000]

2. People can already store arbitrary data, this will just make it easier!

The strength of that argument depends on what "easier" means.

In my opinion, the argument becomes strong if "easier" means "less costful for the nodes", not "easier for the data publishers". This is the case if you use OP_RETURN instead of the more costly "fake public keys" method known by NFT platforms like Bitcoin Stamps.

Reducing the costs for node operators should be paramount, because the lower that cost, the higher the degree of possible decentralization of the network.

Or to re-phrase it: if you can't avoid data storage, try data publishers to use the least harmful way for the nodes.

For all other points @achow101 has already provided an excellent answer.

As I posted in another related threads, I have however some reservations against the "total liberation" of the OP_RETURN limit in one single step. It is the easiest way to make that move and it seems to have been already decided, but as this discussion was very politized and generated a lot of drama, I am worried of some potential "revenge attack" once Core 30 gets published. A (standardness) limit to a single OP_RETURN of 512 or 1024 bytes and lifting in further versions would limit the potential of these possible attacks, without harming the "commitment" use case (of course: if somebody wants to attack, he can simply pay the miners, just like now). But of course as datacarriersize is still there every node can decide to set it to a value in that range.

[gmaxwell]

As I posted in another related threads, I have however some reservations against the "total liberation" of the OP_RETURN limit in one single step. It is the easiest way to make that move and it seems to have been already decided, but as this discussion was very politized and generated a lot of drama, I am worried of some potential "revenge attack" once Core 30 gets published

Already now and before any discussion started a very significant portion of hashpower had already removed the limit completely.  Which means anyone can just already embed whatever, the only reason your attacker would delay is because they're trying to contribute to a false and malicious attack that their action was somehow enabled by the newer software when the reality is that they can just do it right now. I don't mean via inscriptions (which, of course, also works), but just via op_return.

This is the product of having limits that are actively irrational for miners to impose, they'll go dig them out and when they do so they're are not likely to expend a lot of time balancing concerns.  Policy can be useful but it doesn't stand against economic demand.

Of course, it would be nice to deny dishonest enemies of Bitcoin that misinformation opening.  Unfortunately, since a big reason to make the change is to make relay and mining more consistent again in order to stop screwing up block propagation/etc. they need to actually be made consistent.  Imposing a 250 byte limit while significant miners impose no limit doesn't achieve that end.

Similar, the alternatives to using op_return such as fake pubkeys or inscriptions also have no such limit.  So to the extent that the reason for removing the limit is because it's better for the network to use op_returns than other means, that isn't helped by limiting op_return.  The people behind the opposition know this, or otherwise they'd propose a consensus change to just preclude larger opreturns--  that limit would actually work in the sense that it couldn't be bypassed by miners, but it would be outright harmful since it would just divert usage to fake pubkeys or other more harmful approach.

So really it doesn't make logical sense increase the limit less [1], it wouldn't even be a narrative win because people would just jump on these logical inconsistencies.  And since the opposition is heavily relying on misinformation and outright lies, they'd probably *still* do the same attack and claim it was a result of the change-- clearly they can convince a lot of people with arguments to emotion that simply disregard the facts.


[1] technically it's still limited, but the limit is the same as the size for a standard transaction.

[Ferib]

It's funny, some argue that inscriptions would bump the fees making it harder for users who believe in "store of value" and want to transact

But at the same time, some argue that having high fees would be good for miners as block rewards halve and therefore it secures the network as miners keep participating for the higher tx fees.

I don't think blocking or allowing arbitrary data is a good thing. But there seems to be a lot of demand to have arbitrary data into the Bitcoin blockchain for whatever reason, and people are paying for that. Maybe there can be a nice middle ground? Looking over at Ethereum, maybe we can just have Bitcoin as a "Layer-1" type of thing where OP_RETURN is simply used for storing/indexing hash as we point to specific IPFS location, or something else.

[ABCbits]

I don't think blocking or allowing arbitrary data is a good thing. But there seems to be a lot of demand to have arbitrary data into the Bitcoin blockchain for whatever reason, and people are paying for that. Maybe there can be a nice middle ground? Looking over at Ethereum, maybe we can just have Bitcoin as a "Layer-1" type of thing where OP_RETURN is simply used for storing/indexing hash as we point to specific IPFS location, or something else.

Some of ordinal supporter state they want the data is preserved forever. So suggesting them to store the data on IPFS and add the IPFS link on Bitcoin blockchain with OP_RETURN would be ignored. Besides, IPFS design require at least one IPFS node to store the data. In this context, the suggestion require Ordinal supporter have to operate their own IPFS node.

[d5000]

Unfortunately, since a big reason to make the change is to make relay and mining more consistent again in order to stop screwing up block propagation/etc. they need to actually be made consistent.  Imposing a 250 byte limit while significant miners impose no limit doesn't achieve that end.

Thanks for clarifying this. I understand the reasoning, but the reason why I still think a gradual increase would be perhaps not bad is not only a "revenge attack", but also NFT market dynamics.

If the limit is lifted completely, it's almost sure that some NFT platform will come up trying to fuel an OP_RETURN NFT fad. If Core 30's new default policy achieves enough acceptance, then just like with Ordinals, such a wave could become massive just because it's so easy to publish an "unlimited" OP_RETURN NFT (and if current fee levels remain it would also be not expensive).

A gradual limit increase would make such a fad less straightforward to build up. The NFT guys could wait until Bitcoin 32 or 34 or whatever lifts the limit completely. But now, in 2025, the topic is in everybody's mouth and thus such a fad could benefit from that. In late 2026 or 2027 probably everybody will have already forgotten what the OP_RETURN drama was about, and that could be the moment to lift the limit completely.

Or the NFT guys try to push forward their fad anyway from Bitcoin 30's release on, but it wouldn't be as straightforward to publish larger OP_RETURN based NFTs although of course still possible and not that difficult (using the miners' nonstandard tx publishing tools).

In short: a gradual increase would create noise in the NFT market, and that could "harm" a NFT wave (which in this case would be a good thing, at least from my point of view, I think the fee market should rely more on "as a currency" use cases).

[gmaxwell]

If so, why don't they do it now? there is no difficulty getting them mined.

Are you just thinking the drama is free press for them?  Maybe but increasing it over time to eventually actually fix the problem (make it match miners) leaves things broken for a long time, risking further mining centeralization which is hard to undo... and also creates repeated oppturnities for drama.

[d5000]

If so, why don't they do it now? there is no difficulty getting them mined.

I think simply it is easier to "let the wave roll" if those creating NFTs can simply broadcast transactions and don't have to rely on a miners' tx publishing service. Ordinals-style NFTs could have used the fake public key methods like Stampchain too (since Bitcoin's inception practically) but the Taproot method was a "novelty" which has been exploited by some actors to create a massive wave.

Maybe, and hopefully so, the effect this time could be more limited however, because I think the Bitcoin onchain NFT market should be saturated with dozens or hundreds of thousands of NFTs already on-chain. But such a wave could still catch enough momentum to pull more people into the "elementary school arguments" of the OP_RETURN opposing group (and Knots).

Are you just thinking the drama is free press for them?  Maybe but increasing it over time to eventually actually fix the problem (make it match miners) leaves things broken for a long time, risking further mining centeralization which is hard to undo... and also creates repeated oppturnities for drama.

Yes, "the free press" is the other aspect. Some irrelevant NFT guy from an equally irrelevant "$Dog army" has just a couple of days ago "threatened" a fork with no restrictions for NFTs, clearly exploiting the current discussion, and got some social media coverage with that.

I don't know if the potential for drama is still high enough in a couple of months or 1-2 years, as such drama waves also tend to decrease with time. For example, while some big blockers are still grumbling in 2025, in 2019 in the largest part of the Bitcoin community the topic was more or less closed and Bcash became simply a mid-sized altcoin.


BTW, for those interested, I created a beginner friendly thread to explain why the OP_RETURN standardness limit increase should not lead necessarily into more data/NFT/spam transactions (but mentioning the possible effect I wrote about in the last posts).

[takuma sato]

The argument is simple: VC money wants to pump their shitcoins and everyone has a price, so they'll find whoever pushes the agenda that allows them to sell their shitcoins.

https://bitcointalk.org/index.php?topic=5559004.0

Just go on X. Who is pushing for this? Everyone is pumping some $token next to their bio. Why would anyone with a technical background allow this crap? because VC money is finding it's way. It could be argued that certain intel agencies would also benefit from having a weak point there to legislate against Bitcoin because "it hosts CSAM". It brings zero good things to Bitcoin, so the only logical conclusion is that someone is profiting from this. I doubt anyone that has been here since the begining is enjoying this unless they have been bought during the process. Probably a lot of people with huge fortunes out there watching how they are screwing up with their money so some retards can add $dog tokens on the blockchain. This will surely end well.

[NotATether]

CSAM is obviously the most talked-about use case but there's other more niche ways that datacarriers could be (ab)used that are illegal in at least some governments, for example there is malware which I have talked about many times, in addition to C2 payloads for said malware, but there are other things like gore, Nazi propaganda, terrorist cell writing & media, suicides, as well as things that aren't illegal but are obnoxious to most users such as porn, Ordinals and 100KB textual spam like "aaaaaaaaaa".

This post is not an argument against increasing the datacarrier size limit, but it's simply to highlight the potential for misuse of any data storage system.

[Xun hu]

As I posted in another related threads, I have however some reservations against the "total liberation" of the OP_RETURN limit in one single step. It is the easiest way to make that move and it seems to have been already decided, but as this discussion was very politized and generated a lot of drama, I am worried of some potential "revenge attack" once Core 30 gets published

Already now and before any discussion started a very significant portion of hashpower had already removed the limit completely.  Which means anyone can just already embed whatever, the only reason your attacker would delay is because they're trying to contribute to a false and malicious attack that their action was somehow enabled by the newer software when the reality is that they can just do it right now. I don't mean via inscriptions (which, of course, also works), but just via op_return.

This is the product of having limits that are actively irrational for miners to impose, they'll go dig them out and when they do so they're are not likely to expend a lot of time balancing concerns.  Policy can be useful but it doesn't stand against economic demand.

Of course, it would be nice to deny dishonest enemies of Bitcoin that misinformation opening.  Unfortunately, since a big reason to make the change is to make relay and mining more consistent again in order to stop screwing up block propagation/etc. they need to actually be made consistent.  Imposing a 250 byte limit while significant miners impose no limit doesn't achieve that end.

Similar, the alternatives to using op_return such as fake pubkeys or inscriptions also have no such limit.  So to the extent that the reason for removing the limit is because it's better for the network to use op_returns than other means, that isn't helped by limiting op_return.  The people behind the opposition know this, or otherwise they'd propose a consensus change to just preclude larger opreturns--  that limit would actually work in the sense that it couldn't be bypassed by miners, but it would be outright harmful since it would just divert usage to fake pubkeys or other more harmful approach.

So really it doesn't make logical sense increase the limit less [1], it wouldn't even be a narrative win because people would just jump on these logical inconsistencies.  And since the opposition is heavily relying on misinformation and outright lies, they'd probably *still* do the same attack and claim it was a result of the change-- clearly they can convince a lot of people with arguments to emotion that simply disregard the facts.


[1] technically it's still limited, but the limit is the same as the size for a standard transaction.

Wow, that really cleared up a lot about OP RETURN limits and miner behavior i didn’t know miners could already bypass the old limits and that using OP RETURN is actually safer than fake pubkeys or inscriptions. mind blowing!
Also i just learned something new: some wallets and layer-2 solutions can batch or compress OP RETURN data before broadcasting that might make the impact on nodes even smaller than we’ve been discussing.
network efficiency really has so many moving parts slowly getting the hang of it

[headingnorth]

Core 30 wants to turn bitcoin into a memecoin. It is worse than malware.

The people behind Core 30 such as Jameson Lopp who loves memecoin crap along with the VCs who funded
Taproot Wizards (NFT garbage) tells you everything you need to know about this current attack on bitcoin
and their malicious intentions.

Core 30 is a total joke.

The arguments I have seen FOR v30 is something like this:

1. We shouldn't censor data, Bitcoin is about freedom!

2. People can already store arbitrary data, this will just make it easier!

That's like saying we shouldn't be allowed to filter spam from getting into our Email Inbox because spam is free speech
and shouldn't be censored! There's just no point in arguing with something so stupid.  

As Mark Twain once said, "Never argue with an idiot. They will only drag you down to their level and beat you with experience."  

[gmaxwell]

lopp isn't involved with the development of bitcoin core at all-- beyond being a bitcoin using member of the public that has sometimes commented on things that interest him.

Bitcoin developers overwhelming do not like NFTs/embedded shitcoins, or similar.

Major miners already disabled the OP_RETURN limits, so maintaining them for relay by default just causes harm without a benefit.

Also, some people who would have otherwise used them are instead using fakepubkey outputs which are infinitely worse.  Nothing new can be embedded that can't be done now because 1. miners already bypassed, and 2. can be embedded in the witness instead of the outputs.

So the whole thing really is a nothing burger and is just acting as a proxy for parties who are pro-censorship to try to enlist support on the basis of NFT bullshit sucking.  Problem is that that isn't a genuine division, pretty much eveyone in these discussions thinks NFT bullshit sucks.  It's just that we already have capacity limits and fees to manage it which clearly do work if not fast enough for everyone's preference--- and degrading the central properties that make Bitcoin worthwhile isn't an acceptable risk,  particularly vs nothing burger op_return.

That's like saying we shouldn't be allowed to filter spam from getting into our Email Inbox because spam is free speech

The USG passed through some horrible anti-patriotic freedom destroying law by calling it the "Patriot" act.  Calling the traffic here spam seems to have some similarly psychologically distorting effects.  Spam is the wrong word.

Email spam is an unsolicited commercial advertisement (or scam attempt) sent at practically zero cost in bulk to a huge number of targets.  If the target reads it at the very least it wastes their time.  They didn't ask for it, they didn't want it, and the spammer has little incentive to be selective because sending it is practically free.  You are successful in defeating spam if you don't waste your time with it clogging your inbox or waste your time reading it, even if computers acting on your behalf spent a lot of resources analyzing it.  The fact that the spammer may have successfully communicated with someone *else* is just not your concern.

This "spam" in Bitcoin is send to a consenting party, created by a consenting party at considerable cost, processed by a consenting miner who has been paid handsomely for their efforts.  By the traditional definitions of spam you already defeated it: You'll never see it, it never wastes your time.  Instead, bitcoin "spam" opponents are concerned with interfering with the consensual interactions of third parties.  There are fair justifications for them caring about it, but it's just very different from the issues around spam.

The difference is significant because tools that work against Email spam with minimal risk of collateral damage or moral hazard, don't work against "bitcoin spam" and/or come with significant risk.  Because fundamentally email anti-spam is about protecting your time, while bitcoin "anti-spam" is about inhibiting communications between consenting third parties.

In the interest of having a useful discussion I don't object to using the common language for this stuff, but it's important to keep in mind that Bitcoin "spam" and email spam are just entirely different things and not really comparable.

[Technically there is some 'spam' by the traditional definition in Bitcoin-- dust payments. But these are largely addressed by wallets not displaying tx details in ways that would encourage dust payments... and they have not been a significant issue or the subject of any of the 'spam' debate].

[headingnorth]

This "spam" in Bitcoin is send to a consenting party, created by a consenting party, processed by a consenting miner who his paid very very handsomely for their efforts.  By the traditional definitions of spam you already defeated it: You'll never see it, it never wastes your time.  Instead, bitcoin "spam" opponents are concerned with interfering with the consensual interactions of third parties.  There are fair justifications for them caring about it, but it's just very different from the issues around spam.


[Technically there is some 'spam' by the traditional definition in Bitcoin-- dust payments. But these are largely addressed by wallets not displaying tx details in ways that would encourage dust payments... and they have not been a significant issue or the subject of any of the 'spam' debate].

On the one hand you say no one wants spam on the bitcoin network, but on the other you say spammers
have every right to spam as long as they pay for it? Therefore no one has the right refuse the spam just because it was paid for?

The node operators aren't getting paid anything or even asked permission to transmit and store this unwanted garbage on their nodes.

Nowhere in your absurd argument do you mention the rights and interests of the node operators.  
As if the only two parties that matter are the spammers and the miners (those paying to spam the network,
and those profiting and getting paid to mine the spam).

So in your view node operators have no right to object or refuse to store this crap on their nodes?

Bitcoin spam can certainly be compared with email spam, because in both cases node operators are being forced to
receive something whether they like it or not, the same as being forced to receive spam in your email. The comparison is completely valid.

But spam on the bitcoin network is far worse than email spam. At least with spam in your email it can be easily deleted,
but bitcoin spam is stored and stays forever on the blockchain with no possibility to delete it, bloating and slowing the network
forever with useless crap while raising network fees and congestion for all users.

[gmaxwell]

No one is required to run a node. No one running a node is required to store the historical chain (enable pruning). No one running a node is required to relay transactions for third parties, nor have a mempool at all (enable blocks only).

But if you do choose to do those things part of the cost of it will be other people's transactions including other people making transactions that you don't like and don't approve of.  This is the cost of an open permissionless system.   Accepting this fact doesn't mean liking or promoting the use.  No doubt many transactions are dumb or even outright bad, far beyond just the NFT crap.  This has always been true, it will always be true.

The very same people you attack over this, myself included include almost everyone responsible for minimizing and mitigating those costs over the past decade-- as if we didn't care deeply about all of those concerns even before you ever heard of Bitcoin.  The costs matter a lot, but not so much that they justify diminishing Bitcoin's reason for existing-- that being a system of electronic money which is substantially free of human judgement deciding to allow or deny other people's transactions.

the same as being forced to receive spam in your email.

No because you will never notice or even know the bitcoin spam is there, just like no one cares about email spam that their MTA silently discards. It doesn't even increase the resources of your node (generally) because the network is mostly against its capacity limit at all times anyways, in fact-- in most forms it makes nodes process blocks faster, and in the OP_RETURN form being discussed every bit of spam using it reduces your nodes bandwidth requirements too.

So you won't notice it, it doesn't take your time, it makes your node use less cpu time and some forms make (like OP_RETURN using spam) your node use less bandwidth and disk space compared to ordinary transactions.  That's pretty wildly different than email spam.

As if the only two parties that matter are the spammers and the miners (those paying to spam the network,
and those profiting and getting paid to mine the spam).

Since this is only a matter of policy-- those *are* the only parties that really matter. The "spammer" can give their transactions directly to a miner (or mine them themselves) and no one elses node is involved or aware until they're already in the blockchain.  But direct submission centralizes bitcoin by making it less economic for smaller parties to mine independently and is one of multiple centralizing forces we've resisted all of Bitcoin's life.

Certainly when it comes to things that might DOS the network or cause disproportionate resource use, it's absolutely a consideration.  But when the traffic amounts to stuff we don't like ... and *can't* even stop anyways it's another matter.

Ah which is another difference between email spam and bitcoin "spam" --  email spam has to be formatted so that the target can read it, because the recipient is an unwitting and unwilling participant.  But in the Bitcoin "spam" stuff because the interacting parties are consenting it can be encoded in essentially arbitrary ways.  OP_RETURN was specifically introduced to give an alternative to encoding things as fake addresses since doing so is so much more costly to the system than just adding some data which nodes know to ignore.

[Mia Chloe]

~snip

This is actually  a two way debate if you ask me. If Bitcoin's core software starts censoring a specific type of data like CSAM I think it kinda forces developers into the impossible political role of global content moderators which  could compromise the network's neutrality.

Basically, attempting to ban easy to read data like that in a larger OP_RETURN will just push bad actors to use methods like scattering data across multiple standard outputs which in my opinion makes the chain harder for honest node operators to analyze and more resilient for the bad data itself.

If people are actually willing to pay the highest fees for block space even for arbitrary data that revenue kinda secures the network for everyone making a "byte a byte" to the system's security budget. Bitcoin's strength comes from its decentralized protocol and scarcity and not from trying to force human morality.

[Xun hu]

2. People can already store arbitrary data, this will just make it easier!

The strength of that argument depends on what "easier" means.

In my opinion, the argument becomes strong if "easier" means "less costful for the nodes", not "easier for the data publishers". This is the case if you use OP_RETURN instead of the more costly "fake public keys" method known by NFT platforms like Bitcoin Stamps.

Reducing the costs for node operators should be paramount, because the lower that cost, the higher the degree of possible decentralization of the network.

Or to re-phrase it: if you can't avoid data storage, try data publishers to use the least harmful way for the nodes.

For all other points @achow101 has already provided an excellent answer.

As I posted in another related threads, I have however some reservations against the "total liberation" of the OP_RETURN limit in one single step. It is the easiest way to make that move and it seems to have been already decided, but as this discussion was very politized and generated a lot of drama, I am worried of some potential "revenge attack" once Core 30 gets published. A (standardness) limit to a single OP_RETURN of 512 or 1024 bytes and lifting in further versions would limit the potential of these possible attacks, without harming the "commitment" use case (of course: if somebody wants to attack, he can simply pay the miners, just like now). But of course as datacarriersize is still there every node can decide to set it to a value in that range.

I can see now why using OP RETURN is less costly for nodes and safer than fake pubkeys or inscriptions. but i’m wondering, does this incremental limit 512 → 1024 really make a big difference? i mean, if an attacker really wants to, they could just pay the fees and send multiple OP RETURNs anyway also, since some wallets or L2 solutions can batch or compress OP RETURN data the node impact can already be somewhat controlled does this limit actually change much?