Bitcoin is Freedom Money.
Not a spam, csam, jpegs or any other arbitrary data dumpster.
By blowing up OP_RETRUN you invite more of it and you support that. That makes you a spammer.
Of course your bs propaganda speaks volumes too.
Here is Nick Szabo answer for you.
If it’s cheaper to other methods for some types of spam op return size is irrelevant.
If some types of spam is going to pollute the utxo set if it can’t use op return because of its size it is preferable to increase the op_return size than to encourage utxo bloat.
That is why there is this soft fork bip that fixes a lot of weaknesses that are exploited from spammers 🤙
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* with payloads larger than 256 bytes are invalid, except for the redeemScript push in BIP16 scriptSigs.
Spending undefined witness (or Tapleaf) versions (ie, not Witness v0/BIP 141 nor Taproot/BIP 341) is invalid.
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.
It doesn’t fix all spam vectors so all this means is more transactions and more utxo pollution. To fix all spam vectors you will have to destroy any hope of bitcoin scaling and multisig….and even then spam will find a way.
The reactive activation chaotic chain reorg portion is the most retarded thing I have read in a bip. Anyone supporting this will be outed as a glowie or a useful idiot. Which one are you?
