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. > 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. > 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. > 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. > 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. Joost
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
