We could standardize them and make sure the node can interpret it, otherwise node rejects it as invalid (maybe?) Just my own selfish thoughts, I'm happy to pay money for more hardware to store money transactions, it's in my own interest for the money use case to grow, but if half my cost is just storing other people's images for free, I'm not interested in that and would want to reject all of it from my node or maybe it gets even worse and I just give up on node running

That is a wrong avenue. There is a movie called "What's a woman?" and because of their agenda some people can't answer that simple question. It is known what is monetary transaction data like it is known what is IP data for the IP protocol. The creators of The Internet did not allow to put jpegs in the IP field.

“You don’t know” “Why do you care” Dismissiveness reminiscent of the American Left I understand the point you’re trying to make but this has been a bad look

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.

This isn’t about one-off transactions. It becomes quite clear, very quickly, what VC spammers are doing and thus easy enough to filter their transactions. Taking an adversarial stance against this data storage garbage would quickly kill large scale future spammers due to the risk involved. They would fuck off back to solana or wherever