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