Matt Corallo [ARCHIVE] on Nostr: 📅 Original date posted:2022-05-26 📝 Original message: Oops, sorry, I don't ...

📅 Original date posted:2022-05-26
📝 Original message:
Oops, sorry, I don't really monitor the dev lists but once every few months so this fell off my plate :/

On 4/28/22 6:11 PM, Rusty Russell wrote:
> Matt Corallo <lf-lists at mattcorallo.com> writes:
> OK, let's step back. Unlike Bitcoin, we can use a single sketch for
> *all* peers. This is because we *can* encode enough information that
> you can get useful info from the 64 bit id, and because it's expensive
> to create them so you can't spam.

Yep, makes sense.

> The more boutique per-peer handling we need, the further it gets from
> this ideal;.
>
>> The second potential thing I think you might have meant here I don't see as an issue at all? You can
>> simply...let the sketch include one channel update that you ignored? See above discussion of similar
>> rate-limits.
>
> No, you need to get all the ignored ones somehow? There's so much cruft
> in the sketch you can't decode it. Now you need to remember the ones
> you ratelimited, and try to match other's ratelimiting.

Right, you'd end up downloading the thing you rate-limited, but only once (possibly per-peer). If
you use the total-sync approach you'd download it on every sync, vs a "only updates" approach you'd
do it once.

>> I agree there should be *some* rough consensus, but rate-limits are a locally-enforced thing, not a
>> global one. There will always be races and updates you reject that your peers dont, no matter the
>> rate-limit, and while I agree we should have guidelines, we can't "just make them the same" - it
>> both doesn't solve the problem and means we can't change them in the future.
>
> Sure it does! It severly limits the set divergence to race conditions
> (down to block height divergence, in practice).

Huh? There's always some line you draw, if an update happens right on the line (which they almost
certainly often will because people want to update, and they'll update every X hours to whatever the
rate limit is), then ~half the network will accept the update and half won't. I don't see how you
solve this problem.
> Maybe. What's a "non-update" based sketch? Some huge percentage of
> gossip is channel_update, so it's kind of the thing we want?

Oops, maybe we're on *very* different pages, here - I mean doing sketches based on "the things that
I received since the last sync, ie all the gossip updates from the last hour" vs doing sketches
based on "the things I have, ie my full gossip store".

Matt