Peer candidate improvements

[btweenthebars]

I've noticed the peer candidate proposal is hit and miss. What serious people these days are doing is using the "lnrouter.app" website to see if a node has a lot of excess outbound, the routing score is above 75th, see if peers & fee is compatible with their nodes, before they open.

I'm not sure if clboss is doing the probe get the outbound/inbound ratio of nodes, because my clboss used to propose nodes like IBEX_m0 and bcyber which forwarded nothing, and when I checked the lnrouter.app site, they had little outbound comparing to inbound.

[ZmnSCPxj]

Difficult to outright trust lnrouter.app as it potentially becomes a kingmaker --- they could lie about which nodes are actually good. What are the algorithms it uses, is there a writeup? It looks like you are proposing that CLBOSS should probe?

[btweenthebars]

https://blog.lnrouter.app/lightning-payment-speed-2022

[ZmnSCPxj]

It seems a bit light on details, but let me see what I can glean. So it looks like the lnrouter.app service does extensive probing on the network, then ranks nodes based on response time and probed channel balances. Some issues:

• The lnrouter.app model is planned to be a paid service. You can get node ranking for >50th percentile info for free now but this may be temporary and used to entice people to be reliant on this service, then be made into a paid service later.
• As mentioned before, lnrouter.app could lie. It might not lie now but it may be bribed or coerced into lying later once people have started to rely on this service. It is effectively an oracle whose data we have to trust, as the information it provides is expensive to acquire.
• I cannot quickly find information on how to fetch the data programmatically; there is no public API that is not intended for human consumption. Doing a wget https://lnrouter.app/node-ranking returns an HTML document with a lot of references to other JavaScript source files. The referred JavaScript source files are minified, which is bad enough, but it uses numeric keys for object methods, which means either the code has been obfuscated, or was generated from a different language that compiles down to JavaScript, which makes it even harder to hack the current programmatic API.
• Even if I decide to try reverse-engineering the JavaScript code to figure out some kind of programmatic API, https://lnrouter.app/terms-and-conditions shows: "As a user of the Site, you agree not to: 1. Systematically retrieve data or other content from the Site to create or compile, directly or indirectly, a collection, compilation, database, or directory without written permission from us", and reverse-engineering the JavaScript code to figure out the programmatic API might be construed as this. Programming CLBOSS to do it may require that every CLBOSS user get written permission from the site owners individually, as well.
• If everyone channels to the highest-ranked node in the list, then that node becomes king. Obviously CLBOSS can use its randomized tools to spread out the love among the higher-ranked nodes instead of just the highest-ranked node. Hopefully getting overloaded with new channels means that the highest-ranked nodes eventually suffer response time issues and drop in ranking so others can take its place as king, but that seems a poor feedback mechanism.

While the logic makes sense, it seems to me that the information used is expensive to acquire: it has to actively probe, and to get information on direct-channel response time it has to be actually channeled to those nodes. Doable but not in a "do not trust, verify" way: there is no way to get the same information elsewhere to validate it.

CLBOSS could do this kind of data gathering itself, on each node, and in fact does probing on each of its direct peers. But that requires that CLBOSS be connected to the network already; if you are proposing to use this data for initial channel connections then that is a catch-22.