Alex Myers [ARCHIVE] on Nostr: 📅 Original date posted:2022-05-27 📝 Original message: > > The update contains a ...
📅 Original date posted:2022-05-27
📝 Original message:
> > 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 :(.
I viewed it as a soft fork, where if you want to use set reconciliation, anything added to the set would be subject to a constricted ruleset - in this case the gossip must be accompanied by a blockheight tlv (or otherwise reference a blockheight) and it must not replace a message in the current 100 block range.
It doesn't necessarily have to reference blockheight, but that would simplify many edge cases. The key is merely that a node is responsible for limiting it's own gossip to a predefined interval, and it must be easily verifiable for any other nodes building and reconciling sketches. Given that we have access to a timechain, this just made the most sense.
> > 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?).
This case may not be all that difficult. Easiest answer is you offer a spam proof to your peer. Send both messages, signed by the offending node as proof they violated the set reconciliation rate limit, then remove both from your sketch. You may want to keep the evidence it in your data store, at least until it's superceded by the next valid update, but there's no reason it must occupy a slot of the sketch. Meanwhile, feel free to use the message as you wish, just keep both out of the sketch. It's not perfect, but the sketch capacity is not compromised and the second incidence of spam should not propagate at all. (It may be possible to keep one, but this is the simplest answer.)
> 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".
The benefit of a single global sketch is less overhead in adding additional gossip peers, though looking at the numbers, sketch decoding time seems to be the more significant driving factor than rebuilding sketches (when they're incremental.) I also like maximizing the utility of the sketch by adding the full gossip store if possible.
I still think getting the rate-limit responsibility to the originating node would be a win in either case. It will chew into sketch capacity regardless.
-Alex
------- Original Message -------
On Thursday, May 26th, 2022 at 5:19 PM, Matt Corallo <lf-lists at mattcorallo.com> wrote:
>
> On 5/26/22 1:25 PM, Rusty Russell wrote:
>
> > Matt Corallo lf-lists at mattcorallo.com 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
📝 Original message:
> > 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 :(.
I viewed it as a soft fork, where if you want to use set reconciliation, anything added to the set would be subject to a constricted ruleset - in this case the gossip must be accompanied by a blockheight tlv (or otherwise reference a blockheight) and it must not replace a message in the current 100 block range.
It doesn't necessarily have to reference blockheight, but that would simplify many edge cases. The key is merely that a node is responsible for limiting it's own gossip to a predefined interval, and it must be easily verifiable for any other nodes building and reconciling sketches. Given that we have access to a timechain, this just made the most sense.
> > 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?).
This case may not be all that difficult. Easiest answer is you offer a spam proof to your peer. Send both messages, signed by the offending node as proof they violated the set reconciliation rate limit, then remove both from your sketch. You may want to keep the evidence it in your data store, at least until it's superceded by the next valid update, but there's no reason it must occupy a slot of the sketch. Meanwhile, feel free to use the message as you wish, just keep both out of the sketch. It's not perfect, but the sketch capacity is not compromised and the second incidence of spam should not propagate at all. (It may be possible to keep one, but this is the simplest answer.)
> 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".
The benefit of a single global sketch is less overhead in adding additional gossip peers, though looking at the numbers, sketch decoding time seems to be the more significant driving factor than rebuilding sketches (when they're incremental.) I also like maximizing the utility of the sketch by adding the full gossip store if possible.
I still think getting the rate-limit responsibility to the originating node would be a win in either case. It will chew into sketch capacity regardless.
-Alex
------- Original Message -------
On Thursday, May 26th, 2022 at 5:19 PM, Matt Corallo <lf-lists at mattcorallo.com> wrote:
>
> On 5/26/22 1:25 PM, Rusty Russell wrote:
>
> > Matt Corallo lf-lists at mattcorallo.com 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