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.