When we last left our hero Carol, she had successfully joined the Lightning Network and started making Lightning transactions. As she's become familiar with the user experience side of Lightning, she's also started to become more interested in Lightning from a technical standpoint. She's even thinking about running a Lightning routing node herself, with the goal of earning enough in routing fees to pay for her monthly BitFlix subscription. This post is oriented toward budding enthusiasts like Carol who are interested in running Lightning nodes, who are building applications for the Lightning Network, or who are just curious about Lightning. Note that this post is targeted at users who already have some basic knowledge of Lightning and payment channels.

Topics that will be covered include:

• Channel balance
• Gateway routing nodes
• Advertised and non-advertised channels
• Buffer capital
• Source routing
• Onion routing
• Bridge channels
• Atomic multi-path payments

We hope this post will give readers a deeper understanding of the Lightning protocol as well as some of our ideas about how the network will grow and evolve over time. We'll also touch on our goals for Lightning, including censorship-resistance/decentralization, security, privacy, usability, scalability, speed, and cost. Two goals that are specific to routing are availability (user funds should be available at all times), and connectivity (network participants should be able to send funds to any other participant).


Channel balance - One of the primary concepts in Lightning is the idea of channel balance. Payment channels have a total capacity (established by an on-chain funding transaction), as well as an amount that each participant in the channel has available to send. For end users, channel balance in Lightning will seem similar in concept to bank accounts or how they use physical cash. Users will fill their Lightning wallet, spend the balance over a period of days or weeks, then refill it. Just as bank or cash accounts can be emptied and refilled over and over, Lightning channels can as well. We would expect Lightning users to keep channels open for months or even years at a time so as to minimize the on-chain fees necessary to close channels and open new ones.

Channel balance also applies to merchants, exchanges and other businesses. These businesses will have both inflows and outflows of funds through their channels, though most businesses will have a greater number of high-capacity channels than end users. Users and businesses that want to increase the “limits” available to send and receive via Lightning can open additional channels or increase the capacity of existing channels (the process of resizing channels is called "splicing" and will be the subject of a future blog post). The key point is that Lightning participants of all kinds will manage channel inflows and outflows, and that this process will appear similar to how things work in existing financial systems.

Routing nodes - We expect most Lightning users to be sending and receiving transactions using mobile devices or computers that have intermittent power and intermittent access to the internet. Because of this, the vast majority of channels will be opened between end user nodes and routing nodes. A routing node is a Lightning node operated with the intent to be online at all times, earning fees by routing Lightning payments. A routing node, like any other Lightning node, must be able to interface with the Bitcoin network. Routing nodes don't necessarily need to be full nodes and can operate using light client protocols such as neutrino. However, more heavily-capitalized routing nodes will likely prefer the additional security provided by a fully-validating Bitcoin node.

“Gateway” routing nodes are those that directly serve end users. These nodes will serve a relatively small number of users (likely in the hundreds) and will have modest hardware, bandwidth and capital requirements. Over time, some gateway nodes will become more highly connected (see bridge channels below). We’re currently working on tools and guides for routing node operators, and initial versions of those will be released over the coming months. Our goal is to help facilitate the development of a broadly distributed routing node ecosystem with low barriers to entry.

Advertised and non-advertised channels - An aspect of Lightning that may not be readily apparent is that the majority of nodes and channels will not be available for routing and will not be visible in the network graph. End user nodes (smartphones, laptops, etc.) will not “advertise" channels by default. These non-advertised channels will be accessible through the use of extra routing information or “routing hints” embedded in Lightning payment requests. Routing hints provide information about a recipient’s non-advertised channels, allowing a payment sender to build routes with a combination of public and non-public hops in the network. As non-advertised channels become the default for end users, we expect Lightning routing to become more efficient, as routing tables will be significantly smaller and populated with more reliable nodes.

In the future, routing hints can also be used to supply more information about valid routing paths, making it possible for payment senders to find routes to receivers, even if the sender and/or receiver have incomplete views of the network graph.

Buffer capital - In addition to providing continuous access to the network, routing nodes will aggregate inflows and outflows across many users so that overall flows to and from a routing node will be somewhat balanced. Essentially, within a given period of time, some of a routing node's users will be spending, while others will be refilling. However, there will be times when funds will happen to be moving in the same direction (e.g. more spending than receiving). In these situations, a routing node must maintain enough "buffer capital" to be able to wait until the flow of funds reverses and channels return to a more balanced state. Routing nodes that don't contribute enough capital to handle periods of imbalance will experience channel exhaustion (when a node has no funds remaining in a channel) and routing failures. This type of failure should happen relatively infrequently, because nodes that produce these routing failures will be routed around and eventually disconnected by other nodes. Thus, node operators have a strong incentive to provide enough buffer capital for the number and volume of inbound channels they've accepted (and implicity agreed to support).

Autopilot and node availability metrics - For end users, lnd has an Autopilot feature that automates the process of finding gateway routing nodes and opening channels. Upcoming iterations of Autopilot will use metrics from the network channel graph when determining which nodes to connect with. Key metrics will include uptime, outbound channel volume, breadth of channel connectivity and proximity to specific destinations. This data will be gathered by routing nodes to facilitate initial channel creation as well as ongoing channel optimization. Essentially, Autopilot will open channels with those gateway nodes that have shown the ability to facilitate reliable, cheap payments. For most users, Autopilot will operate in the background, but for more advanced users, Autopilot's heuristics are designed to be modular. Members of the Lightning community will be able to optimize node selection parameters for their particular use cases and/or replace the default algorithm with entirely new ones.

Another key point about Autopilot is that end users are likely to have open channels with several completely unrelated routing nodes (the current default is five). This gives end users disparate entry points to the network, providing for improved reliability in case a routing node does happen to go offline. This is in contrast to routing on the internet, where ISP options are limited by the costs of building physical infrastructure (fiber and radio transmitters). In Lightning, the cost of adding connection infrastructure to other nodes is simply the cost of an on-chain Bitcoin transaction.

Source routing and onion routing - One of the differences between Lightning payment routing and most data network routing is that in the case of Lightning, the route is constructed by the payment sender (source routing), rather than being determined by the routers along the path. In addition, Lightning employs onion routing for multi-hop payments. This means that intermediate nodes in the payment path know only the identity of their immediate predecessor and successor in the route. Importantly, the combination of source routing and onion routing protects the identities of payment senders and receivers so as to enhance user privacy and censorship-resistance.

Also note that the Lightning Network protocol supports Tor, and future releases of lnd will include Tor support. Communications from end user lnd nodes to gateway routing nodes will eventually default to Tor, providing additional privacy protection.

Bridge channels and network connectivity - Above, we discussed gateway routing nodes, which provide end users a way to connect to the Lightning Network. However, a major consideration for Lightning users will be breadth of connectivity and the ability to send payments quickly and reliably to other participants anywhere in the network. To add this connectivity in a capital-efficient (and low-fee) way, it’s likely that more reliable nodes with available capital will also “bridge” traffic between other routing nodes. These bridge nodes will accept inbound advertised channels from other routing nodes, and will have proportionally larger outbound channels connected to other bridge nodes and gateway nodes. Note that there isn’t a clear distinction between a gateway node and a bridge node. Some nodes may have relatively more gateway channels and others may focus more on bridge channels.

Bridge channels will generally be processing a higher velocity of payments than gateway channels and bridge channels are also likely to have more naturally balanced flows since they’ll be drawing from a larger pool of end users. Because of these two factors, we expect that bridge channels will typically have more allocated buffer capital than gateway channels, but will process magnitudes more transactions with that capital. This capital efficiency should result in much lower fees for bridge hops than for gateway hops. Essentially, bridge channels will give Lightning Network users broad connectivity at lower cost than could be achieved with gateway nodes alone.

As the network grows, we expect more hops and more bridge channels to be added, supporting exponentially more connected users. Our preliminary modeling shows that a network 10-15 hops in diameter could support billions of users with typical transaction volumes and with fees well under the equivalent of $0.01 per transaction. Also note that due to the capital efficiency reasons discussed above, we expect gateway routing nodes to serve only as many users as necessary to generally balance inflows and outflows (approximately hundreds of users), and then leverage bridge channels to provide broader connectivity. From the perspective of the end user, wallets will simply select routes with lower fees, which will tend to include capital-efficient bridge channels.

Another thing to note is that since end users will be connected to the network at multiple points, and because each routing node will be connected to many other routing nodes, attempts to censor transactions by any particular bridge or gateway node are unlikely to be successful. Nodes that attempt to censor transactions can be routed around, and if a censoring node generates abnormal numbers of routing failures, other nodes will disconnect from them. Also note that onion encryption will obscure sender and receiver information from bridge nodes, making it even more difficult to attempt censorship.

Atomic multi-path payments (AMP) - A final topic related to Lightning routing is AMP, which allows for large payments to be split into multiple small payments by the sender. Each of the split payments is sent via a different route through the network, with the recipient combining them together, rejecting or accepting them as if they were a single transaction. To the user, the AMP process takes place automatically behind the scenes. AMP allows for additional routing flexibility and also allows for multiple small channels to be represented to the user as a single unified balance. A future blog post will discuss AMP in further detail.

Conclusion

In this post, we’ve covered some of the basic concepts involved in Lightning routing. We at Lightning Labs believe that with the current protocol, routing on the network can scale to at least millions of users cheaply and reliably while enhancing user privacy and leveraging bitcoin's decentralization and censorship-resistance. We should also note that this article represents some of our ideas about routing, but contributors to the other Lightning implementations and others in the broader Lightning community may have different ideas about how the network will evolve. Lightning is an open source, collaborative community, and we certainly welcome and expect discussion about these ideas.

In addition, it's obviously very early in Lightning’s evolution, and protocol improvements, algorithmic improvements and hardware improvements will likely improve efficiency, privacy and scalability in ways that we can't foresee now. We (and the other implementors of Lightning) do already have a few protocol improvements in the pipeline for future versions of the Lightning Network specification, but over the coming months and years, we expect many more new, exciting and unanticipated ideas to come from the community and ecosystem.