BIP 110 allows OP_RETURN up to 82 Bytes for legitimate uses which using that limited space can't abuse Bitcoin. The Coretard (who actually tried to act neutral in the article he wrote 🤡) says basically instead of putting 8 KB spam or 80KB spam in one OP_RETURN he can put it in 100 or in 1000 which will cost him 100x or 1000x more which then will really disincentify spammers. BIP 110 is really good solution to reduce big data spam abuse on Bitcoin. From the BIP 110 specification: New output scriptPubKeys exceeding 34 bytes are invalid, unless the first opcode is OP_RETURN, in which case up to 83 bytes are valid. OP_PUSHDATA* payloads and script argument witness items exceeding 256 bytes are invalid, except for the redeemScript push in BIP16 scriptSigs. Spending undefined witness (or Tapleaf) versions (ie, not Witness v0/BIP 141, Taproot/BIP 341, or P2A) is invalid. (Creating outputs with undefined witness versions is still valid.) Witness stacks with a Taproot annex are invalid. Taproot control blocks larger than 257 bytes (a merkle tree with 128 script leaves) are invalid. Tapscripts including OP_SUCCESS* opcodes anywhere (even unexecuted) are invalid. Tapscripts executing the OP_IF or OP_NOTIF instruction (regardless of result) are invalid. https://github.com/bitcoin/bips/blob/master/bip-0110.medi…