On 4/22/22 6:40 PM, Rusty Russell wrote:
Matt Corallo <[email protected]> writes:
Allowing only 1 a day, ended up with 18% of channels hitting the spam
limit. We cannot fit that many channel differences inside a set!
Perhaps Alex should post his more detailed results, but it's pretty
clear that we can't stay in sync with this many differences :(
Right, the fact that most nodes don't do any limiting at all and y'all have a
*very* aggressive (by
comparison) limit is going to be an issue in any context.
I'm unable to find the post years ago where I proposed this limit
and nobody had major objections. I just volunteered to go first :)
I'm not trying to argue the number is good or bad, only that being several orders of magnitude away
from everything else is going to lead to rejections.
We could set some guidelines and improve
things, but luckily regular-update-sync bypasses some of these issues anyway -
if we sync once per
block and your limit is once per block, getting 1000 updates per block for some
channel doesn't
result in multiple failures in the sync. Sure, multiple peers sending different
updates for that
channel can still cause some failures, but its still much better.
Nodes will want to aggressively spam as much as they can, so I think we
need a widely-agreed limit. I don't really care what it is, but
somewhere between per 1 and 1000 blocks makes sense?
I don't really disagree, but my point is that we should strive for the sync system to not need to
care about this number as much as possible. Because views of the rate limits are a local view, not a
global view, you'll always end up with things on the edge getting rejected during sync, and, worse,
when we eventually want to change the limit, we'd be hosed.
But we might end up with a gossip2 if we want to enable taproot, and use
blockheight as timestamps, in which case we could probably just support
that one operation (and maybe a direct query op).
Like eclair, we don’t bother to rate limit and don’t see any issues with it,
though we will skip relaying outbound updates if we’re saturating outbound
connections.
Yeah, we did as a trial, and in some cases it's become limiting. In
particular, people restarting their LND nodes once a day resulting in 2
updates per day (which, in 0.11.0, we now allow).
What do you mean "its become limiting"? As in you hit some reasonably-low
CPU/disk/bandwidth limit
in doing this? We have a pretty aggressive bandwidth limit for this kinda stuff
(well, indirect
bandwidth limit) and it very rarely hits in my experience (unless the peer is
very overloaded and
not responding to pings, which is a somewhat separate thing...)
By rejecting more than 1 per day, some LND nodes had 50% of their
channels left disabled :(
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? 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.
Matt
_______________________________________________
Lightning-dev mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
