Add limited support for Blip18 inbound fees

[rorp]

This PR introduces two features:

1. It implements the option to compute lower fees for routes via nodes with negative inbound fees
2. It automatically excludes channels with positive inbound fees from route finding if enabled

It does not set any kind of negative fees and don't use them in payment forwarding.

I tried to do it in the least invasive way possible, but of course there's always room for improvement.

[DerEwige]

@t-bast

Looks like tests only fail because of current testnet situation.
I run them multiple times locally until they all passed.

I currently run this PR on my mainnet node.
Route building works as expected, but we found a bug in route finding.
Sometimes findRoute delivers routes that are above the specified max fee.
I’m currently debugging the issue with @rorp
We will let you know once we fixed that issue

[t-bast]

Please note that we have no intention for the moment to accept a PR that implement bLIP 18. This can be used on your node of course, but if we ever add support for inbound fees, it will likely be rather using the backwards-compatible proposal from lightning/blips#22 (which wouldn't have created these issues in the first place if it had been used instead of bLIP 18).

[DerEwige]

You might have to reconsider that stance.

Already about 2% of all channels offer blip18 inbound discounts.
The number is rising fast.

I need to do an exact tally, but a high % of my payments make use of inbound fee discounts already.

Success rate of payments have increased drastically since using blip18 and the number of unique payments paths through the network in a 7-day window have increased by 50% already in the 2 days I run this patch.

It saves me multiple 10k of Satoshi each day and I bet it would save ACINQ a magnitude larger amount, as you can leverage finding cheaper and more reliable routes into larger profit when doing the trampoline for phoenix.

The market will decide which inbound fee version will be used.
And LND has 95% market share in routing nodes.
Blip18 works and has already established itself.
It will be hard to convince the users to switch to another inbound fee version.
When this one already has support by most tooling and works throughout the network.

At the current rate of growth, I expect to reach 5% of channels offering inbound discounts within 3-6 months.

[DerEwige]

I want to give some numbers regarding blip18

The number of channels offering blip18 inbound fee rabat has grown from 1000 to over 1600 within the last 2 months.

Two weeks ago the amount of payments from my node including bip18 was 29% by numbers and 18% by volume. This week it was 40% by number and 25% by volume.

We reached the exponential part in the S curve.

I expect that within a month more than 60% by number and 40% by volume will include blip18.
Within 3 months it will be 80%+.

This is mainly due, to the fact, that more and more central routing nodes adapt inbound fees.
And there are not really any routes around them.

Currently the average inbound fee rabat on a blip18 including route is -151 ppm (median -35).

Als there is a trend to increase outbound fees, if the peer offers inbound rabat.
To siphon a bit of that inbound rabat.
I expect any node that does not support blip18 to pay a premium on routing fee of at least 100 ppm in the near future.