NACK. There's no universal way to filter all present and future datacarrying styles. This invites an endless cat and mouse game inside very critical code paths.

It seems better if you just keep this patch for Knots, or alternatively, come up with a generic design to filter transactions. E.g. by loading rules from a file in some template language.

Just to set expectations, I might also NACK such a generic arbitrary filtering system, given the can of worms it would open, but I'd have to think about that more.

This does not meet the bar for "good". If only Ocean pool uses this and it remains a relatively small pool, it will have no effect. If it is widely deployed, it's trivial to circumvent, which will cause this code to grow in complexity. And every time that happens there'll be a lot of pressure on maintainers to push it through quickly "to stop the spam". It's just a matter of time before some DoS vector accidentally makes it in.

For example you're currently looking for this pattern, used for inscriptions:

OP_FALSE OP_IF spam OP_ENDIF This pattern fits about 1000 data pushes with each a max of 520 bytes, so 520 KB, per output.

If this PR were widely deployed, the pattern could be changed as follows:

OP_TRUE OP_IF spam OP_2DROP … OP_2DROP So the "spammers" now need to use up to 500 OP_2DROP codes so the stack is empty again, reducing the capacity to 515 KB. This time the code is actually executed by nodes, which is (slightly?) worse.

Next move?