From decker.christian at gmail.com Wed Sep 18 13:52:46 2019 From: decker.christian at gmail.com (Christian Decker) Date: Wed, 18 Sep 2019 15:52:46 +0200 Subject: [Lightning-dev] Avoiding gossip spam: how many updates do you need? In-Reply-To: References: <87zhjji5xu.fsf@rustcorp.com.au> Message-ID: <87blvhognl.fsf@gmail.com> ZmnSCPxj via Lightning-dev writes: >> But it is perfectly fine to use ***zero*** routing fees, I think. > > Briefly: if a channel has too much liquidity on your side, passively > rebalance by broadcasting a `channel_update` with 0 routing fees. > This helps JIT-Routing of nearby nodes as it allows cheaper rebalances > to support. This falls a bit outside of the scope of `channel_update`s if you ask me. `channel_update`s are meant to communicate coarse grained information about the channel to the rest of the network. They are not meant to communicate in a local group of nodes. I'd rather have a `local_channel_update` that has a small TTL counted down on each hop to limit its spread for this kind of communication. That local update can then also bypass the rate-limiting. > Of course, it is still desirable to rate-limit such updates. > So we can do the below policy: > > 1. Maintain a "latest broadcast is zero" flag. > 2. If the channel has been >=75% in your favor for more than 10 minutes (or whatever configuration you want), and the "latest broadcast is zero" flag is cleared, set it and broadcast a 0-fee `channel_update` and set your feerate to 0. > 3. If the channel has been <75% in your favor, set your feerate to non-zero, but do not broadcast (meaning "latest broadcast is zero" flag does not change). > 4. If the channel has been <75% in your favor for more than 10 minutes, and the "latest broadcast is zero" flag is set, clear it and broacast your normal `channel_update`. > > However this will probably still lead to more than a burst of 4 `channel_update`s per day. This is way more logic to add to an already complex set of rules. I'd prefer having separate negotiation logic for the scenarios you propose. `channel_update`s are coarse-grained on purpose and a really large hammer that is not well-suited for tiny adjustments like rebalancing. This is also the reason why I advocated for active rebalancing over indirect signalling through negative fees. Notice that you can still allow zero-fee forwarding by using local updates as offers and then referencing the offer in the onion, without telling the wider world about the balances in your channel, and without having to deal with someone using that zero-fee much later than you needed it. Cheers, Christian