I should have said "relatively new" - 50 years minimum horizon, lol.
What do you think its primary purpose should be?
Disclaimer: never listen to a retard like me!
But since you are asking, I'd say that it depends on use-case.
No mempool. I agree with Gmax' argument that blocksonly is a perfect mode, for "leaf" nodes 1. Also, I feel that while a properly running relay node may help, a badly configured one or low-capacity node doesn't 2. If you're just looking to do your own validation of (low volume) utxos, no mempool is the best mempool, as you anyway don't want to zeroconf.
Knowing what's going on with your LN channels (or other pre-confirmation risk monitoring). Like I said above, for watchtowers you want to know as much as you can, even stuff that is unlikely to get mined 3. This is technically more permissive than being a reflection of what gets mined, especially when we see pool / template decentralization.
But we do need relays also without LN, because hub-and-spoke would be bad for centralization. For this, I'd say the mempool is basically your pre-validated set of transactions that you pass around, like a hot database of what you want to relay to others. This is the use case where - although not necessarily useful from where I'm sitting - filters could make sense if an operator feels strongly about it. Since someone filtering important transactions is a threat scenario that needs to be minimized no matter what, it shouldn't be too much of a problem when other operators do this.
Edit because I forgot: And as a stage for mining of course. I wouldn't filter my mempool if I were a miner/pool, but I'd definitely look to filter my inclusion rules.
Footnotes
it would be useful to have (degraded?) smartfee work when a node has only the block inclusion statistics, i.e. estimate based on what was mined only, without tracking confirmation time of seen->mined. I'm still building some test scenarios based on a discussion we had about this on SN a week or so ago and have promised to share anything I think can be improved (but I'm slow, sry.) ↩
In the past Ian Coleman had a simulator (pre-segwit, pre-compactblocks and now discontinued?) that illustrated the impact of more nodes on the network in terms of hops a tx would need to travel and what kind of data use we'd look at network-wide, which was interesting to play with. ↩
I've had the temptation to make my watchtower allownonstandard but since there were little/no peers with that and I felt there may be some risks I would miss and then not catch (don't want to be banned from all peers), I instead ran with a maximally permissive policy through config and a much-larger-than-default mempool (had thought of using librerelay instead.) Either way, this is why I feel configurability is very important. Someone may need it for a reason no one thought of. ↩
blocksonlyis a perfect mode, for "leaf" nodes 1. Also, I feel that while a properly running relay node may help, a badly configured one or low-capacity node doesn't 2. If you're just looking to do your own validation of (low volume) utxos, no mempool is the best mempool, as you anyway don't want to zeroconf.Footnotes
allownonstandardbut since there were little/no peers with that and I felt there may be some risks I would miss and then not catch (don't want to be banned from all peers), I instead ran with a maximally permissive policy through config and a much-larger-than-default mempool (had thought of using librerelay instead.) Either way, this is why I feel configurability is very important. Someone may need it for a reason no one thought of. ↩