{"type":"rich","version":"1.0","author_name":"npub1aslmpzentw224n3s6yccru4dq2qdlx7rfudfnqevfck637cjt6esswfqmx","author_url":"https://nostr.ae/npub1aslmpzentw224n3s6yccru4dq2qdlx7rfudfnqevfck637cjt6esswfqmx","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2023-02-14\n📝 Original message:\nHi Christian,\n\n\n\u003e And after all this rambling, let's get back to the topic at hand: I\n\u003e don't think enshrining the differences of availability in the protocol,\n\u003e thus creating two classes of nodes, is a desirable\n\u003e feature.\n\n\nYes so to be clear, the HA signaling is not on the node level but on the\nchannel level. So each node can decide per channel whether they want to\npotentially attract additional traffic at the cost of severe penalties (or\navoidance if you want to use a different wording) if the channel can't be\nused. They can still maintain a set of less reliable channels along side.\n\n\n\u003e Communicating up-front that I intend to be reliable does\n\u003e nothing, and penalizing after the fact isn't worth much due to the\n\u003e repeat interactions issue.\n\n\nI think it is currently quite common for pathfinders to try another channel\nof the same node for the payment at hand. Or re-attempt the same channel\nfor a future payment to the same destination. I understand the repeat\ninteractions issue, but not sure about the extent to which it applies to\nlightning in practice. A think a common pattern for payments in general is\nto pay to the same destinations repeatedly, for example for a daily coffee.\n\n\n\u003e It'd be even worse if now we had to rely on a\n\u003e third party to aggregate and track the reliability, in order to get\n\u003e enough repeat interactions to build a good model of their liquidity,\n\u003e since we're now back in the hearsay world, and the third party can feed\n\u003e us wrong information to maximize their profits.\n\u003e\n\nYes, using 3rd party info seems difficult. As mentioned in my reply to\nMatt, the idea of HA signaling is to make local reliability tracking more\nefficient so that it becomes less likely that senders need to rely on\nexternal aggregators for their view on the network.\n\nJoost\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230214/a7f355e6/attachment-0001.html\u003e"}