Then maybe it's time to propose change. Perhaps start off this forum, talk about it in Bitcoin Core's github, and if you see recognition submit a BIP. One thing's for sure. You are not going to change anything if you continue calling it "Ordinal attack" in an Internet board.
That's a good suggestion. An anonymous user called shoalinfry did it before, https://bitcointalksearch.org/topic/moving-towards-user-activated-soft-fork-activation-1805060
Why not one of the more technical people in the forum? That's how some changes are heard, with enough support from the community.
I would like to hear it as well... Would be nice to get a summary of how Core maintainers and contributors have been approaching the subject and what - if any - changes to the code have been suggested.
I believe they would be the same as us in BitcoinTalk - mixed reactions from both sides of the debate.
not only limit length, but have conditions of content. and limit how many outputs can be this kind of non bitcoin address opcode(opreturn)
opcodes left "open"(lack of conditions to allow upgrades later(nulls, nops, opsuccess, [insert ur buzzword])). can also have a condition of
if blockversion >known ruleset version, treat as isvalid, else reject.
thus anyone using the opcode before actual rules are applied to the content(before a consensus upgrade).. the tx gets rejected. however when an upgrade happens in consensus to change the block version then old nodes would "isvalid" it when not knowing the content