Creating your first Lightning node

Opening your first Lightning channel

Set up Your First Lightning Node

Opening your first Lightning channel

How to choose a good Lightning peer?
How do I find a peer?
Open your first channel via LND

If you've made it this far, you already know that a Lightning node without a channel is a bit like an empty wallet: it exists, but it's useless. To be able to send or receive payments, your node must be connected to at least one other node in the Lightning network via a channel. In the future, we strongly recommend opening several channels, for reasons of resilience and routing efficiency. In the following chapters, we'll also look at how to manage your liquid assets, optimize your channel topology and use more advanced tools than the basic LND interface on Umbrel.

But in this introductory chapter, the aim is simply to understand how to choose a good Lightning peer, where to find the information you need to select your peers, and finally how to open your first channel via the basic LND interface.

How to choose a good Lightning peer?

When you open a channel, you need to choose a peer: another Lightning node to which your node will be directly connected to, via a channel. This choice of peer is important, as it will have a direct impact on:

the ease for your payments to find their way;
the reliability of your channels over time;
your routing costs.

There's no such thing as a perfect match for everyone, but there are a number of reliable criteria for identifying good candidates.

1. Node connectivity

A good peer is a node that is well connected to the Lightning network. This means not only having a large number of channels (although this can be an indicator), but above all being connected to other reliable nodes and occupying a sufficiently central position in the network graph.

A well-connected node increases your chances of finding an efficient route to most payment destinations. It also reduces the number of intermediary nodes needed, which keeps costs down.

Conversely, opening your first channel to an isolated or weakly connected node may restrict your possibilities: you'll be able to pay this peer, but it will be much harder to pay the rest of the network.

2. Capitalization and channel capacity

A good peer is also a sufficiently capitalized node. This is shown by its total channel capacity (the sum of sats committed to all its channels) and its average channel capacity (it's often better to have just a few well-capitalized channels than many small ones).

A node with ridiculous capacity, or whose channels are all tiny, will not be able to route payments with large amounts, resulting in routing failures for you.

3. Expense policies

Each node sets its own routing fees (base fee and fee rate). A good peer will not charge exorbitant fees for strategic channels. For a first channel, it's best to choose a node with rather moderate fees, so as not to handicap your own payments.

Remember that your own routing fees also influence how others perceive you as a peer: a node that constantly changes its fees or imposes absurd costs is rarely appreciated.

4. Stability and seniority

Peer stability is a very important criterion. A good node has a high uptime (it's very rarely offline), it keeps its channels open for a long time and it doesn't constantly open/close channels for no reason.

Old and still active channels are a good signal: they suggest that the relationship is profitable for the peer, that the node knows how to manage its capital and that it doesn't close at any time, so you don't have to keep paying onchain fees for closing and reopening.

Conversely, a peer who is often offline, or who quickly closes channels, can be a source of problems for you, and of additional costs for opening new channels.

Even with these criteria, you won't make a perfect choice the first time. That's normal: the real quality of a peer is revealed by its use. So it's important to:

monitor channel activity (routed volumes, availability, etc.);
close channels that serve no purpose or whose peers are too often offline;
reallocate your capital to better peers over time.

The idea is not to open and close channels every day (which would be expensive in onchain costs), but to gradually evolve your topology to converge on a set of reliable, well-connected peers compatible with your needs.

How do I find a peer?

To apply these criteria, you'll need tools that provide visibility of the Lightning network. There are several explorers and services available to do this. Among the best-known Lightning explorers are 1ML and Amboss.

AmbossExplore and analyze Lightning Network

1MLLearn how to use the 1ML explorer to understand and analyze Bitcoin's Lightning network.

Here, however, I suggest you use the Lightning Terminal tool from Lightning Labs, which provides a ranking (admittedly based on partly subjective criteria) of the Lightning nodes deemed most relevant for opening a channel.

The problem with the very large Lightning nodes at the top of this ranking is that most don't accept channel openings below very high amounts. Many also apply strict peer management policies, which can lead to your channel being closed. On the other hand, these nodes generally have no need for inbound liquidity, given their number of connections.

I'd therefore advise you to work your way down the ranking to find a node that's well connected, reliable and sufficiently central in the network graph, without being excessively large. For example, here I've identified the Lightning node on stacker.news, which is very well connected, has high capacity and occupies a central position in the network graph.

Another interesting approach is to open a channel to a node in need of inbound liquidity, such as a merchant you know, an association or a community. This strategy has three advantages:

Since the chosen entity needs inbound liquidity, it will logically have less incentive to close your channel for no reason;
Its economic activity increases the chances of routing on this channel, and therefore of collecting some fees;
You're doing the ecosystem a favor and making a valuable contribution to other bitcoiners.

Once you've identified a relevant node, you can retrieve its Node ID. This is simply a concatenation of the node's public key, a @ separator, its IP or Tor address, and the port used. This ID is easily accessible from the node's profile on any Lightning explorer.

Open your first channel via LND

Now that we've identified the node with which to open our first channel, we need sats to lock into it. To do this, you need to feed the Bitcoin onchain wallet associated with your LND.

From the main LND interface, locate your Bitcoin Wallet, then click on the Deposit button. An onchain receiving address is then generated: send sats to it. The amount you need to transfer depends on the capacity you wish to allocate to your first channel, but bear in mind that you need to send slightly more than the targeted capacity. For example, if you want to open a 500,000 sats channel, don't send exactly 500,000 sats, but a higher amount.

Once the transaction has been broadcast, it appears in the interface. Wait for confirmation before opening the channel. You'll see a green arrow next to it when it's confirmed.

Scroll down to the main interface, then click on + OPEN CHANNEL.

Enter the Node ID of the node you wish to open a channel with, indicate the amount you wish to lock in, and then adjust the opening transaction fee according to the state of the onchain fee market. Of course, make sure you have sufficient funds in your LND onchain wallet beforehand.

Once all the parameters have been set, click on the OPEN CHANNEL button.

Wait for the opening transaction to be confirmed onchain. Your first channel is now officially operational: congratulations!

You can see that, for the moment, 100% of the channel's liquidity is on my side: that's normal, since I'm the one who opened the channel. As payments and routing evolve, this distribution will change, but the total capacity of the channel will always remain the same.

Now that you have a channel, you can make your first Lightning payments, provided the chosen node is properly connected to the network. Of course, in later chapters we'll look at how to set up a more convenient method of paying Lightning invoices from your mobile. But for now, let's try making a first payment directly from LND to Umbrel.

To do this, in the Lightning Wallet section, click on the SEND button, then paste the invoice to be set.

The invoice amount is displayed. Confirm payment by clicking on the SEND button.

If a valid route is found, your first Lightning payment should be successful.

If we then look at the distribution of liquidity in the channel, we see that my peer now has 5,002 sats on his side. This corresponds to the 5,000 sats of the payment I just made, which he routed to the recipient's node. The additional 2 sats represent the routing fees I paid, since the recipient received exactly 5,000 sats.

To improve the reliability of our payments, it will obviously be necessary to open up other channels. Depending on our objectives, we'll also need to find a way of making inbound liquidity available so that we can receive payments on Lightning. This will be the subject of the next section.

Quiz

lnp2022.4

1/5

From your node's point of view, what is the initial distribution of liquidity after it opens a channel?