Christian Decker [ARCHIVE] on Nostr: 📅 Original date posted:2018-01-17 📝 Original message: Benjamin Mord <ben at ...

📅 Original date posted:2018-01-17
📝 Original message:
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