Thomas Steenholdt [ARCHIVE] on Nostr: š Original date posted:2018-04-10 š Original message: Hi ZmnSCPxj, I came up ...
š
Original date posted:2018-04-10
š Original message:
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? :-)
/Thomas
________________________________
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:
Hi,
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.
Example:
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.
Regards,
ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180410/9bead1af/attachment.html>;
š Original message:
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? :-)
/Thomas
________________________________
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:
Hi,
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.
Example:
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.
Regards,
ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180410/9bead1af/attachment.html>;