📅 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>;
Joost Jager [ARCHIVE] /
npub1as…wfqmx
2023-06-09 15:12:40
in reply to nevent1q…40f2
Author Public Key
npub1aslmpzentw224n3s6yccru4dq2qdlx7rfudfnqevfck637cjt6esswfqmxPublished at
2023-06-09 15:12:40Event JSON
{
"id": "f5670f1456a26ce2a80138c606da2c6cdee59beacf4d36a1c9f97d0786215f6c",
"pubkey": "ec3fb08b335b94aace30d13181f2ad0280df9bc34f1a99832c4e2da8fb125eb3",
"created_at": 1686316360,
"kind": 1,
"tags": [
[
"e",
"93b1d238fcaae143ea8ae5d6f9ddc582df195f32146237959ceb0a833db784e0",
"",
"root"
],
[
"e",
"1718577e88033482885bbe9c1992851c8b9c74a21497922022e83694998becc8",
"",
"reply"
],
[
"p",
"cd753aa8fbc112e14ffe9fe09d3630f0eff76ca68e376e004b8e77b687adddba"
]
],
"content": "📅 Original date posted:2023-02-14\n🗒️ 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.\n📝 Original message:\nHi Christian,\n\n\n\u003e And after all this rambling, let's get back to the topic at hand: I\n\u003e don't think enshrining the differences of availability in the protocol,\n\u003e thus creating two classes of nodes, is a desirable\n\u003e feature.\n\n\nYes so to be clear, the HA signaling is not on the node level but on the\nchannel level. So each node can decide per channel whether they want to\npotentially attract additional traffic at the cost of severe penalties (or\navoidance if you want to use a different wording) if the channel can't be\nused. They can still maintain a set of less reliable channels along side.\n\n\n\u003e Communicating up-front that I intend to be reliable does\n\u003e nothing, and penalizing after the fact isn't worth much due to the\n\u003e repeat interactions issue.\n\n\nI think it is currently quite common for pathfinders to try another channel\nof the same node for the payment at hand. Or re-attempt the same channel\nfor a future payment to the same destination. I understand the repeat\ninteractions issue, but not sure about the extent to which it applies to\nlightning in practice. A think a common pattern for payments in general is\nto pay to the same destinations repeatedly, for example for a daily coffee.\n\n\n\u003e It'd be even worse if now we had to rely on a\n\u003e third party to aggregate and track the reliability, in order to get\n\u003e enough repeat interactions to build a good model of their liquidity,\n\u003e since we're now back in the hearsay world, and the third party can feed\n\u003e us wrong information to maximize their profits.\n\u003e\n\nYes, using 3rd party info seems difficult. As mentioned in my reply to\nMatt, the idea of HA signaling is to make local reliability tracking more\nefficient so that it becomes less likely that senders need to rely on\nexternal aggregators for their view on the network.\n\nJoost\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230214/a7f355e6/attachment-0001.html\u003e",
"sig": "3b25b33d5edbed84cd5481c661c4e700b669077c4b244c6e301885baf62cab10efaf8520ac67c22f7f34d91956a6ee42a34b6039d7e8448c1defe8a5e91798d5"
}