Published on: 2018-02-28T21:38:01+00:00
The Lightning Network developers are currently discussing different approaches to synchronizing gossip messages between nodes. One approach being considered is using a timestamp mechanism, while another approach favored by Rusty Russell is an Invertible Bloom Lookup Table (IBLT) approach. Rusty believes the IBLT approach is easier to maintain and update.To implement the timestamp mechanism, Christian suggests appending a `routing_sync_timestamp` field to the `init` message. He proposes that this field should be used to filter messages and retransmit old announcements based on the timestamp. However, Rusty argues that the peer would need to know how to skip 4 bytes for future fields, making this approach less desirable.In terms of retransmitting announcements, Rusty dislikes the idea of retransmitting all old `channel_announcement` and `node_announcement` messages due to recent `channel_update`. Christian suggests keeping a filter of received messages to solve this problem. He explains that c-lightning keeps a tree of gossip but not in timestamp order, so they need to actively filter and skip entries less than the `routing_sync_timestamp`.There are also discussions about when to stop retransmitting announcements and whether to remember which ones have been sent to each peer. Christian proposes using highwater and lowwater marks to forward messages within a time window. This would allow multiple `timestamp_routing_sync` messages for different time windows.Fabrice's proposal focuses on initial sync between nodes, specifically for mobile nodes that are often offline and need frequent resyncing. The proposal involves creating filters for channel announcements and using them to optimize learning of new channels. A new feature bit called `use_channel_announcement_filters` would be added along with a `channel_announcement_filters` message. Nodes supporting these filters would exchange and use them to improve the synchronization process.The lightning-dev mailing list discusses the need for a temporary solution to address initial sync issues. Christian proposes adding a new feature bit called `gossip_timestamp` to the `init` message. Laolu suggests using a new message instead of extending the `init` message. Fabrice's proposal focuses on newly created channels and uses an update horizon to filter out older announcements. The mailing list is open for further discussion and proposals.Christian and Fabrice propose a solution to fix initial sync issues while waiting for a more comprehensive sync protocol. They suggest using an optional feature bit to group channel announcements by "buckets" and create filters for each bucket. Nodes supporting these filters would exchange and use them to optimize learning of new channels. This proposal aims to address short-term issues during initial sync, without aiming for perfect synchronization between nodes.The author of the message explains that topology synchronization was initially postponed, and a trivial gossip protocol was implemented instead. They propose adding a new feature bit to extend the `init` message with a `gossip_timestamp`. This timestamp indicates the lowest channel_update and node_announcement timestamp to be sent. The author outlines the logic to forward announcements based on the gossip_timestamp. They also mention the possibility of creating a new `set_gossip_timestamp` message but note the potential for duplicate messages.Overall, the Lightning Network developers are actively exploring various approaches to synchronize gossip messages between nodes. They are considering the benefits and drawbacks of using a timestamp mechanism versus an IBLT approach. Deployment suggestions include appending a `routing_sync_timestamp` field to the `init` message and retransmitting old announcements based on the timestamp. The developers are also investigating ways to actively filter messages and optimize the synchronization process.
Updated on: 2023-07-31T19:43:53.904647+00:00