The conversation still mostly isn't about having a version of bitcoin that sets a limit on op_return size that will validate. This actually the sane path for everyone. With no limits everyone will prune because the chain will be too big. Then the arbitrary data people will be forced to use another method because op_return has effectively been removed.

Replies (23)

No one on the Core team or who supports this change understands game theory or can put themselves in someone else's shoes. Why give up the witness discount in the first place? Only people who want to put data too big for that field would do that. Who will run a full archive node with unlimited op_return size? Only well funded commercial node runners and not even all of them. Why pay to use bitcoin but use the field that no one stores? I wouldn't pay full weight just to have everyone delete it immediately, that's stupid. I get shitcoiners asking for this. The VCs just need it to work long enough for a new round of rug pulls. They don't give a flying fuck about the long term health of the network. There should be a limit on what blocks validate. Don't get distracted by their misdirection to argue about mempool accuracy.
There is currently no size limit op_return your node won't consider a valid block. Currently it is only enforced by not being passed in mempool. Anyone can go straight to a sympathetic miner and drop 100Mb op_returns into every block. That means there is no such thing as a "full block" Want proof? Go look at Loops timeline and see that one of the first things they did was push an op_return 4x the current "limit" then brag about it.
Were crawling at like a couple GB per week now it seems right? I haven't looked too closely but it's not getting any smaller lol. You can't really, or shouldn't run a pruned node when running a lightning node. You still need to setup a full node then sync LN then you can prune, but if you're going to need the storage space at least once, why not keep it forever?
It is over the op_return "limit" I think I worked it out. Tell me if I missed the mark. The only real limit has always been total block size. Any TX limits or part of block limits were always a gentleman's agreement.
Lucid's avatar
Lucid 9 months ago
That's a lot for my smooth brain
Why fork the codebase if you aren't going to put consensus limits on open_returns then? Based on my current understanding this change doesn't seem like a big deal. I want mempool on my node to show me the competition for the next block as accurately as possible. Now that this has become as popularized as it has, with core changing, anything on your side is purely symbolic. Even if core drops the PR, arbitrary data fans will use miner accelerator APIs and do it anyway. Core still ran the worst public relations campaign I have seen in a long time, but that is a separate issue.
If you run knots your mempool won't relay op_returns over I think 80 last I checked. If you don't relay you make it harder for them to use op_return than a simple TX broadcast. If Transactions are missing from your mempool you have an innacurate view of the existing transactions you are bidding against. That is especially bad for automated actions taken by your lightning node.