On 5/26/22 1:25 PM, Rusty Russell wrote:
Matt Corallo <[email protected]> writes:
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.
The update contains a block number. Let's say we allow an update every
100 blocks. This must be <= current block height (and presumably, newer
than height - 2016).
If you send an update number 600000, and then 600100, it will propagate.
600099 will not.
Ah, this is an additional proposal on top, and requires a gossip "hard fork", which means your new
protocol would only work for taproot channels, and any old/unupgraded channels will have to be
propagated via the old mechanism. I'd kinda prefer to be able to rip out the old gossip sync code
sooner than a few years from now :(.
If some nodes have 600000 and others have 600099 (because you broke the
ratelimiting recommendation, *and* propagated both approx the same
time), then the network will split, sure.
Right, so what do you do in that case, though? AFAIU, in your proposed sync mechanism if a node does
this once, you're stuck with all of your gossip reconciliations with every peer "wasting" one
difference "slot" for a day or however long it takes before the peer does a sane update. In my
proposed alternative it only appears once and then you move on (or maybe once more on startup, but
we can maybe be willing to take on some extra cost there?).
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".
But that requires state. Full store requires none, keeping it
super-simple
Heh, I'm surprised you'd complain about this - IIUC your existing gossip storage system keeps this
as a side-effect so it'd be a single integer for y'all :p. In any case, if it makes the protocol a
chunk more efficient I don't see why its a big deal to keep track of the set of which invoices have
changed recently, you could even make it super efficient by just saying "anything more recent than
timestamp X *except* a few exceptions that we got with some lag against the update timestamp".
Better, the state is global, not per-peer, and a small fraction of the total state of the gossip
store anyway, so its not like its introducing some new giant or non-constant-factor blowup.
Matt
_______________________________________________
Lightning-dev mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
