Both the rapid growth and technical obstacles facing the more widespread adoption of Bitcoin’s Lightning Network (LN) have spawned some productive conversations around how to improve the young network. Among one of those obstacles that have recently gained attention is known as the ‘inbound capacity’ problem.
An inherent result of the bidirectional design of payment channels in the LN, the problem makes receiving LN payments for new nodes challenging, requiring several methods to supplement their inbound capacity. The inbound capacity problem gained mainstream recognition following the increasing difficulty of receiving the Lightning Torch that was passed between enthusiastic LN users on Twitter.
Since then, the problem itself, and proposed solutions for reducing the complications of the inbound capacity problem have made themselves more apparent. Eventually, the complexities of channel rebalancing and issues such as inbound capacity should be masked from the end user, but for now, it is worth evaluating what precisely the problem is and the ongoing initiatives to solve it.
What is a Node’s Inbound Capacity?
Bitcoin’s LN is composed of bidirectional payment channels between users among a mesh network of nodes. Payment channel capacities between two users are fixed once a channel is opened between them, and cannot be changed until after the channel is closed and a new one is opened.
Payment channels are composed of two sides, a remote balance and local balance. Your side of the channel is the local balance, and the other side is the remote balance. So, if Alice and Bob have an open payment channel between them with a capacity of 5 BTC, and you are Bob, then your local balance is 2 BTC, and remote balance (Alice’s balance) is 3 BTC — the channel capacity is 5 BTC.
Alice 3 <————————-> 2 Bob
Alice and Bob can update the balances within the channel without exceeding the channel capacity (5 BTC), but sometimes problems arise from a two-way channel design. If you want to accept payments or balance your channels, working around the bidirectional design can be tricky, especially when you introduce more parties and payment routing into the picture.
For example, if Charlie wants to receive a payment from Alice, but only has a channel open with Bob, it is still possible for Charlie to receive payment from Alice — as long as Bob has sufficient BTC to route to Charlie, which is Charlie’s remote balance with Bob, and Bob’s local balance with Charlie.
Alice 3 <—————-> 2 Bob 0 <—————> 2 Charlie
In the example above, Alice cannot send Charlie any BTC because Bob’s local balance (i.e., Charlie’s remote balance) is 0 BTC. Alice’s payment is inhibited by Charlie’s inbound capacity. So, Charlie’s inbound capacity at any point during his channel being open is limited explicitly by his remote balance with the counterparty (in this case, Bob) that is routing the payment.
In the example above, Charlie’s inbound capacity is zero. However, in the example below (with 1 BTC larger channel capacity), Charlie’s inbound capacity would be one, and he could receive up to 1 BTC from Alice. This highlights how, in general, liquidity is one of the largest problems facing the LN’s growth, which is not surprising considering it as a young payment network.
Alice 3 <—————-> 2 Bob 1 <—————> 2 Charlie
The inbound capacity problem arises from the fact that when counterparties fund their channels, they are only initially funding their respective local balance. The counterparty’s deposit into the channel is subsequently a respective party’s remote balance. As a result, LN users can determine their outbound capacity (which correlates to their local balance), but they do not have direct control over their inbound capacity.
When you add in more connections throughout the network and routing between nodes, the problem can become even more convoluted. Imagine thousands of nodes not directly connected but relying on routing nodes to perform the payments. You may have solved inbound capacity with an adjacent node, but then you have to take into account the inbound capacity of an adjacent node that’s adjacent to that node, and so on and so on.
Such a dynamic requires liquidity providers functioning as routing nodes, and methods for mitigating the inbound capacity problem of users with small channel balances or ones that are new to the network.
The inbound capacity problem is likely one of the primary causes that the Lightning Torch became increasingly difficult to pass in its later stages. As the torch gained value, the number of liquid providers for routing payments became smaller, thus precluding many users from being able to receive the torch — their inbound capacity was not sufficient.
Despite the problems it presents, particularly for new users just launching their nodes and opening channels, there are several methods for increasing your inbound channel capacity.
Addressing the Inbound Capacity Problem
Increasing your inbound capacity means opening channels and connecting to routing channels with large remote balances (i.e., large local balances from their perspective). Balanced and well-connected nodes are the optimal choices for improving inbound capacity, as they will connect you to many other public nodes, but it is not always that simple for new nodes launching in the ecosystem.
Fortunately, there are several very straightforward methods for increasing inbound capacity — such as simply making outbound payments. Spending coins transfers them from your local balance to your remote balance. It requires that you spend coins, but since most payments via the LN are tiny anyway, sending micropayments within various channels isn’t a significant financial burden and can help boost your inbound capacity.
Another fairly straightforward method for increasing inbound capacity is asking node operators to open incoming channels with you. The best way to do this is with several channel opening services that actually will open a channel with your node directly — sometimes for free and sometimes for a very small fee.
Bitrefill’s Thor, LightningTo.Me, and LNBig.com are all channel opening services with various channel capacity conditions and fees. Such services are handy when launching a new node, for instance, if you purchased a Casa Node and want to start receiving payments.
Other services, albeit custodial ones, offer to exchange LN BTC to on-chain BTC, which is basically a different version of spending LN BTC to buy on-chain BTC. Some of these services include zigzag, coinplaza, and lightningconudctor. However, these services are custodial, and a new non-custodial option from Lightning Labs may prove a better alternative — although it is still in the early experimentation phase.
It’s called Lightning Loop, and it is a non-custodial on-chain/off-chain bridge that uses submarine swaps to acquire inbound capacity from arbitrary network nodes, depositing funds into on-chain wallets without closing a channel, or paying to an on-chain fallback address if liquidity is insufficient for routing.
Based on the lnd implementation from Lightning Labs, Lightning Loop currently only consists of the ‘Loop Out’ functionality, which enables to exchange off-chain funds for on-chain funds in a non-custodial manner. The ‘Loop Out’ functionality is not available yet but will allow on-chain funds to increase the local balance of an LN channel.
Overall, the inbound capacity problem is more of a result of insufficient liquidity in an early-stage payments network than a pivotal design flaw. Solutions are already available for merchants, LN enthusiasts, and developers to overcome the problem — both simple and some more complicated.
As the LN continues its progression, more open channel services, non-custodial swapping services, and UI abstraction of the inbound capacity problem are likely to grow in prevalence.