Bitcoin Lightning Network Advances & Hurdles for Payments & Merchants

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…

Article Source…