On 4/21/22 7:20 PM, Rusty Russell wrote:
Matt Corallo <[email protected]> writes:
Sure, if you’re rejecting a large % of channel updates in total
you’re gonna end up hitting degenerate cases, but we can consider
tuning the sync frequency if that becomes an issue.
Let's be clear: it's a problem.
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. 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.
gossip queries is broken in at least five ways.
Naah, it's perfect if you simply want to ask "give me updates since XXX"
to get you close enough on reconnect to start using set reconciliation.
This might allow us to remove some of the other features?
Sure, but that's *just* the "gossip_timestamp_filter" message, there's several other messages and a
whole query system that we can throw away if we just want that message :)
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...)
Matt
_______________________________________________
Lightning-dev mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
