rich1.0npub1vjzmc45k8dgujppapp2ue20h3l9apnsntgv4c0ukncvv549q64gsz4x8ddhttps://nostr.ae/npub1vjzmc45k8dgujppapp2ue20h3l9apnsntgv4c0ukncvv549q64gsz4x8ddnjumphttps://nostr.ae📅 Original date posted:2023-02-16 📝 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>