Benjamin Mord <b...@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@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev