Antoine Riard [ARCHIVE] on Nostr: 📅 Original date posted:2023-02-16 🗒️ Summary of this message: Matt Corallo ...
📅 Original date posted:2023-02-16
🗒️ Summary of this message: Matt Corallo and Joost Jager discuss the challenges of maintaining outbound liquidity in highly available lightning channels, and the need for reliable scoring data.
📝 Original message:
Yeah definitely looking forward to talk more about highly available
lightning channels. During next LN channel jamming meetup! .
Le jeu. 16 févr. 2023 à 00:43, Matt Corallo <lf-lists at mattcorallo.com> a
écrit :
>
>
> On 2/14/23 11:36 PM, Joost Jager wrote:
> > But how do you decide to set it without a credit relationship? Do I
> measure my channel and set the
> >
> > bit because the channel is "usually" (at what threshold?) saturating
> in the inbound direction? What
> > happens if this changes for an hour and I get unlucky? Did I just
> screw myself?
> >
> >
> > As a node setting the flag, you'll have to make sure you open new
> channels, rebalance or swap-in in
> > time to maintain outbound liquidity. That's part of the game of running
> an HA channel.
>
> Define "in time" in a way that results in senders not punishing you for
> not meeting your "HA
> guarantees" due to a large flow. I don't buy that this results in anything
> other than pressure to
> add credit.
>
> > > How can you be sure about this? This isn't publicly visible data.
> >
> > Sure it is! https://river.com/learn/files/river-lightning-report.pdf
> > <https://river.com/learn/files/river-lightning-report.pdf>;
> >
> >
> > Some operators publish data, but are the experiences of one of the most
> well connected (custodial)
> > nodes representative for the network as a whole when evaluating payment
> success rates? In the end
> > you can't know what's happening on the lightning network.
>
> Right, that was my above point about fetching scoring data - there's three
> relevant "buckets" of
> nodes, I think - (a) large nodes sending lots of payments, like the above,
> (b) "client nodes" that
> just connect to an LSP or two, (c) nodes that route some but don't send a
> lot of payments (but do
> send *some* payments), and may have lots or not very many channels.
>
> (a) I think we're getting there, and we don't need to add anything extra
> for this use-case beyond
> the network maturing and improving our scoring algorithms.
> (b) I think is trivially solved by downloading the data from a node in
> category (a), presumably the
> LSP(s) in question (see other branch of this thread)
> (c) is trickier, but I think the same solution of just fetching
> semi-trusted data here more than
> sufficies. For most routing nodes that don't send a lot of payments we're
> talking about a very small
> amount of payments, so trusting a third-party for scoring data seems
> reasonable.
>
> Once we do that, everyone gets a similar experience as the River report :).
>
> Matt
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230217/a4c356bf/attachment.html>;
🗒️ Summary of this message: Matt Corallo and Joost Jager discuss the challenges of maintaining outbound liquidity in highly available lightning channels, and the need for reliable scoring data.
📝 Original message:
Yeah definitely looking forward to talk more about highly available
lightning channels. During next LN channel jamming meetup! .
Le jeu. 16 févr. 2023 à 00:43, Matt Corallo <lf-lists at mattcorallo.com> a
écrit :
>
>
> On 2/14/23 11:36 PM, Joost Jager wrote:
> > But how do you decide to set it without a credit relationship? Do I
> measure my channel and set the
> >
> > bit because the channel is "usually" (at what threshold?) saturating
> in the inbound direction? What
> > happens if this changes for an hour and I get unlucky? Did I just
> screw myself?
> >
> >
> > As a node setting the flag, you'll have to make sure you open new
> channels, rebalance or swap-in in
> > time to maintain outbound liquidity. That's part of the game of running
> an HA channel.
>
> Define "in time" in a way that results in senders not punishing you for
> not meeting your "HA
> guarantees" due to a large flow. I don't buy that this results in anything
> other than pressure to
> add credit.
>
> > > How can you be sure about this? This isn't publicly visible data.
> >
> > Sure it is! https://river.com/learn/files/river-lightning-report.pdf
> > <https://river.com/learn/files/river-lightning-report.pdf>;
> >
> >
> > Some operators publish data, but are the experiences of one of the most
> well connected (custodial)
> > nodes representative for the network as a whole when evaluating payment
> success rates? In the end
> > you can't know what's happening on the lightning network.
>
> Right, that was my above point about fetching scoring data - there's three
> relevant "buckets" of
> nodes, I think - (a) large nodes sending lots of payments, like the above,
> (b) "client nodes" that
> just connect to an LSP or two, (c) nodes that route some but don't send a
> lot of payments (but do
> send *some* payments), and may have lots or not very many channels.
>
> (a) I think we're getting there, and we don't need to add anything extra
> for this use-case beyond
> the network maturing and improving our scoring algorithms.
> (b) I think is trivially solved by downloading the data from a node in
> category (a), presumably the
> LSP(s) in question (see other branch of this thread)
> (c) is trickier, but I think the same solution of just fetching
> semi-trusted data here more than
> sufficies. For most routing nodes that don't send a lot of payments we're
> talking about a very small
> amount of payments, so trusting a third-party for scoring data seems
> reasonable.
>
> Once we do that, everyone gets a similar experience as the River report :).
>
> Matt
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230217/a4c356bf/attachment.html>;