Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2022-04-22 📝 Original message: Matt Corallo <lf-lists at ...

📅 Original date posted:2022-04-22
📝 Original message:
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 :)

> 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?

Normally I'd suggest a burst, but that's bad for consensus: better to
say "just create your update N-6 blocks behind so you can always create a
new one 6 blocks behind".

>>> 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 :)

I agree. Removing features would be nice :)

>> 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.

Cheers,
Rusty.