What criteria should be taken into account when selecting nodes to create new lightning channels with?
Alex Bosworth recently pointed out:
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?
lightning-network lightning-routing ln-opening-channels ln-topology
add a comment |
Alex Bosworth recently pointed out:
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?
lightning-network lightning-routing ln-opening-channels ln-topology
add a comment |
Alex Bosworth recently pointed out:
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?
lightning-network lightning-routing ln-opening-channels ln-topology
Alex Bosworth recently pointed out:
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?
lightning-network lightning-routing ln-opening-channels ln-topology
lightning-network lightning-routing ln-opening-channels ln-topology
asked Jan 4 at 9:45
Murch♦Murch
34.9k27114326
34.9k27114326
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
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. This is one of the reasons why I have created a standalone autopilot and provided an integration for c-lightning.
There are several kind of information we can look at (my autopilot currently only looks at the first ones):
- 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.
- 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. 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.
add a comment |
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
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "308"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fbitcoin.stackexchange.com%2fquestions%2f83362%2fwhat-criteria-should-be-taken-into-account-when-selecting-nodes-to-create-new-li%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
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. This is one of the reasons why I have created a standalone autopilot and provided an integration for c-lightning.
There are several kind of information we can look at (my autopilot currently only looks at the first ones):
- 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.
- 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. 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.
add a comment |
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. This is one of the reasons why I have created a standalone autopilot and provided an integration for c-lightning.
There are several kind of information we can look at (my autopilot currently only looks at the first ones):
- 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.
- 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. 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.
add a comment |
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. This is one of the reasons why I have created a standalone autopilot and provided an integration for c-lightning.
There are several kind of information we can look at (my autopilot currently only looks at the first ones):
- 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.
- 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. 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.
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. This is one of the reasons why I have created a standalone autopilot and provided an integration for c-lightning.
There are several kind of information we can look at (my autopilot currently only looks at the first ones):
- 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.
- 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. 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.
answered Jan 4 at 11:39
Rene PickhardtRene Pickhardt
85613
85613
add a comment |
add a comment |
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
add a comment |
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
add a comment |
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
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
edited Jan 5 at 10:18
chytrik
6,4252625
6,4252625
answered Jan 4 at 11:23
Carlos RoldanCarlos Roldan
111
111
add a comment |
add a comment |
Thanks for contributing an answer to Bitcoin Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fbitcoin.stackexchange.com%2fquestions%2f83362%2fwhat-criteria-should-be-taken-into-account-when-selecting-nodes-to-create-new-li%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown