{"type":"rich","version":"1.0","author_name":"npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcu","author_url":"https://nostr.ae/npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcu","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2023-02-15\n📝 Original message:\nOn 2/14/23 11:36 PM, Joost Jager wrote:\n\u003e     But how do you decide to set it without a credit relationship? Do I measure my channel and set the\n\u003e \n\u003e     bit because the channel is \"usually\" (at what threshold?) saturating in the inbound direction? What\n\u003e     happens if this changes for an hour and I get unlucky? Did I just screw myself?\n\u003e \n\u003e \n\u003e As a node setting the flag, you'll have to make sure you open new channels, rebalance or swap-in in \n\u003e time to maintain outbound liquidity. That's part of the game of running an HA channel.\n\nDefine \"in time\" in a way that results in senders not punishing you for not meeting your \"HA \nguarantees\" due to a large flow. I don't buy that this results in anything other than pressure to \nadd credit.\n\n\u003e      \u003e How can you be sure about this? This isn't publicly visible data.\n\u003e \n\u003e     Sure it is! https://river.com/learn/files/river-lightning-report.pdf\n\u003e     \u003chttps://river.com/learn/files/river-lightning-report.pdf\u003e\n\u003e \n\u003e \n\u003e Some operators publish data, but are the experiences of one of the most well connected (custodial) \n\u003e nodes representative for the network as a whole when evaluating payment success rates? In the end \n\u003e you can't know what's happening on the lightning network.\n\nRight, that was my above point about fetching scoring data - there's three relevant \"buckets\" of \nnodes, I think - (a) large nodes sending lots of payments, like the above, (b) \"client nodes\" that \njust connect to an LSP or two, (c) nodes that route some but don't send a lot of payments (but do \nsend *some* payments), and may have lots or not very many channels.\n\n(a) I think we're getting there, and we don't need to add anything extra for this use-case beyond \nthe network maturing and improving our scoring algorithms.\n(b) I think is trivially solved by downloading the data from a node in category (a), presumably the \nLSP(s) in question (see other branch of this thread)\n(c) is trickier, but I think the same solution of just fetching semi-trusted data here more than \nsufficies. For most routing nodes that don't send a lot of payments we're talking about a very small \namount of payments, so trusting a third-party for scoring data seems reasonable.\n\nOnce we do that, everyone gets a similar experience as the River report :).\n\nMatt"}