Add a bLIP for backwards-compatible inbound fees

[TheBlueMatt]

This provides an alternative to #18. In comparison, it:

• is backwards compatible in that average nodes on the network do not have to take any action in order to apply the fee changes,
• allows for positive inbound fees,
• requires substantially less total code changed (at least in LDK) as it doesn't touch gossip or path-finding,
• avoids the quagmire/incentive of nodes to rapidly update channel_update messages due to negative fees being a function of channel balance by clamping the fee to zero at the protocol level.

[renepickhardt]

Disclaimer: I might cross post this to the mailinglist.

Let's say Alice charges 200 ppm on the channel with Bob and Bob wishes to request an inbound fee of 100. It is my understanding that upon receiving inbound_fees_update Alice is supposed to send out a channel_update with a ppm of 300. In particular the network will understand this channel to be of 300ppm.

During fee computation in forwarding Alice would only reduce the amt_to_forward only by a ppm 200 such that Bob could keep the remaining 100 ppm.

Here my questions:

• Assuming the total routing fee on the channel is 300 ppm (as stated above). Why should Bob only get 100ppm and Alice 200ppm?
• What prevents Bob from asking Alice for an inbound fee of 300ppm and forcing her to charge 0ppm?
• Vice versa: What prevents Alice from increasing her fees afterwards to 400 and waiting for Bob now to reduce his inbound fees again resulting in 0 ppm inbound fees and 300 ppm outbound fees.
• How do the two very greedy and selfish actors Alice and Bob find an agreement how to share the revenue.

What I am trying to say. Just having one node initially suggest a price for routing and heaving the channel partner make a counter suggestion by either adding to or subtracting from the amount and then keeping or paying the difference seems extremely unstable.

While I very much like from this proposal that this conflict may not be directly visible to the remainder of the network I think we need some form of protocol for Alice and Bob to decide how to split the routing fees on the channel (similar to how we do onchain fee negotaion in mutual closes) and define a point after which Alice or Bob would fail the channel because they can't find agreement.

Luckily various dialects of this problem have been studied in game theory. E.G:

• https://math.stackexchange.com/questions/1141352/splitting-the-dollar-nash-equilibrium
• https://philosophicaldisquisitions.blogspot.com/2010/10/nash-bargaining-solution.html
• https://en.wikipedia.org/wiki/Ultimatum_game

There for some similar dialect of the problem it seems that the nash equlibrium is to split the revenue in a 50/50 way. Thus if we don't know any better it seems very reasonable to have a round based communication protocol (similar to channel closing) by which Alice and Bob negotiate the total routing fees which then would be split 50/50 betweetn them.

btw: As mentioned of Twitter I have previously informed the Lightning Labs team about the fact that the question how to split the routing revenue between the partners needs to be addressed in any form of inbound fees as we would otherwise create instability in the network.

Also let me be clear. To the best of my knowledge price signals (as routing fees are) are known to be a poor mechanism for flow control in fluid networks (like the electric grid or gas / water networks) as they usually do not provide stability. Valves that I have previously suggested to use tend to work much better for flow and congestion control. However also the valves approach would benefit form a communication protocol for the peers to agree on how much to open the valve in which direction. Similar to the negotiation of the routing fee one could have a more general communication protocol to negotiate channel meta data like fees / valves and other features.

Conclusion: Maybe the current discussion and disagreement could be resolved by thinking about channel meta data negotiation protocols (which btw could also include some form of information sharing as proposed in https://github.com/lightning/bolts/pull/780 ) and could be used even during channel opening negotiation.

[TheBlueMatt]

Assuming the total routing fee on the channel is 300 ppm (as stated above). Why should Bob only get 100ppm and Alice 200ppm?

The HTLC will fail.

How do the two very greedy and selfish actors Alice and Bob find an agreement how to share the revenue.

You're assuming they have a target total fee for the channel. I don't think that's a given - rather, a node may wish to receive X for flows inbound over a channel, irrespective of their peer's fee. We could also take your questions further - you could make a similar argument between a peer and the average (or min/max or whatever) fees its peer charges for outbound forwards. Nodes are in effect "splitting the revenue" of an HTLC through the full path, not just on one single hop.

[TheBlueMatt]

More generally, however, see the motivation section of the bLIP here - even if we assume routing nodes don't want this, nodes may want it on private channels for LSP clients.

[cdecker]

I share the concern of others wondering if inbound fees actually solve a problem, and don't just cater to the wishes to have more flexibility for the sake of it, but this proposal is definitely better and less infectious than #18. I'm still pretty convinced that the scenarios used to show the necessity if inbound fees can be solved by emulating them with existing parameters too, or perceived issues in the scenarios are not real (net income is likely unaffected by a node leeching all the outbound balance through a direct peering).

[joostjager]

Another fee model that has been talked about in the past is 'pair-wise' fees. In that model, a routing node can assign a specific fee for each combination of in and out channel. With the gossip approach this is mostly an extension of #18 with a more advanced data format.

Is there any way to do pair-wise fees with the proposal in this PR?

[joostjager]

The proposal specifies that inbound fees must be paid to the final hop too. If two routing nodes decide to open a direct channel to route traffic with inbound fees (charged to a distant sender), they can no longer use this channel to make 'free' payments between them. For example two custodial wallet nodes that route traffic but also make direct payments to each other. This looks to me like something to not step over too easily.

[TheBlueMatt]

Another fee model that has been talked about in the past is 'pair-wise' fees. In that model, a routing node can assign a specific fee for each combination of in and out channel. With the gossip approach this is mostly an extension of https://github.com/lightning/blips/pull/18 with a more advanced data format.

Please for the love of god do not make channel_update messages N^2 in size.

Is there any way to do pair-wise fees with the proposal in this PR?

No, for the same reason as above :)

The proposal specifies that inbound fees must be paid to the final hop too. If two routing nodes decide to open a direct channel to route traffic with inbound fees (charged to a distant sender), they can no longer use this channel to make 'free' payments between them.

This is not a change from today. If a node decides it wants to charge its peer for sending it payments it can do so by creating fake hops in invoices.

[joostjager]

Please for the love of god do not make channel_update messages N^2 in size.

That's the naive way to do it. But there surely are different options. For example: every channel can be assigned a group (id) that is communicated as part of the channel update. For pair-wise fees, you can then reference a whole group of channels and set a different fee only for that group. Not saying that this is how it should be, but I do value the extensibility that the gossip model offers if a need for this would arise in the future.

This is not a change from today. If a node decides it wants to charge its peer for sending it payments it can do so by creating fake hops in invoices.

I am not saying that they can't do so today. It's the opposite. If the mechanism proposed in this PR would be implemented, then routing nodes that charge inbound fees for traffic that they forward wouldn't be able to do zero-fee payments with direct peers anymore across those channels.

[TheBlueMatt]

< Not saying that this is how it should be, but I do value the extensibility that the gossip model offers if a need for this would arise in the future.

If we end up deciding we need that feature, we can implement it any way we want to at that point :) I don't want to implement a router that lets nodes turn themselves into a bunch of virtual nodes in the graph, though :p.

I am not saying that they can't do so today. It's the opposite. If the mechanism proposed in this PR would be implemented, then routing nodes that charge inbound fees for traffic that they forward wouldn't be able to do zero-fee payments with direct peers anymore across those channels.

Sure they can! They can negotiate any additional optional protocol they want :). "If invoice is to me, feel free to pay a fake invoice with funds less by the inbound fee amount", problem solved :). By making this a thing that is negotiated between two peers the two peers can negotiate any additional anything they want.

[cdecker]

Listening to the discussion during the call one thing came to mind: we are handing one peer a way to trigger a channel_update on their behalf by modifying our own inbound fee (we update our fee, they just add it to their fee and broadcast a new channel_update). This may run into issues with nodes that throttle updates or have a time-based limit not forwarding any more updates for our peer, and the malicious node has caused the victim to no longer be update that channel going forward, or severely slow down the propagation of those updates.

Then again, they are always free to reject anything that doesn't match their own policy, but that can cause more failed payments (the malicious node is also hurting themself, so 🤷 )

Didn't want to bring this up since the discussion was on a more fundamental level :-)

[TheBlueMatt]

Yes, the node asking for a fee update has to wait for their peer to send back (and thus broadcast) an updated channel_update before they can enforce the new fees (as written in the bLIP now). That may effectively cut in half how often you can update the inbound fees vs your outbound fees, but its not a huge change otherwise - as you point out your peer can already do any number of other things to cause HTLCs to not be forwarded through the channel y'all have, there's not much we can do to prevent that :)