Matt Corallo [ARCHIVE] on Nostr: 📅 Original date posted:2023-02-15 🗒️ Summary of this message: Running a ...
📅 Original date posted:2023-02-15
🗒️ Summary of this message: Running a highly available (HA) channel on the Lightning Network requires maintaining outbound liquidity by opening new channels, rebalancing, or swapping-in in time. Fetching semi-trusted data from large nodes, LSPs, and third-party scoring data can help evaluate payment success rates.
📝 Original message:
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
🗒️ Summary of this message: Running a highly available (HA) channel on the Lightning Network requires maintaining outbound liquidity by opening new channels, rebalancing, or swapping-in in time. Fetching semi-trusted data from large nodes, LSPs, and third-party scoring data can help evaluate payment success rates.
📝 Original message:
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