From lf-lists at mattcorallo.com Thu Feb 16 00:42:54 2023 From: lf-lists at mattcorallo.com (Matt Corallo) Date: Wed, 15 Feb 2023 16:42:54 -0800 Subject: [Lightning-dev] Highly Available Lightning Channels In-Reply-To: References: <396b3e57-c027-d3a3-560f-fe393df0d2d8@mattcorallo.com> Message-ID: <892a9cf1-d066-12d4-bc02-387c93c8a644@mattcorallo.com> 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 > > > > 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