Inbound fees send support

[joostjager]

LND version 0.18 which was released on May 30, 2024 included support for negative inbound routing fees. This feature allows routing node operators to offer a discount for traffic that comes in through specific channels.

Background information:

• https://www.mail-archive.com/lightning-dev@lists.linuxfoundation.org/msg02895.html
• htlcswitch: add inbound routing fees receive support lightningnetwork/lnd#6703
• routing: inbound fees send support lightningnetwork/lnd#6934

Now that almost a year has passed since, it seems that there is some uptake of the feature by node operators. LDK ignores negative inbound fees and therefore senders using LDK are potentially overpaying.

To address just that, LDK would only need to get send support. Receive support is exclusively relevant to routing nodes.

Additionally, it is worth considering extending the rapid gossip sync protocol to become more flexible with regards to extra channel update parameters - for inbound fees and also for what else might be added going forward.

In the network, there are currently (Feb 2025) around 2000 channel ends for which the node on that end advertizes a non-zero inbound fee. For a list of those nodes and the number of inbound fee channels per node, see Inbound fees analysis - nodes.csv

For 95% of the channels, the base fee is set to zero with just a proportional inbound fee set. The proportional inbound fee distribution (non-zero, down to -20 basis points) is shown here:

[TheBlueMatt]

We should probably see how things go with the new gossip - there's been some discussions to add this as a formal part of gossip in the new gossip format, and that discussion may inform us about what the arguments are for or against this going forward (and also might actually enable positive inbound fees, or maybe only positive inbound fees and not negative ones).

[joostjager]

Can of course wait for that, but keep an eye on this in the mean time to make sure that not too many sats are left on the table.

[joostjager]

Earlier exploration: #1942