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 _______________________________________________ Lightning-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
