pull down to refresh
40 sats \ 5 replies \ @javier OP 6 May \ parent \ on: Ultimate guide to LN routing and fee management. bitcoin
Sure, the fee is the outbound fee, which means the fee you charge for going out. So in your example, A pays 5 sats to you. B doesn't pay anything to you. But in addition to pay you, A will pay to B whatever B has as outbound fee (you can't control this).
Another thing is the inbound fee which is always negative or 0, and it is a discount. So if you put an inbound fee of -5, A will pay 0, because A is the inbound and B is the outbound which you put an outbound fee of 5, so the discount applies: 5-5=0. Do not confuse this with the outbound of A which is 1. Remember, outbound and inbound fees are different, they are not the same parameter, each channel has both fees, both inbound and outbound.
Any more questions I will happily answer.
RTL only provides an interface to "Update Free Policy" where one can set base fee (msat) and fee rate (ppm). I guess that is outbound fees, right?
Then how do I set inbound fees in RTL (I run Core Lightning node with RTL)? My guess is that this is not supported in RTL because inbound fees are something that only LND supports and Core Lightning does not, right?
Are inbound fees in the LN protocol? That is, are they part of the channel fees gossip? I guess the answer is "no". If that is the case, then how do senders know about inbound fees when creating the payment routes?
reply
Fee policy means outbound fee policy, yes.
Inbound policies are a thing available in LND only, I think, but there is a BLIP: https://github.com/lightning/blips/pull/18
Other implementations should enable this, but you know CLN, it is always the last one and usually it comes late. Another reason not to choose CLN added to the long list.
For setting inbound fees graphically I know of LNDg in their advanced settings tab, which is also a good rebalancer and has a good interface (only for desktop).
reply
I see. That https://github.com/lightning/blips/pull/18 is not merged since 2022. Looks like there is a simpler and less disruptive way to implement that and it is to ask the peer on the other end of the channel to lower their fee and you will pay the diff to them. For example, assuming a channel between
A and B:A (outbound fee 1000) ---> (inbound fee -100) Bwould be the same as:
A (outbound fee 900) ---> (no inbound fee, B pays 100 to A after a payment goes through) BIn the second case a greedy and mean
A can increase the fee from 900 to 1000 shortly after and get 1000 from the sender and 100 from B. But that is equivalent to the first case where A can increase its fee to 1100 after noticing B set -100 inbound.Inbound fees have to be supported by all softwares that support sending payments over LN. I wonder how many support that currently.
reply
As I said, losing is imposible because it is a discount. But if you don't believe me, let Lighting Labs tell you so:
reply
That's very helpful, thanks.
reply