BIP157 doesn't have the same problem as the I/O required is proportional to what is sent over the network
jnewbery: sure, though I think with 10 blockers in high prio we're kind of pushing it
+1 on 15934
(but agree the list is getting long)
Ok, so any thoughts on the maximum size of filter messages we send (ignoring the BIP)?
wumpus: how about if I promise to review some of the other ones? :)
wumpus, people have different interests in subtopics, i dont think "long" hurts more than too many type collsions
instagibbs: 10 is fine
I've been making fine progress on the things that depend on #16766, so am OK with either removing from high priority while it gets more review or else I think it's basically mergeable now.
I guess it's fine for post meeting; but I wanted to get examples/edge cases people know of bad mempool behaviors that justify the limits currently and collect any tests people have written to benchmark this
Because I think there's a bit of a documentation gap for why certain limits exist and the intended protection (or, if additional protections conferred became known post-hoc)
Unfortunately lots of mempool design is communal knowledge spread among like 5 people.