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.
Replies (1)
> 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
