rich1.0npub1aslmpzentw224n3s6yccru4dq2qdlx7rfudfnqevfck637cjt6esswfqmxhttps://nostr.ae/npub1aslmpzentw224n3s6yccru4dq2qdlx7rfudfnqevfck637cjt6esswfqmxnjumphttps://nostr.ae📅 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>