The Lightning Network (LN) has made some significant strides throughout 2018. Evaluating just how far Bitcoin’s second layer has come since its launch reveals some impressive developments and a sizeable increase in adoption. With currently more than 18k open channels and nearly 487 BTC total within those channels, the LN is poised for expanding further as a viable P2P payments network.
However, the LN still faces some notable hurdles before it can achieve its full potential and garner further adoption by merchants and users alike. Navigating the problems around rebalancing LN channels and the development of its design space should prove vital steps in the future adoption of the network, and some intriguing solutions are being proposed.
The Problem of LN Rebalancing
The problem of rebalancing stems from the bidirectional payment channel design of the LN and the requirement for an on-chain funding transaction. The amount that a channel is funded by two parties opening an off-chain LN is predetermined by the parties and is known as the channel commitment.
If Alice and Bob open a channel and Alice deposits 2 BTC while Bob also deposits 2 BTC, then the channel commitment is 4 BTC. Bob and Alice can exchange BTC within this off-chain channel as many times as they would like without fees and near-instant settlement.
However, the amount exchanged is dependent on the balance of the sender as it cannot exceed the sender’s balance, making off-chain LN channels convenient for entities that will fund the channel with a larger value because they will interact through the channel regularly. Conversely, using the LN channel for one-off cases is currently inconvenient as both the funding transaction and closing transaction of the channel require on-chain fees and time to perform.
Where the functional limitations of the rebalancing problem come into play is with users seeking to transact through the LN with multiple parties or parties that they do not have an open channel with. If Alice wants to open a channel with Bob, Charlie, and Daisy, she has to open each channel individually and fund them with a set amount. She cannot process large transactions to any of the parties because her funding is spread out and locked in separate channels, requiring her to consistently open and close new channels based on the evolving dynamics of whom she is paying and how much she is paying them.
The LN approaches this problem by enabling users to transact via chained payment channels in the network using Hash Time-Locked Contracts (HTLCs). Users do not explicitly need to open direct payment channels with other parties they wish to transact with since HTLCs create the possibility of intermediary nodes between two interacting parties functioning as routing nodes.
Eventually, the potential of HTLCs and routing nodes extends the LN capacity to the point where users will not need to open direct channels with anyone on the network, and payments will automatically be routed between users based on the protocol. However, the rebalancing problem is standing in the way of the practical realization of this goal. So what exactly is the problem?
If Alice and Bob wish to transact without opening a direct payment channel, they can do so if Charlie has a payment channel open with both of them.
Alice 2 → 2 Charlie 2 → 2 Bob
In the example above, Charlie has a balance of 2 BTC with both Alice and Bob (4 BTC total) while Alice and Bob both have a balance (sending balance) of 2 BTC with Charlie.
If Alice wishes to send Bob 1 BTC without opening a direct channel with him, she can do so via Charlie as the routing node. However, this requires that all balances in the payment chain update accordingly, leading to following balances below.
Alice 1 → 3 Charlie 1 → 3 Bob
Charlie’s channel with Alice receives 1 BTC to update to 3 BTC while his balance with Bob decreases to 1 BTC because he sent 1 BTC (from Alice) to Bob. Charlie still retains 4 BTC, but his channel with Bob was reduced to 1 BTC. You can see where this is going as transactions become more complex with multiple parties involved.
Eventually, if Alice wishes to send Bob another 1 BTC through the same payment route, Charlie will have 0 BTC in his sending balance with the channel shared with Bob, effectively disabling the routing channel between Alice and Bob because it is unbalanced. They could all simply close their channels and reopen them with new balances, but that method does not scale well and presents inconveniences that merchants would like to avoid.
The resulting dilemma is the rebalancing problem, and it becomes more complex with multiple payment routes stemming from more intermediaries and routing nodes.
Routing nodes receive small fees for their work, so rebalancing is largely their objective in the context of the problem. Several solutions have been proposed for overcoming the rebalancing problem, many of which are clever and offer various advantages and shortcomings.
Solving LN Rebalancing
While there are several proposed solutions available for rebalancing in the LN, none of them are perfect. Providing an example of some of the well-known ones will offer a glimpse into the ongoing innovation in this area. There are two primary types of methods for circumventing the rebalancing issues:
Let’s evaluate two of the primary methods; splicing for on-chain and circular payments for off-chain.
The most straightforward method is opening and closing channels, refunding them and starting again. However, this costs both on-chain fees and time for each channel (as well as confirmation time on-chain) that Charlie closes and opens, an inconvenient solution. Another solution that uses an on-chain method is known as splicing, which is a slightly more efficient way of leveraging the on-chain open/close functionality.
For example, let’s use the situation where Charlie is left with 1 BTC in his channel with Bob, and Alice wishes to send 1 BTC to Bob again. For the sake of the example, Alice now has 3 BTC in her sending channel with Charlie.
Alice 3 → 3 Charlie 1 → 3 Bob
Alice 2 → 4 Charlie 0 → 4 Bob
Based on this dynamic, if Alice wants to send Bob 1 BTC more, she cannot because Charlie has no remaining BTC in his sending balance with Bob. Splicing enables Charlie to close his channel with Alice and reopen it in two stages.
- Splicing Out
- Splicing In
In the splice out, Charlie closes his channel with Alice and refunds it with 3 BTC while retaining 1 BTC on-chain, still equivalent to the 4 total BTC he had earlier. Now, the setup in the channel would look like this:
Alice 2 → 3 Charlie 0 → 4 Bob
1 BTC on-chain (Charlie)
The second stage — splicing in — is where Charlie closes his channel with Bob and adds in the 1 BTC that is on-chain after the splice out, leading to the following dynamic:
Alice 2 → 3 Charlie 1 → 4 Bob
Charlie can now route a 1 BTC or less payment between Alice and Bob again. However, Charlie incurs two separate instances of on-chain fees for both the splice out and splice in. The incurred fees are why Charlie can charge small fees for being the routing node between Alice and Bob.
Overall, splicing is more efficient than closing and reopening the channels between the parties since only Charlie is involved. Despite its increased efficiency, it still incurs costs in fees and requires the confirmation time of an on-chain transaction, not ideal for merchants to rebalance their channel. Fee structures from this model also lead to further rebalancing complexities.
A separate method for channel rebalancing using an entirely off-chain structure is known as circular payments, and it is best understood with a slightly more complex payment model. Essentially, circular payments are self-payments through a specified routing path where a node rebalances by paying itself through chained off-chain transactions rather than opening a new channel.
For example, Charlie wishes to rebalance his channel with Bob in the chart below. Circular payments can actually work as a triangle because there simply needs to be a minimum of 3 nodes involved.
In the example above, Charlie would send 1 BTC (counter-clockwise) from his channel with Alice to himself through the direction of the arrows, eventually receiving the 1 BTC in his channel with Bob. As a result, Charlie’s sending balance with Bob is now 2 BTC.
Charlie can subsequently route a 2 BTC payment from Alice to Bob in the opposite (clockwise) direction. Alice cannot directly send 2 BTC through her channel with Bob because she only has 1 BTC in the channel, but she can use Charlie to send it to Bob.
With more nodes and channel values, the process can become a self-sustaining ecosystem based on fee structures. Rebalancing nodes are completed entirely off-chain with no need for on-chain transactions. A routing node can rebalance their channel whenever they want, by simply initiating a transaction to itself.
Circular payments come with their caveats too, however. They lead to fees by the routing nodes in the self-payment cycle. The larger the transaction chain, the more fees paid. Nodes still do not need to wait for on-chain transaction confirmation times, but the fee structure can become complicated and is capped by the balances of the routing nodes in the payment chain.
Merchants in such an ecosystem would also aggregate most of the exchanged BTC in circular payments if they were part of the chain for an extended period because they are only receiving rather than paying. Such a system may end up producing competitive routing and unnecessarily large channel balances by non-merchants for it to function consistently.
Other Developments in the LN
Overcoming the rebalancing of LN channels is vital for the ability of the LN to operate without users having to open direct payment channels with one another, one of its most powerful properties. Imagine going to a new coffee shop or fast food restaurant and having to open a payment channel and deposit a specific amount of BTC each time. That method is inconvenient not only for the customer but also the merchant.
Eventually, these solutions should work in concert among other developments to enable users to seamlessly transact using the LN without having to open a direct channel. The only requirement would be that the merchant and customer both have LN-compatible Bitcoin wallets.
As the LN continues to progress, there are several more important components worth mentioning. Specifically, the LN also allows for Onion-routing micropayments for enhanced network-layer privacy and Lightning Labs has made strides in updating the security of their LN desktop app released back in September.
The user experience of the LN is mostly geared towards developers too, at the moment. A high technical barrier to adoption is natural with emerging technologies, but the UI/UX is rapidly improving with the LN already. Pierre Rochard provides some excellent guides on using the LN, especially with Joule — the new LN Chrome extension.
Further, the progression of submarine swaps should also facilitate easier channel refilling and interoperability, an important consideration for increasing the flexibility of the LN among merchants. Blockstream’s recent inclusion of satellite-compatible LN micropayments is also another significant step forward for users without an Internet connection, opening the power of LN to many people without banking access.
Bitcoin’s LN is making noticeable strides in both development and adoption. Rebalancing channels in routing chains present an obstacle for the network to reach its full potential but should end up proving a speedbump in its acceleration towards a viable and ubiquitous P2P payments layer.