A Gentle Introduction To The Lightning Network

Often seen as the path forward for Bitcoin’s scalability, this is a simple description of the Lightning Network.

*This article assumes the reader already has a basic understanding of the Bitcoin protocol, as well as how nodes, users and miners interact within it.

Bitcoin is extremely secure, but this initially came at a trade-off: It’s slow. On its base layer, there’s no getting around the immense computing power and 10-minute average block time — and that’s the point. Bitcoin’s maximum transactions per second (TPS) is about five, which immediately raises concerns about scalability that enable millions of users to take advantage of its use case: a permissionless, peer-to-peer currency.

Enter the Lightning Network. Lightning was proposed in a white paper by Joseph Poon and Thaddeus Dryja in 2016. At 59 pages, it’s a serious read, but it’s nothing short of genius. It overcomes this scalability problem without sacrificing security or trustlessness, and increases anonymity in the process.

There is often discussion regarding protocols built on Bitcoin, and whether or not its users are interacting with “real” bitcoin. This is a fair question in this context, as it’s not immediately obvious how Lightning users are interacting with “real” bitcoin while having near-instant transaction times and almost zero fees.

The Lightning Network itself consists of two things: nodes and the channels between them. These nodes must also serve as nodes for Bitcon’s base layer, as that’s how they open and close channels between nodes.

Bitcoin can only be added to the Lightning Network by creating a channel between two nodes. The bitcoin is placed in an unbroadcasted transaction which both nodes verify and sign. This channel can be funded by one or both of the nodes. This means that

1. This bitcoin cannot be used for anything else until that transaction is broadcast to the network.

2. Both nodes have the ability to “redeem” this transaction at any time in order to get back their initial channel funding amounts.

There is a lot of effort and nuance in operating a Lightning node. Node operators are incentivized, if nothing else, to establish many channels by the accrual of routing fees. Fees must be competitively priced, though, in order to have transactions routed through their node. It’s also suggested that operators have multiple channels to increase network connectivity and make channel rebalancing easier.

A natural side effect of Lightning Network operation is the pooling of funds in one channel or another. This restricts liquidity in certain neighborhoods and so necessitates the “rebalancing” of channels in order to have a more even liquidity gradient across the network. Maximum transaction size — at least used to be — limited by the smallest channel balance. This is, interestingly, being worked on by Rene Pickhardt and Stefan Richter. Operators are also encouraged to open large channels — usually at least one million satoshis — in order to allow for larger transactions through their channel(s). Operators are also incentivized to keep their channels open for as long as possible, as closing them requires a drop back down to the base layer, incurring potentially high transaction fees.

Channel operators are incentivized to cooperate with each other. The largest concern is a channel constituent closing the channel by themselves, broadcasting an incorrect transaction (i.e., channel state, which shows the channel balance per side at any given time) back to the base layer. But they aren’t able to access that bitcoin for a period of time. If, during that time, the other channel constituent can show a more recent channel state, the malicious channel constituent loses all of their bitcoin. This can also be enforced by Watchtower nodes.

Smoothly operating Lightning nodes and channels can be very time consuming. Thankfully, there are large communities devoted to education and getting everyone, including your grandma, into Lightning.

Lightning improvements are currently made by several organizations, including Lightning Labs, Blockstream and ACINQ. Despite being individual groups, they keep their products interoperable by utilizing agreed-upon development rules.

As Lightning is still very much a work in progress, security issues and vulnerabilities will inevitably arise. That being said, it has come a very long way in just a few years. At the time of writing, it has over 20,000 public nodes, 60,000 channels and 2,000 bitcoin in capacity.

As Lightning makes it unnecessary to confirm every transaction on the base layer blockchain, the possible upper bound of TPS steadily trends toward infinity. This also pushes transaction fees to near-zero.

Interacting with Lightning is not very different from interacting on the base layer. You can still use your own node, or someone else’s via a custodial or noncustodial wallet. Now, instead of trading addresses, we exchange invoices, which encode, among other things, where the bitcoin is going, and how much is going there. These transactions are sent via onion routing, which means no node between the sender and recipient knows who is sending and who is receiving. Lightning dramatically increases fungibility this way. With the enactment of Taproot, it will become difficult to even ascertain whether or not bitcoin is being transacted on the Lightning Network.

In order to remove bitcoin from Lightning back to the base layer, a channel must be closed, a loop out can be performed, or a submarine swap can be performed. You can do these yourself, if you are utilizing your own Lightning node, or you can let someone else do it via an aforementioned wallet.

Luckily, there is a flurry of activity surrounding Lightning onboarding and development. Worldwide adoption is in the sights and in range, and it’s going to need all hands on deck.

This is a guest post by Nameless. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc. or Bitcoin Magazine.