As I said, losing is imposible because it is a discount. But if you don't believe me, let Lighting Labs tell you so:

https://docs.lightning.engineering/lightning-network-tools/lnd/inbound-channel-fees



javier

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 (outbound fee 1000) ---> (inbound fee -100) B

A (outbound fee 900) ---> (no inbound fee, B pays 100 to A after a payment goes through) B

. But that is equivalent to the first case where 

Inbound fees have to be supported by all softwares that support sending payments over LN. I wonder how many support that currently.

bitcoin

Ultimate guide to LN routing and fee management.

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) B`

would be the same as:

`A (outbound fee 900) ---> (no inbound fee, B pays 100 to A after a payment goes through) B`

In 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.