From rusty at rustcorp.com.au Wed Apr 27 06:53:50 2022 From: rusty at rustcorp.com.au (Rusty Russell) Date: Wed, 27 Apr 2022 16:23:50 +0930 Subject: [Lightning-dev] Gossip Propagation, Anti-spam, and Set Reconciliation In-Reply-To: References: <87ee1pj1tj.fsf@rustcorp.com.au> <87czh8h90j.fsf@rustcorp.com.au> Message-ID: <87h76f10g1.fsf@rustcorp.com.au> Matt Corallo 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.