[Lightning-dev] High level fee mechanics

Thomas Steenholdt TSteenholdt at cascadetechnologypartners.com
Tue Apr 10 15:02:39 UTC 2018

Hi ZmnSCPxj,

I came up with a followup question...

Does node GOSSIP also reveal the funding/balance of channels, same way it does the fees?

I'm trying to understand how to make an informed payment routing decision as a sender, based on the fees (that you have already explained), but also the funding/balance of each channel, to select the cheapest route with the highest chance of success.

I have looked through the RFC and can't seem to find an explanation on whether or not the channel funding/balance information is available from GOSSIP or how else you'd handle this kind of thing?

I was hoping you might have a short explanation for this stuff as well? :-)


From: ZmnSCPxj <ZmnSCPxj at protonmail.com>
Sent: Sunday, March 18, 2018 8:48:57 PM
To: Thomas Steenholdt
Cc: lightning-dev at lists.linuxfoundation.org
Subject: Re: [Lightning-dev] High level fee mechanics

Good morning Thomas,

Sent with ProtonMail<https://protonmail.com> Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On March 19, 2018 6:24 AM, Thomas Steenholdt <TSteenholdt at cascadetechnologypartners.com> wrote:


I've been trying to figure out the mechanics of Lightning fees, especially in the case of routed payments. Unfortunately, I haven't had any success in finding a high level description on the topic.

I'm hoping somebody is able to point me in the right direction?

BOLT spec https://github.com/lightningnetwork/lightning-rfc contains everything, but is very detailed and contains the topic in multiple places.


A multi-hop routed payment where A needs to pay D through B and C. Established channels are A -> B -> C -> D.

What I'm looking for is a high level explanation of how fees are established, announced and ultimately claimed in a payment like this. Some of the questions that come to mind are:

- Does A know ahead of time the fees on B and C, or only when trying to set up the payment? And how?

Yes.  Node gossip, the `channel_update` message in BOLT#7.  This message, contains `fee_base_msat` and `fee_proportional_millionths`.  For each channel, there are two `channel_update` messages, one from each direction.  For example B<->C channel, B announces its fee for B->C transfers while C announnces its fee for C->B transfers.

The A may have obsolete information about fees (e.g. B or C change their fee but their `channel_update` has not propagated to A yet).  In this case, payment routing will fail, but the `channel_update` will also be sent as part of the error message returned by payment routing failure.

- How does A know the amount of fees that need to be added to the payment to cover all fees?

It computes it.  If D is to be given a payment with value `msatoshi` then it computes first the C->D fee, which is the C->D `fee_base_msat` +  (C->D `fee_proportion_millionts` * `msatoshi` / 1,000,000).  Add that to `msatoshi` and that is the payment that needs to reach C, so A computes the payment from B->C similarly, except the `msatoshi` is replaced with the payment that should reach C.  Then A knows how much it has to give to B.

- Is D aware of the full amount including fees or is that somehow hidden?

No.  D is only aware of how much C offers it.

- How are the fees actually claimed (who ends up paying whom)?

A offer B a value that is higher than what A instruct B to forward to C.  The difference is the fee.  Since the highest value is at the source A, A is the one, who ends up paying the entire fee.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180410/9bead1af/attachment.html>

More information about the Lightning-dev mailing list