What is Nostr?
ZmnSCPxj [ARCHIVE] /
npub1g5z…ms3l
2023-06-09 12:49:58
in reply to nevent1q…z357

ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2018-04-11 📝 Original message: Good morning Thomas, > ...

📅 Original date posted:2018-04-11
📝 Original message:
Good morning Thomas,

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

No, channel balance of each peer on the channel is not revealed on node gossip.

Logically, invert the question: do you want to report how much you spend/receive on each of your channels to the network? Do you want to report how much you own on Lightning to be reported to everyone on Lightning?

Since the balance on each peer is effectively the amount of money each peer owns on that channel, and each change to that balance represents a send/receive on that channel, you will not want to report your balance, and any changes in that balance, to the entire network.

Logically you can then expect not to receive such updates from anybody else, either.

How do real-life implementations like c-lightning get your payment routes then? By brute-force trial-and-error. If one channel on a route fails, we just mark it as temporarily unuseable and plot a new route that does not include that channel. If a channel on THAT route fails, we mark it and plot another route. And so on until we run out of possible routes because all possible channels to the destination are blocked.

--

Note though that you can easily get the channel total capacity for each channel (just not how the channel is divided between the two parties).

Each published channel has a short channel id composed of blockheight, transaction index within block, and output index within transaction. This identifies a specific txout on the blockchain you are using. If that txout is spent, then the channel has been closed and you cannot use it for routing. If that txout is unspent, then the value of that UTXO is the total channel capacity. C-lightning records this but does not (yet) use the total channel capacity (logically if your payment would exceed the total channel capacity then the channel is unuseable for that payment, and if it is a large fraction of that total channel capacity then it is very unlikely to be useable); but the existing brute-force trial-and-error algorithm works well enough already.

Regards,
ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180410/612e3351/attachment.html>;
Author Public Key
npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3l