Nodes set mempool policies for their own mempool.
A matter is not a non-issue if parties have an issue. Why not lower the node default limit instead of raised (or eliminated) if it is a non-issue?
Obviously some do care.
For anyone not aware nostr:nprofile1qqsve2jcud7fnjzmchn4gq52wx9agey9uhfukv69dy0v4wpuw4w53nqpzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtcuseaka PR to remove the filter entirely was NOT merged. A PR was merged an hour ago to uncap the limit but keep the filter. Core kept an unnecessary filter (imo) to appease plebs and they're still going to be mad about this non issue.
I'll admit I'm wrong when you show me how your filter can stop my transaction from propogating through the network.
News flash, it can't and if it could then Bitcoin would be useless. Read that again. "...your filter can stop my transaction..."
That's NOT something we want in Bitcoin. No matter what you think spam is or isn't. Bitcoin should be uncensorable period. Luckily for everyone, it is. Let them waste generation wealth on silly pictures and just leave it alone. Bitcoin is fine.
Discussion
I believe it's a non-issue because the detractors motivations for setting that policy are inconsequential to the results. It doesn't matter if you raise or lower it that's the whole argument.
The argument to eliminate would be precisely because it doesn't do anything in practice with the actual network only to the local nodes Mempool. The reason detractors do not want it and their mental are not performance related. Their motivations are altruistic. Bitcoin is software. Computers don't care about your altruism. Does the filter meaningfully impact node performance or hardware requirements? Does it change the network?
If the answer is no to both, then data carrier filtering is useless code. If it's useless code it should be removed from core, the reference implementation, and if users want to just truly be altruistic they can run a fork or not update and keep using the filter (If it were removed which it isn't...)
Carving out the subjective pro/con arguments (meaningful vs. useless,) then ask, is the limit important enough to move to a consensus-level check (i.e. required to be passed to be included in the block)? The argument to remove it because it’s “useless code” bypasses the intent of the code, which should be addressed.
The code does what it intends on doing. It filters transactions from your personal mempool. What is the effect of the code on the network?
Nothing.
Because your personal mempool has no effect on what gets mined.
If I'm wrong or you disagree, explain how.
We should remove code from the repo that does nothing in practice.
A consensus level change is a hard fork. You can count me out. I'll lean to sell the fork, but will keep them for a couple months. The winner will probably be clear by then. If the fork coin does not outprice the original in that time frame, it never will.
Code we don’t see as effective sometimes is effective or beneficial for some when the network is operating in the extreme or when concentration occurs.
Even not in the extreme, measuring the effectiveness of something should follow if it does what it is meant to do, and in this case it is meant to stop a node from recognising/relaying a transaction over the limit.
Agreed on the hard fork point.
side note:
modulo is pretty sick. Thanks for making it.
Thanks—a lot of work went into making the modulo key. Being physical it unexpectedly gives positive vibes.
I’d zap you some thanks but I get errors fetching your invoice for some reason.
I’ll think about a response to your response.