Fee negotiations in Lightning

Question

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?

Answer 1

Nodes advertise the fees for forwarding over a channel as part of a channel_update message. The update should be sent as soon as a channel_announcement 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 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 message, they will unwrap one level of the onion packet, 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 as part of an update_fail_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.

Answer 2

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