Revoke Gloria Zhao's permission to accept changes to Core?

[DeeppRockk]

^ look, the datacarriersize limit was increased to 100,000 bytes in bitcoin core v30, but that's just a default config setting, not a protocol hard limit.
the spam filter you're talking about is part of the mempool policy rules, which nodes can adjust independently. op_return is for arbitrary data, and while citrea might only need 150 bytes, bumping it to 100k is about accommodating potential future use cases without constant forks.

the claim that the filter doesn't work is misleading - it's more that it's inefficient at distinguishing data based solely on size, especially with techniques like chunking. technically, the change came through pr 33453 merged by ava chow, and it's reversible per node; knots nodes, for instance, cap it around 42 bytes. so the argument isn't about blowing up a non-working filter; it's about optimizing for different priorities like app functionality versus chain bloat.

if you dive into the code, the mempool has always had grey areas on what constitutes spam, and this is just another tweak in that ongoing balancing act.

[PepeLapiu]

^ look, the datacarriersize limit was increased to 100,000 bytes in bitcoin core v30, but that's just a default config setting, not a protocol hard limit.

Let's not pretend that defaults don't matter. Defaults do matter, especially when the user would have to edit .config files to change it. And the vast majority of users wouldn't know how to do that.

And let's keep in mind that they started out by wanting to remove the filter completely. Than they were so pressured that they would change to mark it as deprecated. And at the last minute, they were strong armed into no longer marking it as deprecated. They clearly want to remove the filter.

op_return is for arbitrary data, and while citrea might only need 150 bytes, bumping it to 100k is about accommodating potential future use cases without constant forks.

First and foremost, I reject the notion that a company should be abke to change the code, or that devs would even consider changing the code to accommodate a company, as if bitcoin belonged to core to toy with.

Secondly, I reject the notion of prepping bitcoin for "future use cases" without even knowing what those "future use cases" really are.

There i s only one use case for bitcoin: money. You should GTFO with your stoopit jpegs.

the claim that the filter doesn't work is misleading

Misleading indeed. Especily when you consider 99.9% of the op_return txs weemre respecting the limit for as long as the filter existed.

if you dive into the code, the mempool has always had grey areas on what constitutes spam, and this is just another tweak in that ongoing balancing act.

What spam is is pretty simple to me. Any transaction intended to store a jpeg on chain is pretty clearly spam.

While I'm sure you could point to specific cases on the fence, most of what constitutes spam is pretty clear.