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 create two classes of nodes based on availability, according to a post on the Lightning-dev mailing list. The post argued that communicating reliability up front would not work, and penalising nodes after the fact would be ineffective. The author also said relying on third-party information to track reliability would be problematic. Instead, the post suggested using high-availability signalling to make local reliability tracking more efficient.
📝 Original message:
Hi Christian,
> And after all this rambling, let's get back to the topic at hand: I
> don't think enshrining the differences of availability in the protocol,
> thus creating two classes of nodes, is a desirable
> feature.
Yes so to be clear, the HA signaling is not on the node level but on the
channel level. So each node can decide per channel whether they want to
potentially attract additional traffic at the cost of severe penalties (or
avoidance if you want to use a different wording) if the channel can't be
used. They can still maintain a set of less reliable channels along side.
> Communicating up-front that I intend to be reliable does
> nothing, and penalizing after the fact isn't worth much due to the
> repeat interactions issue.
I think it is currently quite common for pathfinders to try another channel
of the same node for the payment at hand. Or re-attempt the same channel
for a future payment to the same destination. I understand the repeat
interactions issue, but not sure about the extent to which it applies to
lightning in practice. A think a common pattern for payments in general is
to pay to the same destinations repeatedly, for example for a daily coffee.
> It'd be even worse if now we had to rely on a
> third party to aggregate and track the reliability, in order to get
> enough repeat interactions to build a good model of their liquidity,
> since we're now back in the hearsay world, and the third party can feed
> us wrong information to maximize their profits.
>
Yes, using 3rd party info seems difficult. As mentioned in my reply to
Matt, the idea of HA signaling is to make local reliability tracking more
efficient so that it becomes less likely that senders need to rely on
external aggregators for their view on the network.
Joost
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230214/a7f355e6/attachment-0001.html>;
🗒️ Summary of this message: The Lightning Network should not create two classes of nodes based on availability, according to a post on the Lightning-dev mailing list. The post argued that communicating reliability up front would not work, and penalising nodes after the fact would be ineffective. The author also said relying on third-party information to track reliability would be problematic. Instead, the post suggested using high-availability signalling to make local reliability tracking more efficient.
📝 Original message:
Hi Christian,
> And after all this rambling, let's get back to the topic at hand: I
> don't think enshrining the differences of availability in the protocol,
> thus creating two classes of nodes, is a desirable
> feature.
Yes so to be clear, the HA signaling is not on the node level but on the
channel level. So each node can decide per channel whether they want to
potentially attract additional traffic at the cost of severe penalties (or
avoidance if you want to use a different wording) if the channel can't be
used. They can still maintain a set of less reliable channels along side.
> Communicating up-front that I intend to be reliable does
> nothing, and penalizing after the fact isn't worth much due to the
> repeat interactions issue.
I think it is currently quite common for pathfinders to try another channel
of the same node for the payment at hand. Or re-attempt the same channel
for a future payment to the same destination. I understand the repeat
interactions issue, but not sure about the extent to which it applies to
lightning in practice. A think a common pattern for payments in general is
to pay to the same destinations repeatedly, for example for a daily coffee.
> It'd be even worse if now we had to rely on a
> third party to aggregate and track the reliability, in order to get
> enough repeat interactions to build a good model of their liquidity,
> since we're now back in the hearsay world, and the third party can feed
> us wrong information to maximize their profits.
>
Yes, using 3rd party info seems difficult. As mentioned in my reply to
Matt, the idea of HA signaling is to make local reliability tracking more
efficient so that it becomes less likely that senders need to rely on
external aggregators for their view on the network.
Joost
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230214/a7f355e6/attachment-0001.html>;