Ability to set inbound and outbound fees

[AbelLykens]

Taken from lightningnetwork/lnd#4225 .
Original by @Swissnode:

As a major channel balancer and node operator, it has become clear to me and the community of channel balancers I work with that we really need the ability to incentivize traffic in certain directions.
As such, we would highly recommend having inbound and outbound fees to allow such incentivization.

Reply @Roasbeef :

As is, on the protocol level, you can only set the fees for outbound (routing an HTLC over that channel). The remote party controls the "inbound fees", since their bandwidth is used to carry the HTLC.

One thing we've discussed is possibly introducing "pair wise" fee schedules. So this would mean you can set different fees for A -> B, and A -> C, where B and C are your channels. We could possibly add some new TLV fields to the ChannelUpdate to make this possible, but no one has attempted to fully specify it yet.

and:

This is a spec level thing, so closing here as the discussion needs to be started on the rfc repo and/or the dev mailing list.

[t-bast]

I don't understand what that means.
It doesn't make sense for you to set the inbound fees, that choice belongs to your peer.

[dlaptev]

that choice belongs to your peer.

At the moment yes, but it does not have to be that way. The fee in either direction can be a sum of what you take and what your peer takes. Being able to set both inbound and outbound fee will allow nodes to have a much better control of the liquidity flow.

[t-bast]

Ok that's what you meant, to have both peers collect a fee whenever a payment is relayed, regardless of the direction?
I'm not convinced the incentives work though, can you make your case there?
If I open a channel to you, I want to be able to set the relay fees and I want to collect the whole fee because I brought all the liquidity, I don't want to give you a cut of that fee. The only reason I would do that would be if I'm sure that the fee I'll also collect from your end of the channel exceeds the fee I let you collect from my side of the channel. But then we have an asymmetry and a loser here, so the equilibrium should revert back to one-sided fees.

[dlaptev]

I think yes, that's is how I understand the proposal.

I completely agree that the person bringing the liquidity should be rewarded more in the beginning. Not sure whether this should be handled explicitly though, I tend to think that the market will rule misbehaving peers out, but I could be wrong of course.

My case here would be longer-term. I have lots of channels where cumulatively the amount of forwards is >10x larger than the channel capacity. Note that the notion of "who brought the liquidity" kind of becomes blurry at this point.

Most of these channels have a dominant directions of forwards: some channels are mostly used as incoming channels, so most of time the balance is local, and some as outgoing channels, so most of the time the balance is remote. For the latter channels I increase the fees to "slow down" the flow of funds from me to the peer, and it works great: the channels become more balanced, the network benefits from liquidity both ways, and I collect some fees.

But I have no control over channels with predominantly incoming forwards. I usually drop the fees to zero to incentivize the flow "from me", but the liquidity is still mostly stuck on my end. Being able to set the "incoming fee" would serve exactly the same purpose as the outgoing fee for other channels: slow down the flow of funds in one direction and make the channels more balanced.

[t-bast]

But I have no control over channels with predominantly incoming forwards.

But in that case your peer has absolutely no incentive to let you lower his fees. It is (and IMO should be) entirely his decision to slow the flow of funds by lowering his fee or not.

I think that this proposal needs to be:

1. More detailed, otherwise we can't accurately say whether it will even work or not
2. The claim that it helps liquidity need to be much more substantiated (a hand-wavy "we feel it's better for liquidity" is not enough to motivate such an important change)

[dlaptev]

Agreed. I will let @Swissnode elaborate further if they had more detailed proposal in mind and quantitative evidence to support it.

[Swissnode]

The point of asking this is that currently I don't have a way of enticing movement in a certain direction along a channel. Certain channels basically drain sats so it would be nice to be able to set incoming fees of such channels to near zero to entice flow back down that channel.

This is still advantageous for me as a node, as I still obtain the outgoing fees for any routing through that lopsided channel

Hope that makes sense, it's actually a simple proposal...

[AbelLykens]

I see the same things @Swissnode sees. I want to balance my channels. I use https://github.com/accumulator/charge-lnd to set fees based on channel ratio (higher fees if most is on remote side).

If I am able to encourage routing IN by setting lower fees, that makes more sense to me...

[t-bast]

Sorry but no, that makes absolutely no sense to me (unless I'm missing something).

Are you saying that you are in a situation like A <---> B where you are A and most of the funds are on B's side? And you'd like to lower the relay fees B -> A to incentivize funds to flow back to A?

If that's the case it's a NACK from me. If all the funds are on B's side, it's their money, not yours (you have received the same amount of money in another channel before sending it to them on this channel). Since it's their money, it's 100% their decision, you should have absolutely no business deciding what relay fees they should set for their money. They will update their relay fees when they see fit; if you're complaining because you feel they're not managing their relay fees correctly, then simply don't open other channels to them (you don't care about this one, since all the money is on their side, you don't have anything at stake). If it makes sense in their strategy to get the funds to flow back to you, they'll lower their relay fees, but that should be entirely their decision.

[Swissnode]

This explains it.

If I have 1 million sats coming in and I have an incoming fee and an outgoing fee on channels A and B as shown, I deduct the sum of those ppm's. In this case 25+75 is 100 sats for every million going through the path.

It doesn't matter what the channel balance is at any stage. I simply retain a certain fraction of the sats flowing along both channels.

In this way I can incentivise the usage of channel A by simply dropping the inbound fees to zero. There will still be an outgoing fee applied, but again I can incentivise the outbound usage of a certain channel by dropping ITS fees to zero.

This also allows any node operator to change his modus operandi. He could decide to NEVER charge outgoing channels and just charge certain incoming ones... Maybe I am connected to a node which emits way more sats than it receives, in which case you want to charge for using the incoming from that node...

[t-bast]

If I understand correctly your argument, I'm sorry but it's still a big NACK from me.
To achieve your goal you're trying to control the relay fees that apply to funds that are fundamentally not yours.
From your node's point of view, of course it would be better, but you're assuming what's best for your counterparties.
This shouldn't be your decision, it should be a decision they reach independently, and the existing fee mechanism is well-suited for that.

[begetan]

It is possible to move the fee decision entirely to the right side. For example fee rate would be virtually splitted to 25 + 75 on the both channel B side.

So when a payment come from node A, the total fee would be 100 ppm.
But if another payment come from node C (which is not present here) the total fee coud be just 75 ppm because "incoming" fee it is not set for this channel.

The question is it possible to propogate such data in the network?

[openoms]

@begetan this is what @Roasbeef has mentioned as the pair wise fee schedules.
In that case still only one peer would control the fee on a direction, but could set different (outgoing) fees depending on which peer the payment is coming from.
This would also add a lot of extra parameters and communication burden, but would be a more viable way to achieve what is aimed in this issue which is to be able to prefer or penalize whole routes.

[t-bast]

In that case still only one peer would control the fee on a direction, but could set different (outgoing) fees depending on which peer the payment is coming from.

Ok I get it now, that makes more sense. You would provide discounted fees when it's coming from specific channels to nudge the choice of the overall route towards what helps balance your channels. This is worth exploring, but it's indeed probably quite costly in terms of gossip bandwidth used.