Mark Friedenbach [ARCHIVE] on Nostr: 📅 Original date posted:2018-01-17 📝 Original message: It is not the case that ...
📅 Original date posted:2018-01-17
📝 Original message:
It is not the case that all instances where you might have negative fees would have loops. One instance where you want this feature is when the network becomes too weighted in one side of the graph. Another is when the other side is a non-routable endpoint. In both cases would be useful to signal to others that you were willing to pay to rebalance, and this hand wavy argument about loops doesn’t seem to apply.
> On Jan 17, 2018, at 12:40 PM, Christian Decker <decker.christian at gmail.com> wrote:
>
> Benjamin Mord <ben at mord.io> writes:
>> It isn't obvious to me from the BOLTs if fees can be negative, and I'm
>> finding uint in the go source code - which suggests not. In scenarios where
>> the funding of a payment channel has been fully committed in one direction,
>> why not allow negative fees to incent unwinding, in scenarios where nodes
>> consider that cheaper than on-chain rebalancing?
>
> After discussing this for a while we decided not to allow negative fees
> in channel announcements (for now), because they actually do not add to
> the flexibility and require special handling for route finding.
>
> The main argument for negative fees has always been that they allow a
> channel operator to rebalance its channels. However it is neither
> required, nor is it really all that helpful. If a node wants to
> rebalance he needs to find a cycle, that it can use to rebalance. The
> simplest rebalancing is that the node itself sends a payment along that
> cycle back to itself, giving the rebalancing node full control over the
> amount to rebalance, timing and costs.
>
> The negative fees were intended to encourage other participants to use
> any cycle and rebalance for the node offering the negative fees. However
> that results in less control over the rebalancing for the node, e.g.,
> how many payments to incentivize, amounts, etc. This is compounded by
> the inherent delay of channel updates being disseminated in the
> network. So if a rebalancing node gets too many payments that try to
> take advantage of the negative fees, what should it do? It'd result in
> either losses for the node, or many forward rejections. So why not use
> the funds one would have used towards negative fees for the active way
> of rebalancing.
>
> It is preferable to have payments be routed around an exhausted channel,
> after all if there is a cycle there must be an alternative route, rather
> than trying to artificially rebalance.
>
> So overall, allowing only positive fees makes routing simpler, and still
> allows for active rebalancing. As for other applications some have
> alluded to, this constraint is only for the routing gossip. Should there
> be a good reason to allow increasing the amount forwarded by a peer,
> e.g., node n receives x from the previous hop and forwards x+e to the
> next hop, that can still be negotiated out of band or even in the onion
> payload for that node.
>
> Cheers,
> Christian
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
📝 Original message:
It is not the case that all instances where you might have negative fees would have loops. One instance where you want this feature is when the network becomes too weighted in one side of the graph. Another is when the other side is a non-routable endpoint. In both cases would be useful to signal to others that you were willing to pay to rebalance, and this hand wavy argument about loops doesn’t seem to apply.
> On Jan 17, 2018, at 12:40 PM, Christian Decker <decker.christian at gmail.com> wrote:
>
> Benjamin Mord <ben at mord.io> writes:
>> It isn't obvious to me from the BOLTs if fees can be negative, and I'm
>> finding uint in the go source code - which suggests not. In scenarios where
>> the funding of a payment channel has been fully committed in one direction,
>> why not allow negative fees to incent unwinding, in scenarios where nodes
>> consider that cheaper than on-chain rebalancing?
>
> After discussing this for a while we decided not to allow negative fees
> in channel announcements (for now), because they actually do not add to
> the flexibility and require special handling for route finding.
>
> The main argument for negative fees has always been that they allow a
> channel operator to rebalance its channels. However it is neither
> required, nor is it really all that helpful. If a node wants to
> rebalance he needs to find a cycle, that it can use to rebalance. The
> simplest rebalancing is that the node itself sends a payment along that
> cycle back to itself, giving the rebalancing node full control over the
> amount to rebalance, timing and costs.
>
> The negative fees were intended to encourage other participants to use
> any cycle and rebalance for the node offering the negative fees. However
> that results in less control over the rebalancing for the node, e.g.,
> how many payments to incentivize, amounts, etc. This is compounded by
> the inherent delay of channel updates being disseminated in the
> network. So if a rebalancing node gets too many payments that try to
> take advantage of the negative fees, what should it do? It'd result in
> either losses for the node, or many forward rejections. So why not use
> the funds one would have used towards negative fees for the active way
> of rebalancing.
>
> It is preferable to have payments be routed around an exhausted channel,
> after all if there is a cycle there must be an alternative route, rather
> than trying to artificially rebalance.
>
> So overall, allowing only positive fees makes routing simpler, and still
> allows for active rebalancing. As for other applications some have
> alluded to, this constraint is only for the routing gossip. Should there
> be a good reason to allow increasing the amount forwarded by a peer,
> e.g., node n receives x from the previous hop and forwards x+e to the
> next hop, that can still be negotiated out of band or even in the onion
> payload for that node.
>
> Cheers,
> Christian
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev