Just did a little sleuthing on the OP_RETURN > 83 bytes from @oomahq
's post (https://x.com/oomahq/status/1916793928025596338).
There were 30 such transactions in the ~4 month period:
8 had reasonable fees (< 2x the median for the block)
11 had around double fees
7 had around triple fees
4 had 5x-8x fees
9 were mined by F2Pool (10-11%)
21 were mined by Mara (6-7%)
So in general, the OP_RETURN filter means the non-standard transactions were on average paying a good deal more than normal transactions to get into a block. And since only about 18% of the hashing power seems to mine them, they had to wait 5-6x longer to confirm.
If the point of filters is to make spamming cumbersome and costly, I'd say that they're doing their job. TX IDs in the first comment so you can look for yourself.
30 Tx over 4 months is not something to be concerned about in terms of your mempool accuracy. Smaller miners aren't missing out on a tonne of fees either.
This suggests to me that increasing the OP_RETURN is more about some other functionality that it would enable.
I do think it's about using the timechain to store data, but probably not monkey JPEGs.
Could also say that 30 tx over four months indicates that the threat of spam taking over is overblown.
Sure - it's probably over blown.
We also don't know what it would be used for & where it could go.
The ordinals bullshit was the unintended consequence of a widespread change to the validator software.
Yeah, I'm worried about unintended consequences too. I think the best way to approach this would be to keep the default filter as is and allow node runners to set it themselves. Then a small group of nodes could experiment with removing the limit and monitor the effects. If spam starts to become a problem they could reinstate filters and rug pull the spammers.
