Lightning Network Primer

The Lightning Network is a layer 2 protocol on top of the Bitcoin blockchain that provides scalability and nearly instant bitcoin settlement, while retaining the security and decentralization advantages of Bitcoin.

This article has three parts. First, we describe Lightning Network payment channels, a core concept underlying the Network. Then, we explain how those channels become interconnected to form the Network. Finally, we will outline how payments transit through the network.

Payment channels are the essential building blocks of the Lightning Network. A channel is a Bitcoin output that requires signatures from two keys held by two channel counterparties. Both parties must sign the same transaction to move these bitcoins. These channels have special functionality and properties afforded to them by the Lightning Protocol that enables payments between channel counterparties and across the Lightning Network more broadly. But to fully understand how payment channels work and how they are the foundation of the Lightning Network, it helps to start from the basics by describing what problem payment channels address for payments between two counterparties.

Alice and Bob frequently send funds back and forth. It’s costly and slow for them to settle their payments on Bitcoin layer 1 for every transaction, but what if they agreed to send messages to tell each other how much one owes the other? They could keep exchanging these messages until the point where one of them wishes to settle on chain. Unfortunately, this arrangement isn’t ideal because Alice and Bob must trust each other to send the bitcoin owed when they agree to settle.

To overcome the trusted nature of this approach and ensure that the promised bitcoin exists, Alice and Bob introduce a spending condition on some bitcoin. For example, Alice and Bob could have 10 bitcoin and place a spending condition that says the bitcoin cannot be spent without both Alice and Bob cryptographically signing. The initial allocation of funds, sending 10 bitcoin to this shared address, will be referred to as a funding transaction. The funding transaction is published on chain. Alice and Bob can exchange messages about their respective balances - that is, they can make payments to each other from the 10 bitcoin – and know that neither can spend any of the 10 bitcoin – that is, unlock and move it – without the other party agreeing to the transaction. Imagine that Alice’s allocation is 3 bitcoin, and she wants to spend it. Alice cannot move her bitcoin if Bob refuses to sign a spending transaction. Bob could extort Alice and refuse to sign, resulting in a different type of trust problem.

To address the risk of one party inappropriately withholding their signature for an otherwise valid spending transaction, both parties could sign a spending transaction for every payment message exchanged. As in the previous example, Alice and Bob agree to hold 10 bitcoin with a spending condition that requires both to cryptographically sign how the bitcoin are spent. But prior to funding with the 10 bitcoin, they both sign a commitment transaction that spends the output of the 10 bitcoin and agrees on the initial allocation - for example, 10 bitcoin to Alice and 0 bitcoin to Bob. Both parties hold onto the commitment transaction and could later publish it to move their held bitcoin since it was signed by both parties - satisfying the spending condition.

If Alice were to send 3 bitcoin to Bob, then both parties would sign a new transaction which now allocates 7 bitcoin to Alice and 3 bitcoin to Bob. They again hold onto this transaction without publishing it on chain, but would be able to publish it on chain later to unlock the funds. Neither party can inappropriately hold the other’s funds because both parties have the signed transactions that they could publish on chain to spend their own balance. Alice and Bob can continue to make payments to each other by exchanging signed spending transactions, each of which updates the allocation of the bitcoin balance in the channel. When either wishes to spend their funds on chain, they can publish the most recently signed spending transaction.

But Alice still has the original signed transaction, which would give her all 10 bitcoin even if she had made payments to Bob with later signed spending transactions. So she needs to be prevented from publishing that transaction, which would otherwise result in her taking funds that are not hers.

To prevent this, Alice and Bob create revokable allocation transactions. As before, they publish an initial funding transaction on chain, which says that the 10 bitcoin cannot be spent without both Alice and Bob signing off. But before doing so they create two different commitment transactions: the one held by Alice says that if Alice publishes the transaction, Bob can spend his coins immediately, but Alice cannot spend her coins for some time - for example, 2 days.  Bob holds a transaction with the same allocation but opposite restrictions: his transaction says Alice can spend her coins immediately, but Bob must wait 2 days to spend his funds. The commitment transaction mechanism also ensures that during the 2-day waiting period, if the non-publishing party has a revocation key, they can claim all the funds in the channel, regardless of the stated allocation. After each payment these revocation keys are shared between channel counterparties, erasing the previous allocation after agreeing on a new one. If either party attempts to cheat the other, the cheating party can be penalized by losing all of their funds.

One consequence of either party publishing a commitment transaction to spend funds out of the channel is that, even where the correct and latest commitment channel is used, the publishing party has to wait 2 days before they can spend their bitcoin. They can avoid this delay by signing a closing transaction.  They can agree to settle and close their channel by cooperatively signing a transaction that allocates each of them their latest balances and requires no lock-up time for either party. This cooperative closing transaction would only be done when closing their channel.  But if one party ever goes offline or refuses to cooperatively close the relationship, the other party still has the recourse to publish the uncooperative closing and claim their correct balance in 2 days.

With this technical background on payment channels and an understanding of how they allow for trustless off chain bitcoin transfers between two parties, we can move to a more detailed discussion of the Lightning Network and how payments work on the network more broadly.

The Lightning Network is a network of nodes – computers running the Lightning protocol – connected by payment channels. When Alice opens a payment channel to Bob and funds it with Satoshis/sats (the base unit of bitcoin), all the sats will initially be on Alice’s side of the channel. When she sends sats to Bob, some sats move to Bob’s side of the channel. The sats always stay in the channel between Alice and Bob, but are owned by Alice or Bob depending on their location in the channel. Alice and Bob can send the sats back and forth within their channel as many times as they want without transacting on the Bitcoin blockchain.

The payment channel between Alice and Bob allows Alice and Bob to make payments – moving sats within the channel – to each other. Lightning extends payment channels by creating a network of payment channels, which allows network participants to send payments across the network – not only to their direct channel counterparties.

Imagine a scenario where Alice has a payment channel to Bob, and Bob has a payment channel to Charlie. While the sats in each payment channel are locked, Alice can still send a payment to Charlie by routing the payment through Bob.  To do so, Alice would push the correct amount of sats from her side to Bob, and Bob would push the same number of sats in his channel with Charlie over to Charlie’s side.  The number of sats in total in the Alice ↔ Bob channel and in the Bob ↔ Charlie channel also remains unchanged, but the position of the sats in each channel has changed, and thus a payment has been made from Alice to Charlie.

While the payment occurs by Alice sending sats to Bob and Bob sending sats to Charlie, Lightning makes this process an atomic operation. Bob cannot change or modify the amount or recipient of the payment and cannot use or take the funds being routed.

Lightning Network payments are typically initiated by the recipient requesting a payment from a sender. For example, to request a payment from Alice, Charlie creates a “Lightning invoice,” which contains a value Y which is the hash of some secret value that Charlie generated, and only Charlie knows. Then, Charlie gives this invoice to Alice.

A payment between Alice and Bob is created that says, “if Bob presents a secret value that hashes to Y, then Bob can claim 1,000,000 sats.”  Bob then creates a payment to Charlie with the same condition - “if Charlie presents a secret value that hashes to Y, then Charlie can claim 1,000,000 sats”.

Only Charlie knows the secret value that hashes to Y, he is the only one who can claim the 1,000,000 sats from Bob. To claim it, Charlie must tell Bob what the secret value is, which allows Bob to claim the 1,000,000 sats from Alice. Result is that Alice moved 1 million sats (or 0.01 bitcoin) from her side of the payment channel between her and Bob to Bob. Bob moved 1 million sats from his side of the payment channel between Bob and Charlie over to Charlie. So Alice paid 1 million sats, Bob had no net change in bitcoin, and Charlie received 1 million sats. In this example, Bob routed the payment for Alice.

Bob and Alice will likely not want their bitcoin locked up in their channel forever, though. If Charlie had never provided the secret, Bob and Alice should not lose any funds.  This is avoided through a timelock.  Essentially, timelocks provide the restriction that the bitcoin are locked up only for a few hours, after which the timelock expires.  If Charlie presents the secret after expiration, the bitcoin will have reverted to the original owner.

The example above was a simple payment route with one hop, through Bob’s node. But payments on the Lightning Network can be routed across the network, along payment channels connected by many nodes.

Indeed, Lightning Network nodes typically have many payment channels between themselves and other nodes; the Lightning Network is a graph of nodes connected through payment channels. The more well-connected a node, the more reliable its payments are. For example, it may be more challenging for a more isolated node to send or receive payments.

To send a payment over the Lightning Network, Alice creates a payment channel and puts in her own sats to open the channel. She then sends those sats through a payment route that her Lightning client determines. The route the payment traverses needs liquidity along each hop. Since internal balances of channels are not visible, her Lightning client may need to try multiple routes to find a successful path.

To receive funds, Alice needs to find inbound liquidity–someone to lock funds into a channel with her so that she can receive funds from others on the Lightning Network. For example, if all of the sats are on Alice’s side of a payment channel with Bob, she cannot receive funds through that channel. Often, this requires Alice to pay someone ahead of time to open a channel with her and fund the opposite side of the channel. As in the case of sending payments, appropriate liquidity must exist along the entire path from the sender to Alice.

The Lightning Network emerges as a promising and powerful answer to Bitcoin's scalability challenge, delivering nearly instant and low-cost transactions while maintaining the security and decentralization that underpin the Bitcoin network. At its core, the Lightning Network relies on payment channels, which let two parties transact securely off-chain, streamlining trust and lessening the strain on the Bitcoin blockchain.

By interconnecting these payment channels, the Lightning Network facilitates seamless payment routing throughout the network, allowing users to send Bitcoin to anyone on the network—even those without a direct payment channel to the sender. The Lightning Network's innovative solutions to Bitcoin's scalability issues are a significant step forward in making Bitcoin a viable payment system.