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.

Reply to this note

Please Login to reply.

Discussion

> 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