Introduction

Understanding what a Lightning node is

Set up Your First Lightning Node

Understanding what a Lightning node is

What's a Lightning node?
Node vs. Lightning Wallet: an important distinction
A reminder of how the Lightning Network works
The main Lightning node implementations

Before launching your own node, this chapter briefly reviews the basic theory behind Lightning Network. It is indeed important to understand the mechanisms involved, as this will enable you to identify risks and adopt good practices to limit them. I won't go into detail here, however, as this is not the main objective of this course. If you'd like to delve deeper into the subject, I highly recommend that you consult Fanis Michalakis's LNP 201 course, which is a reference in the field:

Lightning Network Theory

Intermediate

4.8(152)

Discover the Lightning Network from a technical perspective

4.8(152)

Lightning Network Theory

Discover the Lightning Network from a technical perspective

What's a Lightning node?

Let's go back to basics: before defining what a node is, we need to understand what Lightning Network is. It's a top-layer protocol, built on top of Bitcoin, designed to enable offchain BTC transactions that are fast (with near-instant finality) and generally inexpensive. "Offchain" means that transactions carried out on Lightning are not intended to appear on the main Bitcoin blockchain. Lightning is also a partial response to the increasing use of Bitcoin and to onchain congestion, which is raising concerns about the system's scalability.

To operate, Lightning relies on the opening of payment channels between participants, within which transactions can be carried out almost instantaneously, often with minimal fees, without the need to register them one by one on the Bitcoin blockchain. These channels can remain open for a very long time, requiring onchain transactions only when they are opened and closed.

A Lightning node is a participant in the Lightning network, opening channels and making payments with other nodes. In concrete terms, a Lightning node is a piece of software running on a computer and implementing the Lightning Network protocol. Examples include LND, Core Lightning or Eclair. The main role of this software is to:

connect to a Bitcoin node to obtain information from the main blockchain;
create and manage bidirectional payment channels with other nodes;
exchange messages with the entire Lightning network.

Node vs. Lightning Wallet: an important distinction

On Bitcoin (onchain), "wallet" refers to software that manages your private keys, calculates your balance from your UTXOs and builds your transactions. This wallet may be based on your own Bitcoin node or on someone else's, but today, the role of the node and that of the onchain wallet are clearly distinct.

On Lightning, it's more difficult to reuse this kind of vocabulary without creating confusion. The term "Lightning wallet" is rather vague, because in reality there is no such thing as a truly self-custodial Lightning wallet, unless it is based on a node. Only two situations are therefore possible:

To have a real Lightning node (i.e. non-custodial): the software you're using (e.g. a mobile app like Phoenix or a LND instance on Umbrel) is actually running a node, and you actually hold the keys to retrieve your bitcoins. In this case, your "Lightning wallet" is really just a user interface on top of a Lightning node, whether embedded or remote.
To use a custodial service: you use an application that shows you a balance in sats on Lightning, but in the background, the funds are on a provider's node (e.g. Wallet of Satoshi). You have neither the keys nor control of the channels. Your balance is merely an accounting entry in the company's database. It's comparable to leaving your bitcoins on an exchange platform, with all the associated risks. In this case, your "Lightning wallet" is merely an access to an account managed by an operator who, in turn, runs a real Lightning node.

So there's no in-between on Lightning: either you have a node (even an embedded one) so you're in self-custody, or you don't, so a company owns your sats. But as we'll see in the following chapters, these two uses can sometimes be hard to distinguish. For example, Phoenix is a mobile application that embeds a real Lightning node, but the user isn't necessarily aware of it, as the full complexity of its operation is almost entirely hidden.

A reminder of how the Lightning Network works

In this section, I'll give you a quick reminder of how Lightning works. Once again, if you'd like a more in-depth presentation of the theoretical concepts, I invite you to take a look at the dedicated LNP 201 course.

Payment channels: open, update and close

The heart of the Lightning network is based on bidirectional payment channels. A channel can be opened (i.e. created), updated as Lightning transactions take place, and then finally closed. From the onchain point of view, a channel is nothing more than a 2/2 multisignature output.

From Lightning's point of view, it is a payment channel with liquidity divided between the two participants.

Opening a channel:**

Two nodes decide to open a channel. One of them commits bitcoins in an onchain transaction called funding transaction. This transaction creates an output based on a 2-of-2 multisignature script, which means that spending these funds on Bitcoin requires the signature of both nodes in the channel. Before issuing this transaction, the party providing the funds asks the other to sign a withdrawal transaction, which is not issued onchain, but which enables it to recover its funds in the event of a problem.

Commitment transactions:**

The state of the channel (i.e. the distribution of sats between A and B) is represented by a commitment transaction, known to both nodes but not immediately broadcast on the blockchain. This transaction describes how to redistribute the channel funds onchain according to the payments made on Lightning.

With each Lightning payment, the two nodes sign a new state that replaces the previous one. The old state is revoked thanks to a revocation key mechanism: if one of the participants tries to broadcast an old state, the other can recover the full amount of the funds as a penalty.

The important idea here is that there is always a signed Bitcoin transaction, not broadcast onchain, kept by the nodes, and which enables the redistribution of each other's sats according to the payments made on Lightning Network.

Channel closure:**

A channel can be closed cleanly via a cooperative closure, when both parties agree on the final state of the channel, or unilaterally (a forced closure) if one of the participants ceases to cooperate or becomes unreachable. In all cases, closure takes the form of an onchain transaction that spends the 2/2 output and distributes the funds between the participants according to the last valid state of the channel.

Lightning thus functions as a secondary layer anchored on Bitcoin: only certain events (the opening and closing of channels) appear on the main blockchain. Intermediate payments remain offchain.

Before going any further, here are two essential concepts for understanding how to manage a Lightning channel:

Liquidity*: the quantity of sats available on one side of the channel;
The capacity: it is the total amount locked in the 2/2 multisig output, i.e. the sum of liquidity on both sides of the channel.

A network of channels and liquidity

A channel isn't just for payments between two nodes: it's part of a global network of interconnected channels. Your node can route payments for other users through its own channels, and you can send sats to a Lightning node with which you have no direct channel, as long as a valid path can be found between your two nodes.

Each node knows, via the gossip protocol, a map of this network: which channels exist, which nodes are connected by a bidirectional channel, and which capacities are published. To send a payment to a recipient without a direct channel, your node calculates a route consisting of several hops: your node → node X → node Y → recipient node. At each hop, the payment transits a channel that must have sufficient liquidity in the direction of payment.

The liquidity of a channel is therefore not symmetrical: one side may be heavily loaded, while the other is almost empty. Managing this liquidity, i.e. knowing where the sats are and in which direction they can flow, is one of the most important aspects of operating a Lightning node. We'll look at it in more detail in the practical chapters to come.

HTLC: transporting payment without being robbed

To enable payments to pass through intermediate nodes without the need for trust, Lightning uses smart contracts called HTLC (Hashed Time-Locked Contracts). In simple terms, a HTLC makes the transfer of funds conditional on the revelation of a secret, and incorporates a time constraint to protect the sender in the event of transaction failure. Each payment is therefore subject to the presentation of a pre-image (a secret whose hash corresponds to an agreed value). If the final recipient provides this pre-image, he or she can claim the funds, which in turn enables each intermediary node to recover its own funds.

I'll spare you the technical details of how HTLCs work, as they're not essential for the purposes of this course. You'll find an in-depth explanation in the LNP 201 theory course. Just remember that HTLCs enable atomic exchanges: either the transfer is completed and no one is harmed in the routing, or it fails and each participant recovers his or her initial funds. There is no in-between.

The main Lightning node implementations

As with Bitcoin, there are several implementations of the Lightning protocol. A number of independent teams are developing their own versions, all of which are interoperable since they adhere to the same specifications (the BOLTs). Here are the main implementations in use today.

LND (Lightning Network Daemon)

LND is a complete implementation of the Lightning protocol, written in Go and developed by Lightning Labs.

Core Lightning (CLN)

Core Lightning (formerly C-Lightning) is the implementation developed by Blockstream. It is written in C, with some components in Rust.

Eclair

Eclair is an implementation written in Scala and developed by the French company ACINQ. ACINQ operates one of the most important routing nodes in the Lightning network with Eclair, and uses this implementation as the software basis for its own products, such as the Phoenix application.

LDK (Lightning Development Kit)

LDK (Lightning Development Kit) is a Rust development kit, maintained by Spiral (Block, ex-Square). It's not a ready-to-use daemon like LND or CLN, but a library for developers wishing to integrate Lightning directly into their applications.

In this LNP202 course, we'll be concentrating mainly on LND: the implementation that is most commonly used in turnkey solutions for private customers, such as Umbrel.

So much for this brief reminder of how Lightning works. Once again, if there are any concepts you don't understand, or if you'd like to delve a little deeper before putting them into practice, Fanis Michalakis' course is the essential reference on the subject:

Lightning Network Theory

Intermediate

4.8(152)

Discover the Lightning Network from a technical perspective

4.8(152)

Lightning Network Theory

Discover the Lightning Network from a technical perspective

Quiz

lnp2021.2

1/5

What mechanism prevents the release of an old Lightning channel state?