pull down to refresh

I only listened to the first ten minutes, but could someone perhaps summarize how OP_RETURNs would increase the cost of running a node? He lost me at that point.
reply
He explains this well. I am not wasting my time.
reply
21 sats \ 7 replies \ @Murch 1 May
There can be up to 4 MB of witness data in a block, but only 1 MB of other transaction data. Output scripts are "other transaction data". So, if you put data in an OP_RETURN, it results in a smaller block than when you put it in witness data.
So, yeah, the point doesn’t make sense to me.
reply
please explain how allowing these fiat snake oil salesmen to store more data cheaply in op_return stops them from also bloating with witness data?
reply
51 sats \ 0 replies \ @Murch 3 May
Their usecase requires the data to become available immediately and not be malleable. Witness data is malleable and therefore doesn't work for them.
Their current solution is to write data to the UTXO set by putting the data into hash-based output scripts. That outputs are unspendable and will live in every nodes UTXO set forever. It is probably that they write to OP_RETURN outputs which do not get added to the UTXO set.
reply
They don't care if they store it in an OP_RETURN, or an unprunable output for which also no amount extra policy can stop them. They will post it either way. Giving them and others the option of doing so in an OP_RETURN, we at least give them the option to post their data in a way that is prunable.
reply
You are also setting a cultural policy of encouraging this behavior.
Even if technically beneficial I continue to oppose it on cultural and political grounds. At this time, going forward with this MERGE means bitcoin-core endorsement of the forthcoming "built on bitcoin" shitcoins