Matt Corallo [ARCHIVE] on Nostr: 📅 Original date posted:2022-04-24 📝 Original message: On 4/22/22 6:40 PM, Rusty ...
📅 Original date posted:2022-04-24
📝 Original message:
On 4/22/22 6:40 PM, Rusty Russell wrote:
> Matt Corallo <lf-lists at mattcorallo.com> 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
📝 Original message:
On 4/22/22 6:40 PM, Rusty Russell wrote:
> Matt Corallo <lf-lists at mattcorallo.com> 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