rich1.0npub1aslmpzentw224n3s6yccru4dq2qdlx7rfudfnqevfck637cjt6esswfqmxhttps://nostr.ae/npub1aslmpzentw224n3s6yccru4dq2qdlx7rfudfnqevfck637cjt6esswfqmxnjumphttps://nostr.ae📅 Original date posted:2023-02-14 📝 Original message: Hi Christian, > And after all this rambling, let's get back to the topic at hand: I > don't think enshrining the differences of availability in the protocol, > thus creating two classes of nodes, is a desirable > feature. Yes so to be clear, the HA signaling is not on the node level but on the channel level. So each node can decide per channel whether they want to potentially attract additional traffic at the cost of severe penalties (or avoidance if you want to use a different wording) if the channel can't be used. They can still maintain a set of less reliable channels along side. > Communicating up-front that I intend to be reliable does > nothing, and penalizing after the fact isn't worth much due to the > repeat interactions issue. I think it is currently quite common for pathfinders to try another channel of the same node for the payment at hand. Or re-attempt the same channel for a future payment to the same destination. I understand the repeat interactions issue, but not sure about the extent to which it applies to lightning in practice. A think a common pattern for payments in general is to pay to the same destinations repeatedly, for example for a daily coffee. > It'd be even worse if now we had to rely on a > third party to aggregate and track the reliability, in order to get > enough repeat interactions to build a good model of their liquidity, > since we're now back in the hearsay world, and the third party can feed > us wrong information to maximize their profits. > Yes, using 3rd party info seems difficult. As mentioned in my reply to Matt, the idea of HA signaling is to make local reliability tracking more efficient so that it becomes less likely that senders need to rely on external aggregators for their view on the network. Joost -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230214/a7f355e6/attachment-0001.html>