pull down to refresh

I run the node c-otto.de which currently has more than 300 peers. As such, I need to automate certain things. Some of the trickier questions:
  • Which channels should I close?
  • Which peers are good, which are bad, and how does peer X compare to peer Y?
As part of lnd-manageJ (https://github.com/C-Otto/lnd-manageJ) I implemented a rating system, which assigns some number to each peer. For example, LOOP might get a high score because I earn a lot forwarding transactions to said node. Some good plebnet node might get a lower number, but still a lot more than what I'd assign to a bad node.
Currently, I consider the following values for some peer X:
  • sats earned by routing out through peer X
  • sats earned by routing out through some other peer, where the transaction came in from peer X
  • sats provided as part of rebalance transactions (to have more liquidity in a channel with some other peer)
  • sats received as part of rebalance transactions (to have more inbound liquidity from some other peer)
  • potential earnings (based on the current local liquidity and fee rate)
These numbers are added (with different weights), and then the sum is divided by the number of days used for the analysis (so that I get some number that tells me "... per day").
This number is then divided by the average amount of satoshis I have on my side (normalized to million satoshis), so that I divide the number by 3 if I have 3 million sat on my side (on average), or multiply by 2 if I have 1/2 million satoshis (= 500,000sat) on my side (on average). This way I can compare peers based on how much of my capital they use (block?), where higher capital requirements lower the resulting rating.
Note that other important aspects like uptime or fee-configuration are handled irrespective of the rating.
What do you think about this? What makes a good peer good, and how can I assign a number to this?
I think you have most of it covered. All those factors are important. The most valuable ones are the ones that routes in both directions without our active participation (rebalance), and I guess this is covered by combining your first and second bullet points.
For me, as a small timer, a channel I would consider bad is one where the risk of force closing is high, as the costs of force closes is considerably large for me. Therefore, if I can catch this potential and pre-emptively perform a cooperative close it will be really helpful.
Maybe some factors that can lead to a higher chance of this include:
  1. High frequency of stuck HTLCs
  2. Significant decrease in channel count and capacity in a short time.
reply