Bitcoin Forum

In Bitcoin Core, there is a DNS seeds feature which makes outgoing connections from your node to a list of vouched bitcoin nodes.

But as far as I know, in C-Lightning, there is no such feature and you are completely isolated from the network at startup.

Does c-lightning not have a discovery feature where you can query peers for other peers? I have Tor enabled.

According to BOLT 7 (https://github.com/lightning/bolts/blob/master/07-routing-gossip.md), Lightning doesn't rely on third parties to disseminate the peer list. So, it either contains IP addresses of several nodes, which doesn't seem to be the case, or you don't know any node on startup, but get the IP addresses the moment it connects to one node. (That'll then send their peer list etc.)

Another issue I've noticed is that the list of IP addresses in the contrib/bootstrap-nodes.sh file are mostly offline. Out of the 10 nodes, only 2 of them connect successfully. It is difficult to find other people's nodes on internet pages.

Here are some nodes to start with: https://bitcointalk.org/index.php?topic=5266907.msg54940969#msg54940969

It might be a good idear to add your node to the list to, that way others can open channels to you aswell (if they want to)

Doesn't the same apply on Bitcoin Core's seeds if most go offline? Wouldn't you start searching for nodes on the internet? Not that they are offline, though.

Yeah by the thing is though that that Core devs would notice that and discuss the issue on Github and the mailing lists and then promote a node or two to the DNS seeds.

But the bootstrap-nodes script looks pretty much abandoned.

Also, on L1 there are websites such as addrnodes (or whatever that node explorer site was called) that shows you all the online Bitcoin nodes in a particular region, but as far as I know, LN just has a bunch of block explorers with Lightning addresses on them, but that doesn't guarantee any of them are online at the moment, and so adding peers on L2 is more of a trial-and-error process.

As far as I know all lightning implementations have DNS bootstrap. It is specified in BOLT 10 (https://github.com/lightning/bolts/blob/master/10-dns-bootstrap.md).

Looking at C-Lightning source code, there are references to DNS usage. There is also config flag disable-dns. Look it up yourself here (https://github.com/ElementsProject/lightning/blob/master/connectd/connectd.c#L1672).

I think the question was answered well already, but I want to make it clear that in LN, peer discovery (getting IP addresses of other nodes) and 'connections' are less tied together than for the underlying Bitcoin node network.
While a full node discovers peers and subsequently also automatically connects to them, a Lightning node doesn't. The reason is that a connection (channel) in Lightning requires you to commit funds so you're more 'locked' to that peer than in the Bitcoin network. A Bitcoin node can connect to any random peers because if they prove unreliable / as soon as they go offline, they just create a new connection to another peer.
However, opening and closing LN channels automatically as peers go offline and online, would quickly get expensive.

So I think it is easy to understand that LN node operators prefer to choose themselves with whom they commit to a Lightning channel and if they don't know anyone, it's also really easy to find IDs of large hubs that allow you to easily reach most other nodes in the network. It is less desired for decentralization though, so different users want different channels.

Automatically getting a list of node IPs does happen though; as was explained before. This allows me to create a channel with someone by just entering their node ID instead of having to specify the IP and port as well.
But automatically connecting (creating channels) doesn't make sense - I hope it is easy to follow why, now. :)

Actually, they do. Connecting to someone is not the same as opening a channel to them. You can use lightning-cli connect (https://lightning.readthedocs.io/lightning-connect.7.html) with no consequences ;) Usually, 1-2 random nodes are connected to me at a time. Such connections are used only to exchange gossip messages.


Autopilot is a thing, but I have never seen one that closes channels immediately once the other peer goes offline ;D

That's true! I didn't want to overcomplicate. But then technically there's 3 types of 'connecting to peers by default' to consider in LN.
1) Getting a list of IPs through gossip protocol
2) Creating connections (free, mainly for gossip communication)
3) Creating channels (lock up funds)

Do you have practical experience with autopilot mode / plugins? Depending on implementation, it might drive centralization by going for the 'safe bet' (mostly going for channels towards large, well connected hubs).

Is that a network trend, or just an anomaly with your node that you're only connected to 1-2 peers? If it's a normal thing then it's hard to see how LN anodes can protect themselves from "influence attacks" (or whatever they're called) where a few nodes with a completely different and wrong blockchain connect as the only peers to another node, tainting its knowledge of what is the correct tip. Since Lightning nodes are just thin wrappers around bitcoin nodes, it would be easier to carry out this kind of "mind control" of an unsuspecting LN node.

...and DNS bootstrap.


I have only used LND's autopilot for a short moment back in 2019 and it always prioritized large nodes (especially ACINQ which always causes problems for me). I glanced over their GitHub and it looks like they have made quite a few improvements. I prefer to open my channels manually now.


I am connected to all of my channel peers (10 connections) and occasionally some random Lightning nodes connect to me (or vice-versa). My Bitcoin node has far many more connections.


Here's a paper (https://arxiv.org/abs/2006.01418) describing such an attack. You should be fine if you run a watchtower at a different location. Most Lightning Network nodes are connected to full nodes which are less susceptible to this attack.

It's actually not even that easy to run a Lightning node without having Bitcoin Core running. Maybe it got easier, but last time I tried it was pretty bad. ;D Ended up just getting a disk of the required size for that node.
It's definitely essential for an LN node to know the status of the blockchain with full confidence. So either a full node runs on the same machine or the task is delegated to another machine which you trust (best control) and takes over the 'controlling' task - a watchtower, as Rath_ already said.

That's good to know! It was kind of what I was expecting, since connecting to large hubs is the 'safe bet' strategy without too many what I call 'false positives' (opened channels that turn out useless).
Would be interesting to try if with all the code changes it got any better; I'm sure the developers of such plugins should be able to test their implementation through simulations (or better, the model based on which they write the logic code).