<p>Here there are some properties:</p>

<pre><code>Node reliability: On-line connected 24/7.
History: when the node came online for first time.
Routing: How many channels has the node.
Capacity: How much capacity can the handle through channels
</code></pre>

CC BY-SA 4.0
2019-01-04T11:23:08.700Z
2019-01-05T10:18:33.497Z
2019-01-05T10:18:33.497Z
Carlos Roldan
<p>I agree with Alex Bosworth and I have pointed this out about one year ago when I have filed an <a href="https://github.com/lightningnetwork/lnd/issues/677" rel="noreferrer">issue about the strategy used by the LND autopilot which basically looks for nodes with a high channel count</a>. This is one of the reasons why I have <a href="https://github.com/ElementsProject/lightning/pull/1888" rel="noreferrer">created a standalone autopilot and provided an integration for c-lightning</a>.</p>

<p>There are several kind of information we can look at (my autopilot currently only looks at the first ones): </p>

<ol>
<li>Network topology: 

<ul>
<li>How can I increase my centrality (e.g. by connecting to central nodes)</li>
<li>How can I increase my probability to have well funded routes by connecting to points where a lot of liquidity is floating around</li>
<li>Improve the network topology by increasing the amount of triangles</li>
<li>Geography: It is likely that you pay to services where you live and therefor you might want to connect to nodes that have a similar geoip as yours.</li>
</ul></li>
<li>Node Provenance / properties: 

<ul>
<li>age of Node (seen by oldest channels)</li>
<li>age of channels (seen by the blockheight of funding transactions)</li>
<li>uptime of the node (can be tracked via the gossip messages and the gossip store)</li>
<li>Routing fees of the node</li>
<li>Reliability of the node to forward payments (can be tracked by doing fake 1 satoshi payments to yourself over different routes) </li>
</ul></li>
</ol>

<p>most of the stuff that I mentioned here has been taken from my <a href="https://www.rene-pickhardt.de/improve-the-autopilot-of-bitcoins-lightning-network-summary-of-the-bar-camp-session-at-the-2nd-lightninghackday-in-berlin/" rel="noreferrer">blog article about autopilots</a>. In general I hope that better autopilots will emerge because I think this problem will be hard to decide by humans without investing a lot of time. </p>

<p>Finally another strategy could be to create routing tables in a similar way as the border gateway protocol does on top of IP. In that case nodes would share partial information about the channel balance so that we would have a better overview of where liquidity is missing. </p>

CC BY-SA 4.0
2019-01-04T11:39:46.833Z
2019-01-04T11:39:46.833Z
Rene Pickhardt
<p>Alex Bosworth recently <a href="https://twitter.com/alexbosworth/status/1080876219728457728" rel="noreferrer">pointed out</a>:</p>

<blockquote>
  <p>I see people connect to a "well connected" node on LN and by that they mean they connect to a node with lots of channels. <strong>The number of channels is actually a contra-indicator of a node's ability to route. Good routers curate and balance.</strong> Bad routers spam the open channel button. [Emphasis added]</p>
</blockquote>

<p>What criteria should be kept in mind when evaluating nodes while opening new channels on the lightning network?</p>

<lightning-network><lightning-routing><ln-opening-channels><ln-topology><lightning-autopilot>
What criteria should be taken into account when selecting nodes to create new lightning channels with?
Murch
# What criteria should be taken into account when selecting nodes to create new lightning channels with?

(Asked by: username_0 on 2019-01-04)

Alex Bosworth recently [pointed out](https://twitter.com/alexbosworth/status/1080876219728457728):

> I see people connect to a "well connected" node on LN and by that they mean they connect to a node with lots of channels. **The number of channels is actually a contra-indicator of a node's ability to route. Good routers curate and balance.** Bad routers spam the open channel button. [Emphasis added]

What criteria should be kept in mind when evaluating nodes while opening new channels on the lightning network?

**Tags:** lightning-network, lightning-routing, ln-opening-channels, ln-topology, lightning-autopilot


---

## 2 answers

### Answer by username_2 on 2019-01-04. Score: 11 | Accepted answer

I agree with Alex Bosworth and I have pointed this out about one year ago when I have filed an [issue about the strategy used by the LND autopilot which basically looks for nodes with a high channel count](https://github.com/lightningnetwork/lnd/issues/677). This is one of the reasons why I have [created a standalone autopilot and provided an integration for c-lightning](https://github.com/ElementsProject/lightning/pull/1888).

There are several kind of information we can look at (my autopilot currently only looks at the first ones):

1. Network topology:
   * How can I increase my centrality (e.g. by connecting to central nodes)
   * How can I increase my probability to have well funded routes by connecting to points where a lot of liquidity is floating around
   * Improve the network topology by increasing the amount of triangles
   * Geography: It is likely that you pay to services where you live and therefor you might want to connect to nodes that have a similar geoip as yours.
2. Node Provenance / properties:
   * age of Node (seen by oldest channels)
   * age of channels (seen by the blockheight of funding transactions)
   * uptime of the node (can be tracked via the gossip messages and the gossip store)
   * Routing fees of the node
   * Reliability of the node to forward payments (can be tracked by doing fake 1 satoshi payments to yourself over different routes)

most of the stuff that I mentioned here has been taken from my [blog article about autopilots](https://www.username_2.de/improve-the-autopilot-of-bitcoins-lightning-network-summary-of-the-bar-camp-session-at-the-2nd-lightninghackday-in-berlin/). In general I hope that better autopilots will emerge because I think this problem will be hard to decide by humans without investing a lot of time.

Finally another strategy could be to create routing tables in a similar way as the border gateway protocol does on top of IP. In that case nodes would share partial information about the channel balance so that we would have a better overview of where liquidity is missing.


---

### Answer by username_1 on 2019-01-04. Score: 1

Here there are some properties:

```
Node reliability: On-line connected 24/7.
History: when the node came online for first time.
Routing: How many channels has the node.
Capacity: How much capacity can the handle through channels

```


---

