{"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-14\n📝 Original message:\nOn 2/14/23 2:34 AM, Joost Jager wrote:\n\u003e Hi Matt,\n\u003e \n\u003e     If nodes start aggressively preferring routes through nodes that reliably route payments (which\n\u003e     I believe lnd already does, in effect, to some large extent), they should do so by measurement,\n\u003e     not signaling.\n\u003e \n\u003e \n\u003e The signaling is intended as a way to make measurement more efficient. If a node signals that a \n\u003e particular channel is HA and it fails, no other measurements on that same node need to be taken by \n\u003e the sender. They can skip the node altogether for a longer period of time.\n\nBut as a lightning node I don't actually care if a node is binary good/bad. I care about what \nsuccess rate a node has. If you make the decision binary, suddenly in order for a node to be \"good\" \nI *have* to establish a credit relationship with my peers (i.e. support 0conf splicing). I think \nthat is a very, very bad thing to do to the lightning network.\n\nIf someone wants to establish such a relationship with their peers, so be it, but as developers we \nshould strongly avoid adding features which push node operators in that direction, and part of that \nis writing good routing scoring so that we aren't boxing ourselves into some binary good/bad idea of \na node but rather estimating liquidity.\n\nHonestly this just strikes me as developers being too lazy to do things right. If we do things \ncarefully and we are seeing issues then we can consider breaking lightning, but until we give it a \ngood shot, let's not!\n\n\u003e     In practice, many channels on the network are “high availability” today, but only in one\n\u003e     direction (I.e. they aren’t regularly spliced/rebalanced and are regularly unbalanced). A node\n\u003e     strongly preferring a high payment success rate *should* prefer such a channel, but in your\n\u003e     scheme would not.\n\u003e \n\u003e \n\u003e This shouldn't be a problem, because the HA signaling is also directional. Each end can decide \n\u003e independently on whether to add the flag for a particular channel.\n\nBut how do you decide to set it without a credit relationship? Do I measure my channel and set the \nbit because the channel is \"usually\" (at what threshold?) saturating in the inbound direction? What \nhappens if this changes for an hour and I get unlucky? Did I just screw myself?\n\n\u003e     This ignores the myriad of “at what threshold do you signal HA” issues, which likely make such a\n\u003e     signal DOA, anyway.\n\u003e \n\u003e \n\u003e I think this is a product of sender preference for HA channels and the severity of the penalty if an \n\u003e HA channel fails. Given this, routing nodes will need to decide whether they can offer a service \n\u003e level that increases their routing revenue overall if they would signal HA. It is indeed dynamic, \n\u003e but I think the market is able to work it out.\n\nI'm afraid this is going to immediately fall into a cargo cult of \"set the bit\" vs \"don't set the \nbit\" and we'll never get useful data out of it. But you may be right.\n\n\u003e     Finally, I’m very dismayed at this direction in thinking on how ln should work - nodes should be\n\u003e     measuring the network and routing over paths that it thinks are reliable for what it wants,\n\u003e     *robustly over an unreliable network*. We should absolutely not be expecting the lightning\n\u003e     network to be built out of high reliability nodes, that creates strong centralization pressure.\n\u003e     To truly meet a “high availability” threshold, realistically, you’d need to be able to JIT 0conf\n\u003e     splice-in, which would drive lightning to actually being a credit network.\n\u003e \n\u003e \n\u003e Different people can have different opinions about how ln should work, that is fine. I see a \n\u003e trade-off between the reliability of the network and the barrier of entry, and I don't think the \n\u003e optimum is on one of the ends of the scale.\n\nMy point wasn't that lightning should be unreliable, but rather a reliable network build on \nunreliable hops. I'm very confident we can accomplish that without falling back to forcing nodes to \nestablish credit to meet \"reliability requirements\".\n\n\u003e     With reasonable volume, lightning today is very reliable and relatively fast, with few retries\n\u003e     required. I don’t think we need to change anything to fix it. :)\n\u003e \n\u003e \n\u003e How can you be sure about this? This isn't publicly visible data.\n\nSure it is! https://river.com/learn/files/river-lightning-report.pdf\n\nI'm also quite confident we can do substantially better than this.\n\nMatt"}