An Introduction to The Lightning Network

Bitcoin is the first, largest, most decentralized, most secure, and most widely used cryptocurrency network. The Bitcoin network has been operating since 2009, and bitcoin – the native token of the Bitcoin network – is widely held in the United States. Despite bitcoin’s relatively wide adoption as an investment asset, the Bitcoin network has not yet seen meaningful use for its originally intended purpose: peer-to-peer, real-time payments built upon an open technology platform. Technological features inherent to the Bitcoin network lead to low throughput, slow transaction settlement times, and high fees. Because of these characteristics, the adoption of Bitcoin as an open protocol for online payments has lagged. 

The Lightning Network addresses these limitations. It is an open-source, layer 2 software protocol that runs on top of the Bitcoin network (the layer 1) and enables near-instant, low-cost payments with the same benefits in network security as the Bitcoin network and wide-scale adoption of bitcoin as an asset.  This article describes the Lightning Network and how it works, concluding with considerations for its use in payment services.

What Are Lightning Network Nodes and Channels

The Lightning Network is made of peer-to-peer, secure payment channels established between Lightning Network Nodes. Payment channels move bitcoin between Nodes securely and quickly, without the costs in terms of transaction fees or block settlement timing attendant to layer 1 Bitcoin transactions.  

Network participants operate Nodes by running open-source Lightning Network node software. This software allows a Node to open payment channels with other Lightning Network Nodes and to make payments through these channels. The Lightning protocol sets the characteristics and functionality of the payment channels. 

Opening and Funding a Channel and Making Payments 

Each Node has a layer 1 Bitcoin blockchain address.  To establish a Lightning Network channel with another Node, a Node sends bitcoin to a new two-of-two multisignature address on the Bitcoin blockchain. Each Node holds one of the two keys to the multisignature address. Both Nodes must sign with their keys to (1) allocate bitcoin between the Nodes in their channel–which is the fundamental building block of payment transactions on the Lightning Network–and (2) to remove bitcoin from a channel by closing the channel (other than in limited circumstances, described below under Trustless Node Interactions and Uncooperative Closing).

Channels are initially funded at the opening, that is, when a Node sends bitcoin to the channel’s multisignature Bitcoin address. The funding transaction is visible on the Bitcoin blockchain, as is any layer 1 transaction. As an illustrative example, Node A and Node B can open a Lightning Network channel with Node A funding the channel with 25,000 satoshis by sending that amount to the channel’s Bitcoin blockchain address. (Lightning Network payments are generally denominated in satoshis, the smallest denomination of bitcoin. One bitcoin equals 100 million satoshis).

Typically the party that expects to make regular payments to the other funds the channel. In cases where both Nodes expect to move money back and forth, both Nodes could fund the channel.

Once a channel is open and funded, Nodes make payments to each other by agreeing to change the allocation of bitcoin held in the channel between them. Transactions that update bitcoin allocations within a channel are referred to as commitment transactions because they commit each Node in the channel to a particular channel balance and thus a specific allocation of funds in the channel. Funds allocated to a Node in a channel are controlled by the Node and are, in effect, owned by that Node. Commitment transactions are a core part of the Lightning protocol and take the form of partially signed but unbroadcast transactions–that is, not published to the Bitcoin blockchain, but shared between channel counterparties–that represent updated channel balances. 

Returning to our example, Node A can pay Node B 5,000 satoshis through their channel by sending Node B a signed message proposing to update the channel balance to Node A 20,000 and Node B 5,000. When Node B accepts the updated channel balance by signing the message, the protocol creates a new commitment transaction representing the updated channel balance. 

The new commitment transaction is held by the Nodes – not broadcast to the Bitcoin network, and thus there is no layer 1 transaction and no change to the channel’s layer 1 Bitcoin address balance.  It will represent the current channel balance, and the ownership of funds by each Node, until the Nodes agree on another channel balance update through a new commitment transaction.

Commitment transactions are the mechanism by which Nodes agree on updated channel balances and, thus, make payments to each other. In our example, Node A now has the ability to make 20,000 sats of payments to Node B (called outbound liquidity). Node B has 5,000 sats of outbound liquidity for payments to Node A. Conversely, Node A has 5,000 sats of inbound liquidity available from Node B, that is, the amount of payments Node A is able to receive from Node B, while Node B has 20,000 sats of inbound liquidity available from Node A.

Commitment transactions are also used to unilaterally close a channel, in case the one Node in a channel is offline or not cooperating. This ability to unilaterally close a channel at the most recent, agreed-upon balance is what makes channels "trustless,” as a Node can remove its funds from a channel without the cooperation of its channel counterparty. 

Cooperative Channel Closing

Channels can be cooperatively closed, which results in all funds in the channel being distributed in layer 1 transactions on the Bitcoin blockchain to each Node channel participant. Either Node in a channel can initiate a channel closing. Most channel closings on the Lightning Network are cooperative, as the uncooperative closing process is most costly in terms of effort and time needed to retrieve funds.

In a cooperative channel close, the Nodes work together to close the channel in an fast and orderly manner. The Node that seeks to close the channel informs the other that it would like to do so. Both Nodes cease payment activity in the channel (by not entering new commitment transactions) and  publish to the Bitcoin blockchain a closing transaction signed by both Nodes, with the same bitcoin allocation as the most recent commitment transaction for the channel being closed (less transaction fees for the layer 1 transaction). In our example, if Node A or Node B initiates a cooperative channel close, Node A will receive 20,000 satoshis and Bob will receive 5,000 satoshis to the Bitcoin addresses they have specified in the closing transaction (again, less transaction fees, not shown).

The closing transaction, like the funding transaction, is a layer 1 transaction on the Bitcoin blockchain and will result in the channel balance being sent to each Node’s designated Bitcoin addresses in the prescribed amounts. This spends the channel Bitcoin output, closing the channel.

Trustless Node Interactions and Uncooperative Closing

A Node can unilaterally publish a commitment transaction to the Bitcoin blockchain to retrieve its funds and close the channel without the cooperation of its channel counterparty. But a Node may try to improperly take bitcoin from a channel counterparty by publishing an outdated commitment transaction. This type of attack is almost never attempted, because the channel counterparty can immediately respond to a revoked commitment transaction by taking the total balance of the channel. This penalty mechanism is effected through the design of commitment transactions, as explained below.

Each channel balance is represented by two commitment transactions, one held by each Node in the channel. Each commitment transaction includes (1) a timelock that delays payment to the Node holding that commitment transaction and (2) a cryptographic revocation secret that bypasses the timelock and allows revocation of the previous commitment transaction. 

In our example, where Node A has 20,000 satoshi and Node B has 5,000 satoshi, the channel balance (or channel state) would be represented by two commitment transactions, each with two outputs:

After signing a new commitment transaction where channel counterparties agree on a new balance, they also send each other revocation secrets, revoking their claim on the previous commitment transaction and previous balance. The channel counterparties store each of these revocation secrets for the duration of the channel's lifetime, to be used in case the other party tries to fraudulently claim an invalidated balance by publishing a previous commitment transaction. 

If a Node does publish a previous commitment transaction, its channel counterparty, with the revocation secret, can invalidate that commitment transaction and take all funds that were released from the channel, not only those that were allocated to it. This must be done by the non-publishing/non-cheating Node before the timelock expires for the publishing/cheating Node. In our example, Node A could try to cheat Node B by taking back the 5,000 satoshis she paid to Node B by publishing the initial funding transaction for their channel (Node A 25,000, Node B 0).  Node B upon seeing the old commitment transaction published, can revoke the transaction and claim Node A’s 25,000 satoshis.

A Node that publishes an old commitment transaction is therefore at risk of having its balance taken by its channel counterparty. This is a serious disincentive to cheating, allowing for channels to be opened between Nodes without the Nodes having to trust each other. The timelock also creates an incentive for channel participants to be online and monitor activity in their channels, to be vigilant against a cheating channel counterparty. This incentive promotes availability of payment channels throughout the Lightning Network and network resilience.

Lightning Network Payments

The building blocks for the Lighting Network are Nodes opening bilateral channels and using those channels to move funds, as discussed above. The Lightning Network uses these channels to allow for payments between Nodes that are not directly connected to each other by channels. Indeed, most payment activity on the Lightning Network occurs by Nodes routing payment transactions through a series of connected Nodes. We can see, in this very stylized figure, how the Lightning Network is formed as a network of Nodes and channels:

Any Node can make payments to any other Node by routing payments through its own channel(s). For example, Node A could make a payment to Nodes C and D, even though it does not have channels open with those Nodes, by routing a payment through its channel with Node B, and then Node B routing the payment to Node C or Node D through its channel with that Node. Thus, payments are made along a payment route by Nodes making a series of bilateral funds movements in their channels.

Each channel along a payment route must have sufficient outbound liquidity to make its leg of the payment. For example, Node A could send a 10,000 satoshi payment to Node C through Node B, because Node B has sufficient outbound liquidity (that is, satoshis it holds in the channel with Node C). But Node A could not send a payment of 10,000 sats to Node D through Node B, because the channel between Nodes B and Node D has only 5,000 stats of outbound liquidity for Node B, so the payment is not possible and the system would not route it. Node A would need to find another route for its payment to Node D.

Several key technological features of the Lightning Protocol enable network-wide payment routing in a secure and trustless manner.

• Invoices. Lightning Network payments are generally initiated by the recipient Node issuing an invoice to the sending Node. The invoice is exchanged between Nodes away from the Lightning Network (for example, through QR codes). The invoice contains the information needed for a sending Node to make a payment to a receiving Node, including a unique payment identifier (called a payment hash), identification of the recipient Node, a payment amount, and an optional text description. Invoices make it possible for a Node to find and send funds to a Node on the Lightning Network to which it is not connected directly through a channel. In addition, the default flow for Lightning Network payments is for the recipient Node to provide an invoice to the sending Node.  This feature allows recipient Nodes to limit inbound payments to those from invoice recipients, that is, to senders known or permissioned by the recipient Node. In contrast, layer 1 blockchains generally do not restrict sending funds to any public blockchain address.
  
  
• Pathfinding and routing.  The Lighting Protocol includes several protocols to help Nodes find payment routes with sufficient availability and liquidity. Publicly available Nodes share Node and channel information through a gossip protocol with all other Nodes. These messages are tracked by Nodes to help them understand the topology of the network. Each Node then finds its own payment routes through source routing. The routing method allows the Node to choose routes based upon various characteristics in addition to Node uptime and liquidity, depending on the information broadcast by the Nodes. 
  
  Some Nodes may choose not to broadcast information about themselves or their channels to the Lightning Network, but may instead be private and available for channel opening or routing only to those Nodes that are aware of their existence through other means (for example, bilateral communication).
  
  
• HTLCs. Hash Time-Locked Contracts (HTLCs) are the software code that allow Nodes to securely form and send Lighting Network payments along a Lightning Network payment route. HTLCs generate cryptographically secure payment instructions so that, once a payment route is found, a payment in the correct amount will be sent along the route from the sending Node to the recipient Node. 
  
  HTLC messages are encoded so that each Node on the payment route receives payment from the just-previous Node and payment instructions to send payment in the correct amount to the next Node on the route only–without knowing other Nodes on the route.  Nodes on the route have no way to view other information included in the payment message (such as in the memo field) and have no way to modify or change the payment amount, recipient identity, routing path or any other information included in the message.
  
  HTLCs also prevent a payment from being partially routed–that is, stopping at a Node along the route other than the final destination. Each payment must either successfully complete its full route, resulting in a payment to the recipient Node, or must entirely fail. This same feature prevents any Node along a payment route from taking funds not allocated to it by the HTLC. For example, it is impossible for a Node to receive funds for a payment for routing but to not pass the payment in the next leg and keep the received funds. Thus, Nodes have no counterparty or settlement risk to any other Node on the Lightning Network by virtue of sending, receiving, or routing Lighting Network payments.

Taken together, these technological features enable fast, low-cost, trustless transactions with important privacy preserving features on an open network.