Published on: 2019-09-18T13:52:46+00:00
A Lightning Network developer has proposed a method of passively rebalancing channels by broadcasting a `channel_update` with zero routing fees if there is too much liquidity on one side of the channel. This approach would aid in Just-In-Time (JIT) routing of nearby nodes and allow for cheaper rebalances to support. However, it has been noted that this falls outside the scope of `channel_update`s, which are intended to communicate coarse-grained information about the channel to the wider network rather than a local group of nodes.To address this, a suggestion was made to use a `local_channel_update` with a small Time-To-Live (TTL) to limit its spread for this type of communication. Nonetheless, it is still important to rate-limit such updates. The user proposed maintaining a "latest broadcast is zero" flag and broadcasting a 0-fee `channel_update` if the channel has been >=75% in your favor for more than 10 minutes. However, it is expected that this approach may result in more than a burst of four `channel_update`s per day. Therefore, the user recommends implementing separate negotiation logic for these scenarios instead of adding complexity to the existing set of rules.The user also advocates for active rebalancing over indirect signaling through negative fees. They suggest using local updates as offers for zero-fee forwarding without disclosing the balances in your channel to the wider network. This approach aims to provide more control and flexibility in managing channel liquidity.In addition to these rebalancing strategies, the next release of c-lightning will introduce measures to suppress excessive gossiping. A simple filter will be implemented, allowing each message (node_announcement or channel_update) to be transmitted once on average per day, with a burst of up to four times per day. Duplicate gossip messages, except for the timestamp and signature, will be discarded. This filtering mechanism aims to prevent scaling issues in the future.Furthermore, other optimizations will be implemented to reduce gossip overhead. These include using gossip queries for backfilling instead of asking for the last 24 hours of gossip on startup, suppressing duplicate gossip and reply gossip, and issuing "refresh" updates only once every 13 days instead of the current seven. These measures are primarily motivated by a user who has an rPi on a 4G plan. The current process of restarting their node is cumbersome, necessitating the need for these new measures to improve their experience.
Updated on: 2023-07-31T21:53:55.108765+00:00