Why can't an intermediary Lightning node take (nearly) all fees?

Consider a Lightning payment: Alice wants to pay 100 sat to Dave via two intermediary hops: Alice - Bob - Charlie - Dave. Both Bob and Charlie advertise a fee of 2 sat. Alice sends 104 sat to Bob, expecting him to forward 102 sat to Charlie. But Bob only forwards 101 sat. Then Charlie has a choice: either to fail the payment and get nothing, or forward it for just 1 sat. It seems that the economically rational choice is to forward anyway. If this is true, why first hops not always take nearly all fees for themselves?

Of course, due to onion routing, Bob doesn't know whether Charlie is the last hop. If Charlie is the ultimate recipient and he won't get the sum he expected, he won't reveal the preimage, and Bob will get nothing. But can such strategies be profitable on average, over many attempts?

Sergei Tikhomirov

Posted 2019-06-06T10:07:52.993

Reputation: 1 189

Answers

Summarizing what I've read in other answers and elsewhere: yes, a node can technically do so, but this would probably not be economically viable, as current implementations fail a payment is the difference between "incoming" and "outgoing" amounts is less than their announced fee. So assuming that the majority of the network runs non-malicious software, the payment with modified fees with likely fail. The precise economic analysis of this attack (and the related DoS attack) has not been done though (AFAIK).

Sergei Tikhomirov

Posted 2019-06-06T10:07:52.993

Reputation: 1 189

Sure there might be some game theory involved but two things speak against it:

Bob does not know what the fee or the final payment amount is. Of course he could make an educated guess. But maybe the final payment was 101.5 sats and Charlie was supposed to forward for 500msat. Charlie would now even have to add 500msat to fulfill her 101.5 amt to forward.
It is currently differently implemented. Nodes will just not forward if the amount they reicieve minus the amount they are supposed to forward is below their fees. So if Bob would mess with the onions later nodes would currently automatically fail with insufficient fee error message. This of course could be abused for denial of service attacks.

Rene Pickhardt

Posted 2019-06-06T10:07:52.993

Reputation: 6 565

Can't Bob just query Charlie about what fee he offers? 2. "nodes would currently automatically fail" - current implementations do that, but this can't be enforced, right?

< – Sergei Tikhomirov – 2019-06-06T13:53:34.297

Bob could query Charlie but since Bob does not know how long the route is the information given is low but it might be used). So there are possibilities. And yes I don't see any way to enforce this behavior – Rene Pickhardt – 2019-06-06T14:30:08.170

1no bob would not change the amount_to_forword for the next hop but just forward a different amount than was specified in his part of the onion. This would not have any impact to HMACs but obviously meddeling / breaching the protocol is a poor idea since charlie would / should probably fail the onion as charlies routing fees are not sufficient – Rene Pickhardt – 2019-06-07T06:22:27.917

@RenePickhardt I just figured that out and deleted my earlier comment. What impeccable timing :). Sorry about that – Ugam Kamat – 2019-06-07T06:23:10.883

Each hop along the route is sent the full amount including fees with a new HTLC, and inside the onion packet, they are told how much of it to forward to the next hop. They can therefore determine if enough is provided for the fees they have advertised for their own node, and if the fee is insufficient, they can simply remove the HTLC without forwarding it by returning an fee_insufficient failure code to the previous node in the route.

There is a possible race condition where fees have changed, so the most recent channel_update is forwarded along with the fee_insufficient failure so that the payer can reattempt the route with update fees.

Each HTLC is conditional on receiving the payment_preimage or timing out. Currently, the same preimage is used for every hop along the route, which makes the payment from Alice to Bob conditional on Dave releasing the preimage to Charlie, who can then forward it to Bob, who then forwards it to Alice.

If the penultimate node attempts to forward less than the intended amount to the payment destination, then the payment destination will respond with the failure code incorrect_or_unknown_payment_details, which will also remove the HTLC. Each node along the route will then forward the same failure and cancel each HTLC, and no money will change hands.

Mark H

Posted 2019-06-06T10:07:52.993

Reputation: 2 038

"if the fee is insufficient, they can simply remove the HTLC" - but do they have to? Sure, if the last node gets less than expected, the whole thing fails. The question was, if I announce my fee as X and get offered a routed payment with fees <X, why would I want to drop it instead of earning at least something? – Sergei Tikhomirov – 2019-06-06T13:56:21.557

The node is not required to drop it, but if they do not forward at least the requested amount to the next node it is very likely the payment will fail and they will earn nothing anyway. A node is unlikely send payments with insufficient fees to begin with because it is highly likely to fail. – Mark H – 2019-06-06T15:29:11.473