Christian Decker [ARCHIVE] on Nostr: 📅 Original date posted:2019-09-18 📝 Original message: ZmnSCPxj via ...
📅 Original date posted:2019-09-18
📝 Original message:
ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org>
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
📝 Original message:
ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org>
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