You don't want arbitrary data, the solution is roll back and remove OP_RETUEN and Segwit.
Hard fork that will not succeed.
Even then there is probably a way.
Discussion
I can only dream of getting rid of Segwit lol I know it’ll never happen tho…
Why get rid of SegWit? It’s necessary for Lightning.
Lightning can still work with regular Bitcoin transactions.
But...
There would be transaction malleability where txid can be changed before confirming
The work around would be using only confirmed transactions.
It's hard to tell if there are other problems because we have to back up and think about how that would actually work in practice.
Arbitrary data has been possible on chain since the beginning more or less. There's no need to remove segwit or OP_RETURN to to filter spam, since older versions of CORE and the present version of Knots already accomplish that.
yea but... they don't....
Are you sure about that?
Yes, here is a dust tx I made. Non standard. Broadcast via regular rpc submission at a standard fee from my node.
I'll make an OP_RETURN that's non standard too if you would like for me to prove it.
Also ALL versions of core currently have the default filters still. Including OP_RETURN limit at 80 bytes
There is no version of core that's released that has a higher limit.
That's good.
Have I not demonstrated that they don't prevent concensous transactions?
I'm saying your statement is a good thing. I've been under the impression that the newest version of CORE has OP_RETURN limit removed, or something along those lines. But I stand corrected. "Also ALL versions of core currently have the default filters still. Including OP_RETURN limit at 80 bytes
There is no version of core that's released that has a higher limit."
I'm saying my statement shows why filters don't work and are unnecessary.
proof: https://mempool.happytavern.co/tx/58ae7a318f19c580b14d3547d6c65d1a417bbe8980189d34c61b2d4161741dfb