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.
Login to reply
Replies (23)
They'll use witness data and it will live in your node forever.
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.
If blocks are full then the data storage is the same. Whether it's all op_return or not.
Block validation is consensus, not mempool policy.
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.
So you're saying we already have big blocks with no limit? Got any code files I can verify against?
Alternatively, drop a 100MB block here:
Slipstream | MARA Holdings, Inc.
So youre saying spammers have accomplices and we should enable both of them?
??? 

Help me understand this then? I want to be right, even if it means changing my mind. I suspect that isn't true of everyone posting about this.


The Mempool Open Source Project®
Explore the full Bitcoin ecosystem with The Mempool Open Source Project®. See the real-time status of your transactions, get network info, and more.
So you're going to Knots?
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?
I already run knots
I'm not sure what you're referencing in this transaction?
What about when Knots becomes compromised?
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.
Yup! That's my understanding. Hence the 4MB JPEG of a wizard in one of the blocks.
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.
That would be a hard fork, no thnx. Need my node in consensus.
And i'd rather not spammers use non-pruneable parts of the tx like witness data.
Then why run a mempool that makes it harder for them to use op_return and gives you an inaccurate view of pending transactions?
I don't?
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.