In this final chapter marking the end of the LNP201 training, I propose to revisit the important concepts we have covered together.
The goal of this training was to provide you with a comprehensive and technical understanding of the Lightning Network. We discovered how the Lightning Network relies on the Bitcoin blockchain to perform off-chain transactions, while retaining the fundamental characteristics of Bitcoin, notably the absence of the need to trust other nodes.
Payment Channels
In the initial chapters, we explored how two parties can conduct transactions outside of the Bitcoin blockchain by opening a payment channel. Here are the steps covered:
Channel Opening: The creation of the channel is done through a Bitcoin transaction that locks the funds in a 2/2 multisignature address. This deposit represents the Lightning channel on the blockchain.
2. Transactions in the Channel: In this channel, it is possible to carry out numerous transactions without publishing them on the blockchain. Each Lightning transaction creates a new state of the channel reflected in a commitment transaction.
Securing and Closing: Participants commit to the new state of the channel by exchanging revocation keys to secure the funds and prevent any cheating. Both parties can close the channel cooperatively by making a new transaction on the Bitcoin blockchain, or as a last resort, through a forced closure. This latter option, although less efficient due to its length and sometimes poor evaluation in terms of fees, still allows for the recovery of funds. In the event of cheating, the victim can penalize the cheater by recovering all the funds from the channel on the blockchain.
The Network of Channels
After studying isolated channels, we extended our analysis to the network of channels:
Routing: When two parties are not directly connected by a channel, the network allows for routing through intermediary nodes. Payments then transit from one node to another.
HTLCs: Payments transiting through intermediary nodes are secured by "Hash Time-Locked Contracts" (HTLC), which allow for the funds to be locked until the payment is completed end-to-end.
Onion Routing: To ensure the confidentiality of the payment, onion routing masks the final destination to intermediary nodes. The sending node must therefore calculate the entire route, but in the absence of complete information on the liquidity of the channels, it proceeds through successive trials to route the payment.
Liquidity Management
We have observed that liquidity management poses a challenge on Lightning, necessitating the smooth flow of payments. Sending payments is relatively simple: it just requires opening a channel. However, receiving payments requires having liquidity on the opposite side of one's channels. Here are some strategies discussed:
Attracting Channels: By encouraging other nodes to open channels towards oneself, a user obtains incoming liquidity.
Moving Liquidity: By sending payments to other channels, liquidity moves to the opposite side.
Using Services like Loop and Pool: These services allow for rebalancing or buying channels with liquidity on the opposite side.
Collaborative Openings: There are also platforms available for connecting to perform triangular openings and to have incoming liquidity.
Now that you have understood the theoretical functioning of the Lightning Network, you can move on to practice and set up your first Lightning node in order to gain greater autonomy in your usage. To do so, follow the LNP 202 course: