Let nodes decide what filters to set or not set. Knots allows this. Core, like the nanny state, does not.
Discussion
yeah except the knob doesn't do anything useful, but whatever makes you feel more righteous.
Filters are useful. And even if they weren’t, I’d rather have node runners decide than a small clique of Chaincode Labs devs. The fact that Core is forcing this change despite the controversy around it is very telling.
a knob that adjusts this setting won't stop the tx from getting into your node, but alright. you keep telling yourself that.
It doesn’t stop all, but it does stop most, like how all filters (email spam etc) work.
simply not true.
your node will then start relaying this CSAM to other nodes after it comes in a block, I don't see the point of a knob that does nothing except delay for 10 minutes.
this is still true even with 99.999% knots usage. people relaying this stuff won't be doing it through knots nodes.
There’s a difference between what ends up on the timechain and what I choose to accept in my mempool.
And with Core v30 lifting OP_RETURN limits to nearly 4 MB (a 50,000× increase) the risk of vast CSAM being permanently embedded becomes a much bigger issue.
what appears in your personal mempool has no impact on what will be accepted in a block.
My node alone won’t. But enough Knots runners and aligned miners (eg. Ocean) can shape what propagates. You choose defeatism. I do not.
Why isn't it there already then? Please don't say that it isalready there because someone chunked something up to look like utxos and spread it out across lots of transactions. If filters don't do anything why don't we already have big long strings of CSAM in the op return field? Don't say its because no one wants to upload it, someone already went through all the trouble of chunking it up to look like normal monetary transactions.
Why do they need to remove the knob though?
This is all retarded and I don’t trust anyone. One side has a bunch of shitcoiners and the other is a bunch of religious nuts…
because it doesn't do anything useful. mempool settings are incredibly niche for non-mining nodes, unless you are optimizing memory, but then you would just use the total mempool size setting.
I've been running a node since 2010 and I never once needed to tweak this, only ever mempool memory usage.
non-useful code is dead code and is a maintenance burden. non-useful code is also confusing to users who think tweaking the knob will actually do something.
Sorry but I don’t buy that excuse…
How much additional maintenance does allowing users flexibility to update settings on their node really require?
Just seems very suspect that this is the hill core devs are deciding to die on.
“Despite the controversy” - this is IMO the biggest issue here. Influencers making non-technically sound arguments should not be able to change the course of dev work
Historically, Core has only advanced non-controversial changes with broad consensus. Core v30 breaks that pattern. If you don’t think that sets a dangerous precedent, I don’t know what to tell you.
What’s more dangerous - influencers being able to force dev behavior to change, or the devs themselves?
yeah i think nostr:npub1r0fj5wr200n0dz9nm37ysrhuy8xeg66ratq5hf960q62caaz8e5sqpuzz3 believes bitcoin core is a democracy and that social media campaigns spawned by influencers can change dev direction. If that was the case then bitcoin would be a dumpster fire of bad decisions.
It actually does do something useful. It stops the relaying of a tx your node does not wish to relay. Just because a tx can still make it into the block does not make the relay data limit useless. It’s enforcing a policy set by the node runner and the version of code they run.
Bitcoin is a monetary network not a jpeg network. Just because Satoshi didn’t specifically say it’s for money only does not make all data equal. It’s a peer to peer e CASH system. Not a peer to peer insert whatever data you like system. I personally don’t care if people are relaying monkey jpegs but non-continuous CSAM is likely a real risk factor and a possible attack vector.