Update gossip protocol to support signed values for fees.

[legendarymartini]

Moved from lightningnetwork/lnd#5835

In section "8.5 Fees" (page 49) of the lightning network white paper, a single sentence at the end of the section suggests using negative fees to encourage routing on certain channels.

Since certain paths may become very profitable in one direction, it is possible for fees to be negative to encourage the channel to be available for those profitable paths.

However, the channel_update message format only supports unsigned values for base fee and fee rate.

Supporting negative fees would allow node operators to pay a sender (instead of collecting a fee) to encourage transactions that would push liquidity out on a channel that has a tendency to fill up locally. Node operators currently can only drop the fee to zero, which sometimes isn't enough and their only options are to A) wait, or B) pay routing fees to re-balance the channel. In some scenarios, setting a negative fee to pay a sender to move the liquidity may be a cheaper or an otherwise more desirable option.

[NickRHill]

I have operated a node for a while, and come to the conclusion the graph theory of the network interconnect is only one dimension.

Presuming you have a system to actively manage channel fees to maintain liquidity, you will find your channels fall into three rough categories:

1. Channels which can reach an equilibrium, but with only a very high fee.
2. Channels which reach an equilibrium with essentially zero fees. In effect, your equilibrium peers.
3. Channels for which you cannot reach an equilibrium with zero fees. No equilibrium is possible for an extended period of time, unless that node on the other end changes it’s own peers and therefore position in the fees equilibrium. For such nodes, your liquidity is mostly wasted.

I'll describe a way to visualise it hydrodynamically:

A channel:
Imagine you have a watertight box. That box has a flexible membrane in the middle. Once that membrane touches the other side of the box, no further flow is possible. One one side connects to one node, the other connects to another node. The size of the box is analogous the channel's capacity in sats.

A node:
A node is a manifold. A flooded vessel with many connectors. Each manifold connection has a pressure reducing valve which works only for water flowing out. Water may flow in freely. A node gains "energy" from harnessing the flow of water out through the pressure reducing valve. That energy ultimately increases the amount of water held inside the manifold. This harnessing of "energy" ultimately is supposed to make operating the node worthwhile.

With each node, you can position it higher or lower on the side of the mountain depending on it’s static pressure. The static pressure is analogous to the network price equilibrium.

A very important factor for channels is that they can connect between nodes higher and lower on the mountain, but the contents of the channel pipes themselves are free from the effects of gravity. If you connected a channel from the node with high pressure at the bottom of the mountain to a node with low pressure at the top of the mountain, water will flow very quickly through the channel pipe until either the source node reached equilibrium with the destination node and it’s channels, OR the channel is exhausted; the membrane is tight against the other side of the channel box.

In this model, you may find Boltz (and it’s neighbours) at the bottom of the mountain, ACINQ (and it’s neighbours) in the middle of the mountain, and Nicehash, BFX and Lnbig at the top of the hill.

If you make a connection from the Boltz neighborhood to BFX, unless you put a high outgoing fee on your channel, it will quickly empty.

So we have high fees and possibly limited liquidity with your sats climbing up the gradient, and zero fees and plenty of excess liquidity going down the gradient.

If you happen to be connected to a node in the valley, and you want to send to another node at a similar level, so long as you can find a “horizontal” route, you will be able to complete your spend with very low fees. If there is no horizontal route, you will need to find a channel going up the hill and back down. Only outbound connections up that hill with a significant fee will have liquidity to send your transaction. Once it reaches that up-hill node, payment back down the hill will be easy and free. So your transaction is expending fees or “energy” going up the hill, but is gaining nothing going back down the hill. Essentially wasted energy.

In my experience, the route-finding system for lightning is effective; if I set up a route to a different equilibrium regime, it doesn’t take very long, maybe less than an hour, for a 10MSat channel to be drained.

This suggests the routing problem as it stands right now is not finding a good route. The problem is that routes have to not only navigate the network graph of interconnects (which actually works quite well), but has to navigate a kaleidoscope of node “pressure” equilibria. The pressure equilibria being expressed in transaction fee.

In an ideal situation, the whole network will reach a neutral equilibrium; Boltz and those in it’s neighborhood will keep opening and closing channels to BFX with low fees until no more sats flow. Under that ideal scenario, with well managed nodes, Boltz and BFX reach pressure equilibria with ACINQ. But as we can see, this doesn’t happen.

Let’s say that you are a benevolent node, just wanting to enable the functioning of the Lightning network and make just a few sats to cover operational cost and you wanted to connect every node. Is this possible? The easy answer is NO. As a node, you have your equilibrium pressure, and you cannot maintain useful channels everyone up and down that “hill”, the pressure gradient. Fees can only be charged for going up that hill and cannot be given back for going down. This limits the value of your liquidity only to those people horizontal to you – who share the same equilibrium pressure.

The only way I can see out of this is for node operators to be able to charge negative fees for sending payments down that pressure gradient. The available liquidity for any transaction will be multiplied many-fold if low cost transactions were no longer constrained to nodes sharing the same level on the hill – at the same equilibrium pressure.

It is clear that HTLC transactions will settle when the fees being offered to the node on the hop are equal or greater than the fee policy. They needn’t be exactly the same.

Therefore, to maintain compatibility, the gossip protocol could be modified with a bit as-yet reserved, to be assigned as “Negative fee”. This way, the change would be backwardly compatible. If a node didn’t recognise the negative fee flag in gossip, it could send an HTLC as normal, with a positive fee, and it will propagate across the network. The only difference being the node operator would receive a fee whereas they may have expected to pay a fee.

Until negative fees become a reality, life as a low-fee node operator will be constrained to providing liquidity to only your hydrostatic pressure peers in this analogy.

[joostjager]

Linking #1022 as an option to add signed fees without a feature bit.

[t-bast]

This can't be backwards-compatible: there are better designs to offer negative fees such as inbound fees.