Those are default behavior of Bitcoin Core, so i don't understand why other node would determine it as a spam.
Ordinals are also allowed by "default behavior of Bitcoin Core", but they are filtered by some mining pools anyway.
data carrier:
https://github.com/bitcoin/bitcoin/issues/27043bare multisig:
https://github.com/bitcoin/bitcoin/pull/28217In general, if you make for example 1-of-20 multisig, then guess what: you need a single valid key, and the rest 19 keys can be used, just to push some data.
And in case of OP_RETURN, the 80-byte limit is no longer a problem, because there are pools accepting more than that. So, obviously, it is used as a faster way of spamming, because then, you can put your spam inside some output, instead of input (which is needed to put more spam, if you want to send a lot of short messages, because then, it may be cheaper than Taproot, if your data is between zero and a few hundred bytes).
Also, bare multisig can be used to slow down verification, and to increase the number of sigops in a given block. And both issues can be used, to get some advantage over another mining pool, which may be unaware of that, and include those transactions, and losing some time or fees by doing that.
Good point. I'm aware Bitcoin Knots (full node software) and Ocean (mining pool) have option to exclude Ordinals. Although they're in minority who actually put effort to partially deny Ordinal. GitHub Links you included mentioned token protocol which use P2MS, but that protocol plan to move from P2MS and token hype on Bitcoin blockchain have reduced. So IMO there's no strong reason to refuse TX with bare multisig now.
1. You don't have complete mempool / unconfirmed transactions. It mainly hurts those who run blockchain analysis or block explorer though.
2. For miner/pool, you could earn slightly less Bitcoin.