Joost Jager [ARCHIVE] on Nostr: 📅 Original date posted:2023-02-14 🗒️ Summary of this message: The Lightning ...
đź“… Original date posted:2023-02-14
🗒️ Summary of this message: The Lightning Network should not be built out of high reliability nodes to avoid centralization pressure, according to a developer. Nodes should measure the network and route over paths that are reliable for what they want, robustly over an unreliable network.
đź“ť Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230214/da656e7a/attachment.html>;
🗒️ Summary of this message: The Lightning Network should not be built out of high reliability nodes to avoid centralization pressure, according to a developer. Nodes should measure the network and route over paths that are reliable for what they want, robustly over an unreliable network.
đź“ť Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230214/da656e7a/attachment.html>;