Good point about individual choice. That's ignored entirely too much in this discussion.

However, censoring all spam from the **timechain** going forward through filters, is not gonna work. Putting some pressure on it through simple OP_RETURN settings may help, or running a massively filtered implementation of the Bitcoin software. But if you want it relatively absent from the timechain completely, we're talking a consensus rules change... and a new exploit might be found again anyway or an old one made worse.

To me the only effective solution that is also ethical and LONGLASTING, is that everyone gets to run their own OP_RETURN policy and filters and such, which they already do (but I can see the argument that this change to Core will sneak a lot stuff in without proper discussion or consideration of the purpose of the network and the reason for running the node, which violates some of the expectations some noderunners have, shame on you guys for not having a good faith discussion about the ethics here),

AND that the discussion converges on a further way to make spam ***COSTLY***, WITHOUT incentivizing slipstream to the point that it becomes the de facto method of bitcoin transaction submission. No one in the mainstream discussion I have seen has yet discussed methods of doing this simple approach in enough detail to understand what the tradeoffs are, where the sweet spot might be, how long the default OP_RETURN could be to allow arbitrary data, how to make OP_RETURN the default way of inputting arbitrary data so that spam costs a full vbyte, or other similar kinds of tweaks that individual users can make and that Core can make as the current de facto Bitcoin implementation.