Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2022-04-27 📝 Original message: Matt Corallo <lf-lists at ...
📅 Original date posted:2022-04-27
📝 Original message:
Matt Corallo <lf-lists at mattcorallo.com> 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.
📝 Original message:
Matt Corallo <lf-lists at mattcorallo.com> 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.