I fully subscribe to what you wrote.
But I fail to see (1) increasing the limit on the data within OP_RETURN ,and (2) removing the right of node operators to manually change this limit, as any logical direct consequence of anything you wrote above
And I’ll be happily corrected for whatever I’m missing
removing the filtering entirely unifies the network, where some nodes and miners didn't see entire classes of valid transactions.
unification of the network is important when considering potential issue that lead to forks or attacks that cause forks on purpose.
removing the right to configure this is also a consideration towards this end. We don't want people to self segregate. Division among nodes when that division is not consensus is not good. It doesn't help anything. It doesn't stop the spam. It just divides us up and the spam causes more issues elsewhere, not on your node today but on all nodes tomorrow (UTXO bloat)
OP_RETURN consensus limits aren't changing. The reason why mempool policies are changing isn't to make it easier for these transactions to propagate but in order for the mempools to reflect better what the next block is going to look like.
Nobody removes your right for anything. You can run Knobs if you think that's important for you. Knots however is a dangerous psyops and unreviewed pile of burning trash. I advice against it but you do you.
If the majority of nodes aren't relaying them to other nodes (current state), how will the miner receive the transaction? Unless it's relayed directly to the miner node ala LibreRelay.
Let's say 5% are running Core v30 and 95% are running Core v29. What are the odds a spam tx gets relayed to the miner node that hits the next block?
If one was running v30 with the new default datacarriersize, but the majority were on older versions, wouldn't it be the v30 node who's fee estimates would be off?
great question, somewhere between 30% and 100% https://x.com/murchandamus/status/1971647746299121773/photo/1
