Fair point, yet I think it would be reasonable to think that the broad categories of techniques that allow storing arbitrary data on chain can be outlined. I would imagine that everyone agrees that having to generate a trillion private keys until one is found that, when a bech32m address is created from it, has its first 5 characters after the human readable part be interpreted as the first bytes of some jpeg is quite more cumbersome than OP_FALSE OP_IF, right? I believe not much would change in terms of actual transaction composition, in both mempools and blocks, even if v30 were to be broadly adopted - which does not seem the case to be honest - yet I cannot quite accept the idea that, since in principle spam cannot be prevented entirely, nothing should be done about it.

> I would imagine that everyone agrees that having to generate a trillion private keys until one is found that... Yes, there are easier ways to spam than others. > I cannot quite accept the idea that, since in principle spam cannot be prevented entirely, nothing should be done about it. I understand your position, and I too am not sure what is the correct path. The variables at play are: - how damaging is the spam - how effective are the anti-spam measures, at both technical layer and social layer (e.g. discouraging future spam because old spam was killed) - how much effort, and technical complexity is introduced in trying to keep up with spam I'm terms of software preference, I would not be willing to introduce all that growing complexity to half solve a problem. Mostly becaus I don't think this spam is doing much damage