<p>Nodes advertise the fees for forwarding over a channel as part of a <a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md#the-channel_update-message" rel="nofollow noreferrer"><code>channel_update</code></a> message. The update should be sent as soon as a <a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md#the-channel_announcement-message" rel="nofollow noreferrer"><code>channel_announcement</code></a> is sent. Each party can decide its own fees for the channel.</p>

<p>For private channels, nodes advertise the fees inside the <code>r</code> tagged field of the <a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/11-payment-encoding.md" rel="nofollow noreferrer">BOLT#11</a> invoice.</p>

<p>When forwarding a payment, your node must calculate the required fee for each hop and add it to the payment requested in the invoice. When each intermediate hop receives an <a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#adding-an-htlc-update_add_htlc" rel="nofollow noreferrer"><code>update_add_htlc</code></a> message, they will unwrap one level of the <a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/04-onion-routing.md#packet-structure" rel="nofollow noreferrer">onion packet</a>, which contains an <code>amt_to_forward</code>. This is subtracted from the <code>amount_msat</code> in the <code>update_add_htlc</code> message, and the difference is the fee paid for this hop. </p>

<p>If the hop determines that the fee is insufficient, they respond to the sender with <a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/04-onion-routing.md#failure-messages" rel="nofollow noreferrer"><code>fee_insufficient</code> error</a> as part of an <a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#removing-an-htlc-update_fulfill_htlc-update_fail_htlc-and-update_fail_malformed_htlc" rel="nofollow noreferrer"><code>update_fail_htlc</code></a> message. This message also includes the most recent <code>channel_update</code> for this channel so that the payer can re-attempt the payment with new fees.</p>

<p>There is always the possibility of a race condition where fees may have changed between the most recently received <code>channel_update</code> and the payment attempt. This is minimized by including the <code>channel_update</code> as part of the failure as above.</p>

<p>If the payment at the last hop is too small, they will respond with a failure containing the <code>incorrect_or_unknown_payment_details</code> failure code.</p>

CC BY-SA 4.0
2019-05-08T14:42:01.093Z
We need to coordinate in future (: I was typing on my mobile where putting all these links and syntax highlighting is annoying. Anyway plus 1 for nice onside explainations instead of referring to a tutorial video like I did.
Rene Pickhardt
CC BY-SA 4.0
2019-05-08T14:37:35.523Z
2019-05-08T14:42:17.200Z
2019-05-08T14:42:17.200Z
Mark H
<p>The situation you describe cannot happen / would lead to a routing failure. I have created an <a href="https://youtu.be/toarjBSPFqI" rel="nofollow noreferrer">11 minute video explaining how htlcs are used in onion routing</a>. Parts of the video (rather at the end) explain how fees are encoded within the sent onion. I think watching that video is the quickest way to understand the fee model of the lightning network. </p>

<p>A tl;dw (too long didn't watch) answer looks like that:</p>

<p>If a node decides to maliciously collect a larger fee and forward the onion. The next hop will not be able to collect the fee as it advertised and will fail the routing process. In your setting this means charlie decrypts his onion and sees which amount to forward and sees from the incoming htlc that it would only receive a fee of 80 / 50 or 0 Satoshi instead of the advertised 100. As said charlie would fail the onion but not be able to blame Bob. Actually obs behavior would confuse Alice as she chose the correct fees. Alice could assume Bob was a bad routing node and elect a different part. However this mechanism is as far as I know not implemented yet. </p>

CC BY-SA 4.0
2019-05-08T14:50:16.757Z
By "this mechanism" in the last sentence do you mean Alice marking Bob as a bad node? (BTW, the tiny envelopes you use in the video are amazing, where did you even get those things :)
Sergei Tikhomirov
CC BY-SA 4.0
2019-05-08T14:50:18.800Z
What if we extended this argument by one more party? Alice sending BTC to Eric via bob, charlie and dave. Assume charlie is the bad apple in the lot and consumes all the remaining fee in the hop. How would Alice know whether it is Bob or Charlie?
Ugam Kamat
CC BY-SA 4.0
2019-05-08T14:59:19.490Z
Since the fees are part of the onion noone in the chain knows what the payment amount is and how much fees are in the onion in total... On the other hand I hope to remember correctly that the node that can't forward the onion because the prev took too much fees and back an failure message of type 12 `fee _insufficient` cf: https://github.com/lightningnetwork/lightning-rfc/blob/master/04-onion-routing.md#failure-messages
Rene Pickhardt
CC BY-SA 4.0
2019-05-08T15:05:24.473Z
@RenePickhardt That was helpful. One more scenario comes to mind. Assume Alice forwarded with 150 sats fee assuming bob, charlie and dave would take 50 stas each. Now let us assume Bob is the bad guy. Bob consumed 90 sats, and charlie consumed 50 sats. Dave will send a `fee_insufficient` message, but it would be hard for Alice to figure out who was the bad guy
Ugam Kamat
CC BY-SA 4.0
2019-05-08T15:11:54.237Z
What I see here is a violation of the "don't explain to the attacker why the error happened" security principle, screaming for probing attacks similar to [this one](https://eprint.iacr.org/2019/328)... ;)
Sergei Tikhomirov
CC BY-SA 4.0
2019-05-08T15:56:22.437Z
I think it would be interesting because if there are say 10 hops and I just take 1 more Satoshi than I advertised, then only the last guys will send an error and the originator of the transaction will not who the bad guy is
Ugam Kamat
CC BY-SA 4.0
2019-05-08T17:00:27.423Z
Yeah the probing attack is well known. I don't see a direct relation. The proving attack usually would use a circular onion and you yourself would fail the htlc / onion
Rene Pickhardt
CC BY-SA 4.0
2019-05-08T19:56:10.447Z
@RenePickhardt I guess I have some reading left to do ;)
Ugam Kamat
CC BY-SA 4.0
2019-05-08T14:34:17.997Z
2019-05-08T14:34:17.997Z
Rene Pickhardt
<p>How are fees negotiated in multi-hop payments in Lightning?</p>

<p>Imagine a four-hop payment: Alice -- Bob -- Charlie -- Dave. Bob and Charlie advertise fees of 100 sat each, Alice thinks it's reasonable and starts routing the payment through this route. Does Bob know which part of the expected payment is intended to be a fee? What is Bob forwards the payment to Charlie taking 120, 150, or 200 sat instead of 100 -- what does Charlie do?</p>

<p>Is there anything that prevents intermediary nodes from lying about their fees?</p>

<transaction-fees><lightning-network>
Fee negotiations in Lightning
Sergei Tikhomirov
# Fee negotiations in Lightning

(Asked by: username_0 on 2019-05-08)

How are fees negotiated in multi-hop payments in Lightning?

Imagine a four-hop payment: Alice -- Bob -- Charlie -- Dave. Bob and Charlie advertise fees of 100 sat each, Alice thinks it's reasonable and starts routing the payment through this route. Does Bob know which part of the expected payment is intended to be a fee? What is Bob forwards the payment to Charlie taking 120, 150, or 200 sat instead of 100 -- what does Charlie do?

Is there anything that prevents intermediary nodes from lying about their fees?

**Tags:** transaction-fees, lightning-network


---

## 2 answers

### Answer by username_1 on 2019-05-08. Score: 3 | Accepted answer

Nodes advertise the fees for forwarding over a channel as part of a [`channel_update`](https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md#the-channel_update-message) message. The update should be sent as soon as a [`channel_announcement`](https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md#the-channel_announcement-message) is sent. Each party can decide its own fees for the channel.

For private channels, nodes advertise the fees inside the `r` tagged field of the [BOLT#11](https://github.com/lightningnetwork/lightning-rfc/blob/master/11-payment-encoding.md) invoice.

When forwarding a payment, your node must calculate the required fee for each hop and add it to the payment requested in the invoice. When each intermediate hop receives an [`update_add_htlc`](https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#adding-an-htlc-update_add_htlc) message, they will unwrap one level of the [onion packet](https://github.com/lightningnetwork/lightning-rfc/blob/master/04-onion-routing.md#packet-structure), which contains an `amt_to_forward`. This is subtracted from the `amount_msat` in the `update_add_htlc` message, and the difference is the fee paid for this hop.

If the hop determines that the fee is insufficient, they respond to the sender with [`fee_insufficient` error](https://github.com/lightningnetwork/lightning-rfc/blob/master/04-onion-routing.md#failure-messages) as part of an [`update_fail_htlc`](https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#removing-an-htlc-update_fulfill_htlc-update_fail_htlc-and-update_fail_malformed_htlc) message. This message also includes the most recent `channel_update` for this channel so that the payer can re-attempt the payment with new fees.

There is always the possibility of a race condition where fees may have changed between the most recently received `channel_update` and the payment attempt. This is minimized by including the `channel_update` as part of the failure as above.

If the payment at the last hop is too small, they will respond with a failure containing the `incorrect_or_unknown_payment_details` failure code.

> **Comments:**
> **username_2**: We need to coordinate in future (: I was typing on my mobile where putting all these links and syntax highlighting is annoying. Anyway plus 1 for nice onside explainations instead of referring to a tutorial video like I did.  

---

### Answer by username_2 on 2019-05-08. Score: 4

The situation you describe cannot happen / would lead to a routing failure. I have created an [11 minute video explaining how htlcs are used in onion routing](https://youtu.be/toarjBSPFqI). Parts of the video (rather at the end) explain how fees are encoded within the sent onion. I think watching that video is the quickest way to understand the fee model of the lightning network.

A tl;dw (too long didn't watch) answer looks like that:

If a node decides to maliciously collect a larger fee and forward the onion. The next hop will not be able to collect the fee as it advertised and will fail the routing process. In your setting this means charlie decrypts his onion and sees which amount to forward and sees from the incoming htlc that it would only receive a fee of 80 / 50 or 0 Satoshi instead of the advertised 100. As said charlie would fail the onion but not be able to blame Bob. Actually obs behavior would confuse Alice as she chose the correct fees. Alice could assume Bob was a bad routing node and elect a different part. However this mechanism is as far as I know not implemented yet.

> **Comments:**
> **username_0**: By "this mechanism" in the last sentence do you mean Alice marking Bob as a bad node? (BTW, the tiny envelopes you use in the video are amazing, where did you even get those things :)  
> **username_3**: What if we extended this argument by one more party? Alice sending BTC to Eric via bob, charlie and dave. Assume charlie is the bad apple in the lot and consumes all the remaining fee in the hop. How would Alice know whether it is Bob or Charlie?  
> **username_2**: Since the fees are part of the onion noone in the chain knows what the payment amount is and how much fees are in the onion in total... On the other hand I hope to remember correctly that the node that can't forward the onion because the prev took too much fees and back an failure message of type 12 `fee _insufficient` cf: https://github.com/lightningnetwork/lightning-rfc/blob/master/04-onion-routing.md#failure-messages  
> **username_3**: @username_2 That was helpful. One more scenario comes to mind. Assume Alice forwarded with 150 sats fee assuming bob, charlie and dave would take 50 stas each. Now let us assume Bob is the bad guy. Bob consumed 90 sats, and charlie consumed 50 sats. Dave will send a `fee_insufficient` message, but it would be hard for Alice to figure out who was the bad guy  
> **username_0**: What I see here is a violation of the "don't explain to the attacker why the error happened" security principle, screaming for probing attacks similar to [this one](https://eprint.iacr.org/2019/328)... ;)  
> **username_3**: I think it would be interesting because if there are say 10 hops and I just take 1 more Satoshi than I advertised, then only the last guys will send an error and the originator of the transaction will not who the bad guy is  
> **username_2**: Yeah the probing attack is well known. I don't see a direct relation. The proving attack usually would use a circular onion and you yourself would fail the htlc / onion  
> **username_3**: @username_2 I guess I have some reading left to do ;)  

---

