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