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.