{"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 Matt,\n\nIf nodes start aggressively preferring routes through nodes that reliably\n\u003e route payments (which I believe lnd already does, in effect, to some large\n\u003e extent), they should do so by measurement, not signaling.\n\u003e\n\nThe signaling is intended as a way to make measurement more efficient. If a\nnode signals that a particular channel is HA and it fails, no other\nmeasurements on that same node need to be taken by the sender. They can\nskip the node altogether for a longer period of time.\n\n\n\u003e In practice, many channels on the network are “high availability” today,\n\u003e but only in one direction (I.e. they aren’t regularly spliced/rebalanced\n\u003e and are regularly unbalanced). A node strongly preferring a high payment\n\u003e success rate *should* prefer such a channel, but in your scheme would not.\n\u003e\n\nThis shouldn't be a problem, because the HA signaling is also directional.\nEach end can decide independently on whether to add the flag for a\nparticular channel.\n\n\n\u003e This ignores the myriad of “at what threshold do you signal HA” issues,\n\u003e which likely make such a signal DOA, anyway.\n\u003e\n\nI think this is a product of sender preference for HA channels and the\nseverity of the penalty if an HA channel fails. Given this, routing nodes\nwill need to decide whether they can offer a service level that increases\ntheir routing revenue overall if they would signal HA. It is indeed\ndynamic, but I think the market is able to work it out.\n\n\n\u003e Finally, I’m very dismayed at this direction in thinking on how ln should\n\u003e work - nodes should be measuring the network and routing over paths that it\n\u003e thinks are reliable for what it wants, *robustly over an unreliable\n\u003e network*. We should absolutely not be expecting the lightning network to be\n\u003e built out of high reliability nodes, that creates strong centralization\n\u003e pressure. To truly meet a “high availability” threshold, realistically,\n\u003e you’d need to be able to JIT 0conf splice-in, which would drive lightning\n\u003e to actually being a credit network.\n\u003e\n\nDifferent people can have different opinions about how ln should work, that\nis fine. I see a trade-off between the reliability of the network and the\nbarrier of entry, and I don't think the optimum is on one of the ends of\nthe scale.\n\n\n\u003e With reasonable volume, lightning today is very reliable and relatively\n\u003e fast, with few retries required. I don’t think we need to change anything\n\u003e to fix it. :)\n\u003e\n\nHow can you be sure about this? This isn't publicly visible data.\n\nJoost\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230214/da656e7a/attachment.html\u003e"}