As someone who doesn't have a strong understanding of what mempool is, what are the benefits of not allowing a node runner to filter out OP_RETURN and what are the benefits of filtering / configuring it?

Am I even framing the question correctly?

I would like to hear from core 30 ppl because so far knots seems reasonable and I see a lot of "you're a retard" coming from the other side.

Reply to this note

Please Login to reply.

Discussion

I don’t think there are benefits in not “allowing” node runners to filter out OP_RETURN, but Bitcoin Core developers also have no obligation to add configurable options in their software. Their code is already free and open source; anyone can fork and change it if they feel that would be an improvement. (Or just not upgrade.)

I don’t believe there are any real benefits in filtering OP_RETURNS from your mempool though.

I'll try to answer that one:

The benefits are mostly for the node runner himself:

He gets better fee estimation, and can verify a mined block more quickly because he doesn't have to request the previously filtered TXs from the network.

The sum of those benefits, applied over all nodes, increase the decentralization (better fee estimation), speed and reliability (fewer orphaned blocks) of the network as a whole. Which is part of why core wants it as a default.

Another part of why core want it is, that their code base becomes clearer and smaller, making it less prone to bugs and cutting dev overhead.

IMHO the split between core vs knots happens along the axis of "the right thing" vs "the possible thing". Knots side wants to fight spam because it's The Right Thing™ (I think they're right), core knows that's going to be a losing battle (I think they're right, too), which they will have to fight with their few resources, constantly updating filter rules and distributing them, in a non-centralizing way, against VC funded attackers.

That's the gist of it.

So in short: while the filteroooors have moral on their side, the cooores have the technically more sound arguments. My personal stance, for what it's worth, is siding with core, while regretting that core cannot seem to take at least a clear social stance against the attackers. They should at least ostracize them. But who knows why they don't do it? In my talks with core devs, I was usually surprised how many steps they were thinking ahead. They may have good reasons.

This is the best explanation and aligns exactly with how i understand and view it. I do not disagree on running knots though i can't really say how much of a burden it would be on the network if we still have to toss around the blocks with 100kb OP_RETURNS in them after a block has been mined. I guess we'll have to see.

Knots is the protest sign that gives a signal but can just be walked around and ignored.

Here's the neat part: We won't even have to toss 100kB OP_RETURNs around, because those are way too expensive. At around 130 bytes or so, using fake scripts (aka inscriptions IIUC) in the witness becomes cheaper.