[c-lightning] Protecting against JIT-Routing-enabled attacks in a non-zero-fee rebalance environment

[ZmnSCPxj]

Good morning list,

As is usual, I shall spend more time adding verbiage to the list, than on actually implementing Lightning technology.

So let us consider first an attack enabled by JIT-Routing, in an environment where rebalancing is not fee-free.

--

Let us suppose there are three nodes, Rene, ZmnSCPxj, and YAijbOJA, plus another node we shall simply call RestOfLightningNetwork.

Rene has channels with ZmnSCPxj and YAijbOJA, and ZmnsCPxj and YAijbOJA have a channel also.
Further, Rene also has a channel that is perfectly balanced with RestOfLightningNetwork.

Let us first suppose that in the Rene<->ZmnSCPxj channel, ZmnSCPxj holds most of the funds, while in the Rene<->YAijbOJA channel, Rene holds most of the funds.
Then let us consider the following sequence of events:

1. Rene receives a forwarding request from RestOfLightningNetwork to ZmnSCPxj.
2. Rene notices the Rene<->ZmnSCPxj has low capacity for Rene side, but the Rene<->YAijbOJA channel has high capacity for Rene side.
3. Rene computes a rebalance Rene->YAijbOJA->ZmnSCPxj->Rene, as well as the fee involved.
4. Rene finds that the fee in the rebalance is much smaller than the fee offered in the RestOfLightningNetwork->Rene->ZmnSCPxj forward, so performs JIT-Routing and rebalances.
5. After rebalancing, Rene<->ZmnSCPxj now has high capacity for Rene while Rene<->YAijbOJA has low capacity for Rene.
6. Rene forwards to ZmnSCPXj.
7. ZmnSCPxj responds in tears, saying that the forwarding failed after his node.  Rene earns no forwarding fees.
8. Rene receives a forwarding request from RestOfLightningNetwork to YAijbOJA.
9. Rene notices the Rene<->YAijbOJA has low capacity for Rene side, but the Rene<->ZmnSCPxj channel has high capacity for Rene side.
10. Rene computes a rebalance Rene->ZmnSCPxj->YAijbOJA->Rene, as well as the fee involved.
11. Rene finds that the fee in the rebalance is much smaller than the fee offered in the RestOfLightningNetwork->Rene->YAijbOJA forward, so performs JIT-Routing and rebalances.
12. After rebalancing, Rene<->YAijbOJA now has high capacity for Rene while Rene<->ZmnSCPxj has low capacity for Rene.
13. Rene forwards to YAijbOJA.
14. YAijbOJA responds in tears, saying that the forwarding failed after his node.  Rene earns no forwarding fees.
15. GOTO 1.

This means, of course, that YAijbOJA and ZmnSCPxj are extracting funds from Rene here.

One solution is to require zero-fee rebalances.
However, that is potentially contentious.

----

I propose another solution instead.

In this solution, Rene keeps track of a synthetic "maximum rebalance fee" for each channel it has.

Whenever Rene forwards over a channel, and is able to forward *successfully*, it increases the "maximum rebalance fee" for the outgoing channel it earned from.
This increase can be any fraction of the earned fee less than 1.0, for example it can count 50% of the fee to the maximum rebalance fee.

Then, when a forward over a channel cannot be serviced because the outgoing channel has too little capacity, Rene will only consider possible rebalancing routes that have a fee less than the "maximum rebalance fee" for that channel.
And if the rebalance pushes through, Rene will then *deduct* the rebalancing fee from the "maximum rebalance fee" for that channel.

This still lets ZmnSCPxj and YAijbOJA extract funds from Rene, but only up to (1 - fraction) of the actual fees that Rene has earned from "real" forwards.
ZmnSCPxj and YAijbOJA cannot touch some proportion of the earnings Rene gets from forwarding.

In addition, this can be used by Rene to opportunistically overbalance.
For example, suppose that Rene notices that the "maximum rebalance fee" for a channel is already very high.
This implies that sending funds over that channel is probably very lucrative.
In that case, Rene might do better to rebalance more than the minimum needed to fulfill the forwarding request, provided it does not exceed the "maximum rebalance fee" accumulated.

This lets us deploy a practical JIT-Routing mechanism, without having to wait for a zero-fee-rebalance spec change.

Regards,
ZmnSCPxj