Matt Corallo <[email protected]> writes: >> This same problem will occur if *anyone* does ratelimiting, unless >> *everyone* does. And with minisketch, there's a good reason to do so. > > None of this seems like a good argument for *not* taking the "send updates > since the last sync in > the minisketch" approach to reduce the damage inconsistent policies > cause, though?
You can't do this, with minisketch. You end up having to keep all the ratelimited differences you're ignoring *per peer*, and then cancelling them out of the minisketch on every receive or send. So you end up doing that LND and core-lightning do, which is "pick 3 peers to gossip with" and tell everyone else to shut up. Yet the point of minisketch is robustness; you can (at cost of 1 message per minute) keep in sync with an arbitrary number of peers. So, we might as well define a preferred ratelimit, so nodes know that spamming past a certain point is not going to propagate. At the moment, LND has no effective ratelimit at all, so it's a race to the bottom. We need that limit eventually, this just makes it more of a priority. > I'm not really > sure in a world where you do "update-based-sketch" gossip sync you're any > worse off than today even > with different rate-limit policies, though I obviously agree there are > substantial issues with the > massively inconsistent rate-limit policies we see today. You can't really do it, since rate-limited junk overwhelms the sketch really fast :( Note, we *can* actually change the ratelimit in future, either by running two sketches (feature bit!), or by changing the rate slowly enough that they can handle the small differences. Cheers, Rusty. _______________________________________________ Lightning-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
