<p>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).</p>

CC BY-SA 4.0
2019-06-11T13:27:01.360Z
2019-06-11T13:27:01.360Z
Sergei Tikhomirov
<p>Sure there might be some game theory involved but two things speak against it:</p>

<ol>
<li>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. </li>
<li>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.</li>
</ol>

CC BY-SA 4.0
2019-06-06T13:53:34.297Z
1. 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
CC BY-SA 4.0
2019-06-06T14:30:08.170Z
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
CC BY-SA 4.0
2019-06-07T06:22:27.917Z
no 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
CC BY-SA 4.0
2019-06-07T06:23:10.883Z
@RenePickhardt I just figured that out and deleted my earlier comment. What impeccable timing :). Sorry about that
Ugam Kamat
CC BY-SA 4.0
2019-06-06T10:28:22.953Z
2019-06-06T10:28:22.953Z
Rene Pickhardt
<p>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 <code>fee_insufficient</code> failure code to the previous node in the route.</p>

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

<p>Each HTLC is conditional on receiving the <code>payment_preimage</code> 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.</p>

<p>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 <code>incorrect_or_unknown_payment_details</code>, 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.</p>

CC BY-SA 4.0
2019-06-06T13:56:21.557Z
"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
CC BY-SA 4.0
2019-06-06T15:29:11.473Z
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
CC BY-SA 4.0
2019-06-06T10:23:11.050Z
2019-06-06T10:23:11.050Z
Mark H
<p>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?</p>

<p>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?</p>

<lightning-network><lightning-routing>
Why can't an intermediary Lightning node take (nearly) all fees?
Sergei Tikhomirov
# Why can't an intermediary Lightning node take (nearly) all fees?

(Asked by: username_0 on 2019-06-06)

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?

**Tags:** lightning-network, lightning-routing


---

## 3 answers

### Answer by username_0 on 2019-06-11. Score: 0 | Accepted answer

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


---

### Answer by username_1 on 2019-06-06. Score: 1

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

1. 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.
2. 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.

> **Comments:**
> **username_0**: 1. 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?  
> **username_1**: 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  
> **username_1**: no 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  
> **username_2**: @username_1 I just figured that out and deleted my earlier comment. What impeccable timing :). Sorry about that  

---

### Answer by username_3 on 2019-06-06. Score: 1

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.

> **Comments:**
> **username_0**: "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?  
> **username_3**: 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.  

---

