What's your counter to "if they cant use op_return then they will include it in the witness and thats worse because witness it cant be pruned and creates an unspenable output, further bloating the utxo set" ?
Discussion
Yeah am also curious about this in the discussion
This argument is a decoy.
1. It’s cheaper to spam in the SW
2. No guarantee that spammers voluntarily pay more to spam in the OP_RETURN
3. The people pushing this so called solution are the same people who created this problem.
The real agenda is to force as many node runners to relay their spam.
Right now they are only able to include these spammy txs in a small percentage of blocks. If all core node runners removed the limit on OP_RETURN size there would be significantly higher chances of their spam being included in blocks. This could also be used to throttle the network throughput ultimately lowering transactions per block.
#3 👌
1. It is not cheaper for all data sizes.
2. Some embed data in multiple fake key outputs. There is no stopping that. OP_RETURN gives them an alternative.
3. Not sure what you mean here, but I don't think any regular Bitcoin Core developer has gone and inflated the UTXO set with data?
Spammers are incentivized to use the witnessspacee, therefore removing a spam filter will only give them more opportunity to spam.
Witness data is counted at 1/4 of the data in the legacy part of the transaction. OP_RETURN lives in the non-witness scriptPubKey, so even if you allow arbitrary large OP_RETURN each byte still cost 4 weighted units, whereas the very same but pushed into the witness costs only 1 weighted unit.
Core knows this. They are compromised.