Fabrice Drouin [ARCHIVE] on Nostr: 📅 Original date posted:2018-10-12 📝 Original message: Hi Zmn, > It may be ...

📅 Original date posted:2018-10-12
📝 Original message:
Hi Zmn,

> It may be reduced to a set reconciliation problem if we consider the timestamp and enable/disable state of channel updates as part of an item, i.e. a channel update of 111:1:1 at 2018-10-04 state=enabled is not the same as a channel update of 111:1:1 at 2018-10-05 state=disabled.
>
> Then both sides can use standard set reconciliation algorithms, and for channel updates of the same short channel ID, we simply drop all items except the one with latest timestamp.
>
> The above idea might be less efficient than your proposed extension.

Yes there may be some way use the structure of channel_update messages
to transpose this into a set reconciliation problem, and use smarter
tools like IBLTs. But we would need to have a good estimate for the
number of differences between the local and remote sets. This would be
the really hard part I think, and probably even harder to get right
with channel_updates than with channel_announcements. I had a quick
look at how this type of sync issue is handled in different contexts
and my impression is that exchanging and and comparing timestamps
would be the most natural solution ?

But mostly my point is that I think we missed something with the
current channel queries, so first I would like to know if other people
agree with that :) and propose something that is close to what we have
today, should be easy to implement if you already support channel
queries, and should fix the issue that I think we have.

Thanks,
Fabrice