📅 Original date posted:2023-02-17
📝 Original message:
As long as protocol development and design is done neutrally, I'm all fine!
Le ven. 17 févr. 2023 à 10:48, Joost Jager <joost.jager at gmail.com> a écrit :
> 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
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230217/36b81f39/attachment-0001.html>;
Antoine Riard [ARCHIVE] /
npub1vj…4x8dd
2023-06-09 13:08:07
in reply to nevent1q…47t4
Author Public Key
npub1vjzmc45k8dgujppapp2ue20h3l9apnsntgv4c0ukncvv549q64gsz4x8ddPublished at
2023-06-09 13:08:07Event JSON
{
"id": "d20ac0c4aefaee863d522440c267608e8d9e2ab173a8bd632d539053fe6c74f9",
"pubkey": "6485bc56963b51c9043d0855cca9f78fcbd0ce135a195c3f969e18ca54a0d551",
"created_at": 1686316087,
"kind": 1,
"tags": [
[
"e",
"fc8a894a4e8d57d6b3b2f8ffd93a7c6696f3dc731595d0f0386959afdd2ef342",
"",
"root"
],
[
"e",
"c6dfb34e7e97e314b526e72adb68aab040e74617f2f72b4434cb390dd8d7f872",
"",
"reply"
],
[
"p",
"ec3fb08b335b94aace30d13181f2ad0280df9bc34f1a99832c4e2da8fb125eb3"
]
],
"content": "📅 Original date posted:2023-02-17\n📝 Original message:\nAs long as protocol development and design is done neutrally, I'm all fine!\n\n\nLe ven. 17 févr. 2023 à 10:48, Joost Jager \u003cjoost.jager at gmail.com\u003e a écrit :\n\n\u003e Right, that was my above point about fetching scoring data - there's three\n\u003e\u003e relevant \"buckets\" of\n\u003e\u003e nodes, I think - (a) large nodes sending lots of payments, like the\n\u003e\u003e above, (b) \"client nodes\" that\n\u003e\u003e just connect to an LSP or two, (c) nodes that route some but don't send a\n\u003e\u003e lot of payments (but do\n\u003e\u003e send *some* payments), and may have lots or not very many channels.\n\u003e\u003e\n\u003e\u003e (a) I think we're getting there, and we don't need to add anything extra\n\u003e\u003e for this use-case beyond\n\u003e\u003e the network maturing and improving our scoring algorithms.\n\u003e\u003e (b) I think is trivially solved by downloading the data from a node in\n\u003e\u003e category (a), presumably the\n\u003e\u003e LSP(s) in question (see other branch of this thread)\n\u003e\u003e (c) is trickier, but I think the same solution of just fetching\n\u003e\u003e semi-trusted data here more than\n\u003e\u003e sufficies. For most routing nodes that don't send a lot of payments we're\n\u003e\u003e talking about a very small\n\u003e\u003e amount of payments, so trusting a third-party for scoring data seems\n\u003e\u003e reasonable.\n\u003e\u003e\n\u003e\n\u003e I see that in your view all nodes will either be large nodes themselves,\n\u003e or be downloading scoring data from large nodes. I'd argue that that is\n\u003e more of a move towards centralisation than the `ha` flag is. The flag at\n\u003e least allows small nodes to build up their view of the network in an\n\u003e efficient and independently manner.\n\u003e\n\u003e Joost\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230217/36b81f39/attachment-0001.html\u003e",
"sig": "d47341500992c7dcbeb94c0633aec0507cd97c0db73ca86f3cf3ee10a2201acad0e67bc1a034b1324b68794e81442005220a6afc12225eb384a84d49911e7aea"
}