Murch on Nostr: Hey Leon, thanks for your reply. Given the many points you raised, I will quote for ...

Hey Leon,
thanks for your reply. Given the many points you raised, I will quote for context what I’m replying to.

> Leon wrote:
> What I don't understand is why the limit for op_return is being changed when filters are actually working. Yes they don't filter out everything but they do filter out most of it.

I am puzzled how you arrive at the conclusion that they "filter out most of it". 53% of transactions over the past year had OP_RETURN outputs or inscriptions. Could you perhaps explain further what effect you perceive filters to have had?

> Leon wrote:
> Then you have a couple of folks claiming that filters are useless and we should give up on them entirely because spammers could use out of bound transactions via services as slipstream by MARA to circumvent filters (which is right but also proves that filters are working pretty well since they wouldn't need to go out of bound otherwise).

Some miners appear to be running Libre Relay or have otherwise loosened their mempool policy. These miners accept transactions considered non-standard by default Bitcoin Core configurations in-band. They appear to track them normally in their mempools, and include them in their blocks whenever those transaction’s feerates put them in the block. The myth that non-standard transactions need to pay a multiple of other transactions appears to be based on the OP_RETURN_BOT service charging a premium and sending at a higher feerate, but if you are willing to wait, non-standard transactions appear to be getting confirmed at the same feerates as any other txs.

> What puzzles me as well is the statement that transaction fees are enough to filter out spam. You might be right with this claim but I am not sold on it entirely.

Given limited blockspace, it is obvious that transaction uses that can afford to pay more for blockspace will price out transactions that can only afford to pay little for blockspace. This means especially that large value transfers have a much bigger budget to pay for blockspace than small transfers (if you are sending 10 ₿, you don’t care about paying 10'000 sats in fees, but if you’re trying to send 10'000 sats, paying 10'000 sats is prohibitive). This isn’t a new observation, I wrote in 2016: "Transaction fees are not in relation to the amount of value transferred, but in relation to the amount of block space they'll take. Therefore, it is relatively cheap to send large amounts of value in Bitcoin but uneconomical to send micro-payments." (via https://bitcoin.stackexchange.com/a/48422/5406). I’m not sure what your expectation is, but any form of Bitcoin succeeding will mean that small payments will be economically infeasible on chain. In the past couple years, we saw the third hype wave of people using Bitcoin for publishing data. Just like the prior two times, the excitement eventually subsided and as the premium came down, the cost curbed the transaction volume. Even at the peak of the hype, large transfers easily price out this sort of use. If you are upset that small payments were priced out, I’m afraid that’s the expected outcome either way. I don’t see the point in lying to Bitcoin users by trying to keep transaction fees low artificially.

> Leon wrote:
> As long as bitcoin evolves the way as projected and increases in global significance a lot more folks might want to spam the chain even though fees would be higher at that point the incentive for spamming and using more resources to do so would grow similarly.
> In general I think spam is harmful and might lead to unintended consequences so I don't think we should give non monetary transactions more room and easier ways to use the protocol.

OP_RETURN outputs do not grow the UTXO set, because they do not get added to the UTXO set. They are easier to validate than payment outputs, because they don’t contain signature operations. Since OP_RETURN data is in output scripts, it has no witness data that would be discounted. As far as I can tell, besides competing for blockspace, they use less resources in every way than other transactions per byte.
Inscriptions also do not increase the UTXO set per se, because it takes creating an output and spending an output to publish the Inscription in the input’s witness stack. Witness data is validated once and retained with a full copy of the blockchain or discarded by pruned nodes as any other blockchain data.
It seems to me that most of the UTXO set increase is due to Ordinals—the notion that satoshis have a serial number and some of those serial numbers are more valuable than others—and users splitting up UTXOs to isolate satoshis with certain Ordinals. Sometimes inscriptions are attached to Ordinals, but I’d still blame that on Ordinals more than on Inscriptions. The transactions that split UTXO amounts to isolate certain Ordinals are indistinguishable from payment transactions without out-of-band information about Ordinals, so the main UTXO set bloat is not easy to filter.
So, overall I see UTXO bloat from Ordinals and blockspace demand by transactions that offer to pay more for blockspace. I don’t see a practical way of preventing Ordinals, and don’t perceive Inscriptions or OP_RETURN outputs as particularly harmful (dumb sure, but not harmful). Perhaps you could elaborate how spam is harmful, if you disagree, because I don’t see it.

> Leon wrote:
> I said core seems compromised because they would not ship many "controversial" implementations in the past but this time when controversy is obvious as you can tell from the debate they don't care and ship anyways.

I don’t know which examples of controversial changes that did not get shipped you are referring to, but the ones I recall were sunk by convincing technical arguments against them. I have yet to see a convincing technical argument against raising the OP_RETURN limit.