Hi Joost, I’m not sure I agree that lightning is “capital efficient” (or even close to it), but more generally I don’t see why this needs a signal.
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. 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 ignores the myriad of “at what threshold do you signal HA” issues, which likely make such a signal DOA, anyway. 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. 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. :) Matt > On Feb 13, 2023, at 06:46, Joost Jager <joost.ja...@gmail.com> wrote: > > > Hi, > > For a long time I've held the expectation that eventually payers on the > lightning network will become very strict about node performance. That they > will require a routing node to operate flawlessly or else apply a hefty > penalty such as completely avoiding the node for an extended period of time - > multiple weeks. The consequence of this is that routing nodes would need to > manage their liquidity meticulously because every failure potentially has a > large impact on future routing revenue. > > I think movement in this direction is important to guarantee competitiveness > with centralised payment systems and their (at least theoretical) ability to > process a payment in the blink of an eye. A lightning wallet trying multiple > paths to find one that works doesn't help with this. > > A common argument against strict penalisation is that it would lead to less > efficient use of capital. Routing nodes would need to maintain pools of > liquidity to guarantee successes all the time. My opinion on this is that > lightning is already enormously capital efficient at scale and that it is > worth sacrificing a slight part of that efficiency to also achieve the lowest > possible latency. > > This brings me to the actual subject of this post. Assuming strict > penalisation is good, it may still not be ideal to flip the switch from one > day to the other. Routing nodes may not offer the required level of service > yet, causing senders to end up with no nodes to choose from. > > One option is to gradually increase the strength of the penalties, so that > routing nodes are given time to adapt to the new standards. This does require > everyone to move along and leaves no space for cheap routing nodes with less > leeway in terms of liquidity. > > Therefore I am proposing another way to go about it: extend the > `channel_update` field `channel_flags` with a new bit that the sender can use > to signal `highly_available`. > > It's then up to payers to decide how to interpret this flag. One way could be > to prefer `highly_available` channels during pathfinding. But if the routing > node then returns a failure, a much stronger than normal penalty will be > applied. For routing nodes this creates an opportunity to attract more > traffic by marking some channels as `highly_available`, but it also comes > with the responsibility to deliver. > > Without shadow channels, it is impossible to guarantee liquidity up to the > channel capacity. It might make sense for senders to only assume high > availability for amounts up to `htlc_maximum_msat`. > > A variation on this scheme that requires no extension of `channel_update` is > to signal availability implicitly through routing fees. So the more expensive > a channel is, the stronger the penalty that is applied on failure will be. It > seems less ideal though, because it could disincentivize cheap but reliable > channels on high traffic links. > > The effort required to implement some form of a `highly_available` flag seem > limited and it may help to get payment success rates up. Interested to hear > your thoughts. > > Joost > _______________________________________________ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
