📅 Original date posted:2023-02-17
📝 Original message:
>
> Right, that was my above point about fetching scoring data - there's three
> relevant "buckets" of
> nodes, I think - (a) large nodes sending lots of payments, like the above,
> (b) "client nodes" that
> just connect to an LSP or two, (c) nodes that route some but don't send a
> lot of payments (but do
> send *some* payments), and may have lots or not very many channels.
>
> (a) I think we're getting there, and we don't need to add anything extra
> for this use-case beyond
> the network maturing and improving our scoring algorithms.
> (b) I think is trivially solved by downloading the data from a node in
> category (a), presumably the
> LSP(s) in question (see other branch of this thread)
> (c) is trickier, but I think the same solution of just fetching
> semi-trusted data here more than
> sufficies. For most routing nodes that don't send a lot of payments we're
> talking about a very small
> amount of payments, so trusting a third-party for scoring data seems
> reasonable.
>
I see that in your view all nodes will either be large nodes themselves, or
be downloading scoring data from large nodes. I'd argue that that is more
of a move towards centralisation than the `ha` flag is. The flag at least
allows small nodes to build up their view of the network in an efficient
and independently manner.
Joost
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230217/d0b4ac41/attachment.html>;
Joost Jager [ARCHIVE] /
npub1as…wfqmx
2023-06-09 13:08:07
in reply to nevent1q…gf7e
Author Public Key
npub1aslmpzentw224n3s6yccru4dq2qdlx7rfudfnqevfck637cjt6esswfqmxPublished at
2023-06-09 13:08:07Event JSON
{
"id": "c6dfb34e7e97e314b526e72adb68aab040e74617f2f72b4434cb390dd8d7f872",
"pubkey": "ec3fb08b335b94aace30d13181f2ad0280df9bc34f1a99832c4e2da8fb125eb3",
"created_at": 1686316087,
"kind": 1,
"tags": [
[
"e",
"fc8a894a4e8d57d6b3b2f8ffd93a7c6696f3dc731595d0f0386959afdd2ef342",
"",
"root"
],
[
"e",
"7e1d5c0de58adc9a5e4b3c6c52b8af0614a7db50400dee517faddf679b0e9ff6",
"",
"reply"
],
[
"p",
"6485bc56963b51c9043d0855cca9f78fcbd0ce135a195c3f969e18ca54a0d551"
]
],
"content": "📅 Original date posted:2023-02-17\n📝 Original message:\n\u003e\n\u003e Right, that was my above point about fetching scoring data - there's three\n\u003e relevant \"buckets\" of\n\u003e nodes, I think - (a) large nodes sending lots of payments, like the above,\n\u003e (b) \"client nodes\" that\n\u003e just connect to an LSP or two, (c) nodes that route some but don't send a\n\u003e lot of payments (but do\n\u003e send *some* payments), and may have lots or not very many channels.\n\u003e\n\u003e (a) I think we're getting there, and we don't need to add anything extra\n\u003e for this use-case beyond\n\u003e the network maturing and improving our scoring algorithms.\n\u003e (b) I think is trivially solved by downloading the data from a node in\n\u003e category (a), presumably the\n\u003e LSP(s) in question (see other branch of this thread)\n\u003e (c) is trickier, but I think the same solution of just fetching\n\u003e semi-trusted data here more than\n\u003e sufficies. For most routing nodes that don't send a lot of payments we're\n\u003e talking about a very small\n\u003e amount of payments, so trusting a third-party for scoring data seems\n\u003e reasonable.\n\u003e\n\nI see that in your view all nodes will either be large nodes themselves, or\nbe downloading scoring data from large nodes. I'd argue that that is more\nof a move towards centralisation than the `ha` flag is. The flag at least\nallows small nodes to build up their view of the network in an efficient\nand independently manner.\n\nJoost\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230217/d0b4ac41/attachment.html\u003e",
"sig": "ee4c9cee6ed837d9cb99ff49e77c9c41e43fdc2bb4bd52145d3fc694641a8002dbd3a3df9103d7965bd20f1bb59d8818e04076b46d734b1a5db2f2e2cc0e5232"
}