If you can't see why I included those I don't think you understand the issue.
Discussion
I know why you included them. They are just irrelevant to the PR. If I remove a color option on a desktop environment. TECHNICALLY websites all around the world will be affected. But in reality it is just the end user that can't render the color.
I don't think you understand the issue either. This is not about spam in valid blocks. Period. This is about spam in individual mempools.
They are not irrelevant to most of the people I see arguing about the issue who consistently have one or more of those facts wrong. I didn't write that for you, I wrote it for the community at large.
I can set a limit on my mempool size. Mempool is RAM only, the least constrained resource on any node I've seen. Mempool is transient and constantly changing. Mempool is far less important than what gets validated in a block to go on chain and be on my hard drive for all eternity. If spam is in op_return instead of witness data I gain the option to not store that spam on my hard drive for all eternity.
Unless you plan to stop validating those blocks and hard fork you accomplish nothing but making your own view of pending transactions less accurate by filtering your mempool. You also remove options from yourself for not storing monkey jpgs because they get put into witness data you can't eliminate without losing economic information your way.
You picked a side, good for you. You picked the wrong side for your stated goal of limiting spam stored on your node. You hold an inconsistent position. You must now change your position, change your goal, or concede to being irrational. If you really think mempool is more important than on chain I can't help you.
There is no way (outside of using DATUM) to filter that spam in the witness. Period. So, all of what you said is conjecture. They are CHOOSING to use OP_RETURN, that is non-binding. Which given a toggle is my perogative. Also, as I said before no single node has an accurate view of pending transactions. So having a few less transactions in my mempool is no different now than it was before.
My goal as far as you are aware is to filter my mempool. Spam on valid blocks is an inevitability but their proliferation using my broadcast node is not.
"On-chain" is what the Miners and Nodes agree is on-chain. We will see what a less performant Ethereum gets you, but I don't think this concession will work out the way you hope it will.
You have setting block templates for your miner and validating block by other miners on the chain on your node confused in your datum statement. Even so, Ocean let's you run pretty strict filters on your miner without datum so it is double wrong.
What exactly do you gain by keeping a TX out of your mempool that you have every intention of considering valid on chain? I know what you lose but I can't see any gain for you. Tell me please?
You said all my OP points we're useless but you missed #1. 4MB block limit before and after the change. No change in what blocks are considered valid to add to the chain by anyones nodes. How does changing nothing about valid blocks on chain destroy performance?
Firstly Ocean and DATUM are two distinct things, I do not use Ocean but I use DATUM. Secondly other miners don't "validate" so if you want to just be pithy and pedantic, I can too.
I'm not confused, you either misread or didn't understand.
As for the why, beyond the bulwark of property rights and I can do whatever I want, refusing to propagate spam forces it to got through other channels that are more fragile. Where as Shinobi seems to think spam centralization is bad, I see it as good because it has one avenue of propagation and if that method fails, no spam.
I never once argued about performance. This is a property rights issue. And compelled speech issue. I don't want to "say" to the network I am passing along a spammers message. The fact that the spammer found another way to "say" that message is irrelevant. But on my property, with my speech, I refuse or at the very least reserve the right to refuse.
You node validates blocks from other miners that include the spam no matter what you do with datum and your miner. Perhaps I was unclear but I wasn't wrong.
Property rights is an argument I can respect. I think they should have changed the default but left the setting. I still think you are destroying your own property to spite your neighbors by running the mempool filter.
You absolutely said a slower ETH. Don't lie to my face about it 1 post later.
What speech is more important to you? Transient in your mempool gossip or what you share as valid block data with everyone for all eternity? If you help encourage them to op_return you can drop op_return entirely from your chain for all eternity, jokes on them.
I get that you see you node data as speech and don't want to stupid shit. I agree on principle. I'm valuing hosting that monkey jpg on chain for all eternity more than 10 minutes in my mempool gossip. You are choosing the opposite. No one knows a way to never share the monkey.
The ETH comment is the end result I forsee when the spammers use the witness anyway when Nodes start pruning OP_RETURN. I don't know where I lied exactly but I take your word that I wasn't clear either.
A year and a half ago there was an initiative to fix the filters but that was pushed aside as "censorship" so, that's perhaps why we never solved the monkey sharing problem.
Regardless, I think we see each other's postion we just disagree on outcome which neither of us know.
My assumption is that the kind of person who would trade in monkey jpgs isn't informed enough know any of those details about where on chain it is stored or going to take any path other than the cheapest possible to the next block.
1MB base and 3MB witness. I think they will end up split on chain once base is full and witness is empty.
2 problems with filters that combine to keep block validation filters from being taken seriously.
1 is they are just way harder than you think to get right if you've never had to write a regex.
2 is that any filter on valid blocks must allow all existing blocks or fork and rollback. we don't know what our adversary has cooked up to sneak through the filter till it hits mempool, or in your case gets in a block. That is too late to get the fixed filter in place.
Points taken. I have tried to write regex, did not go well. Put me off of coding entirely.
As for my filter removing my info on current attacks, I watch attacks outside of my own nodes. I query mempool.space nodes and a few others to keep up on what traffic that I don't relay. I still get the info just not on my own node.
That is fine for setting fees for manual on chain transactions but not very sovereign. It also not helpful for lightning justice transactions.