Among the recent technological advances in Bitcoin, the Lightning Network is one of the most ambitious projects. Once the remaining obstacles are cleared away, it promises to deliver faster transactions, lower fees, spacious blocks and happier wallets.
While the advantages of the Lightning Network are the talk of the town, there is less common knowledge about its obstacles. The rebalancing problem is one of the challenges every node of the Lightning Network will have to overcome. We will shed some light on this subject over a series of articles.
Before we begin, let's take a step back and quickly review the basics of the Lightning Network.
Payment channels
You may have heard about payment channels. They are the first building block of the Lightning Network.
Simply put, a payment channel is a conduit between two parties, let's call them Alice and Bob, which allows them to send money back and forth without having to broadcast transactions to the blockchain. These movements are called off-chain transactions, and are potentially free of charge, and instantaneous.
In the Lightning Network, payment channels are also set up to be trustless. Alice and Bob don't need to be friends for any of this to work. If Bob decided to cheat Alice, he would end up stealing nothing, losing time and possibly money.
To begin, Alice and Bob must open a payment channel. They sign and broadcast a funding transaction, where one or both commit funds. The combined amount of this initial commitment is called the balance of the shared channel, and Alice and Bob each own their part.
Once open, Alice and Bob can update the channel, redistributing the balance among them, as many times as they want. Each update involves signing a transaction and must be agreed upon, but does not require broadcasting it to the network. No confirmation time, no mining fee.
Alice and Bob can make any number of payments through the channel, but the amount transacted in each payment is bounded by the balance of the sender. At a given moment, Alice cannot send more money to Bob than her own portion of the balance.
Finally, Alice and Bob may decide to close the channel by broadcasting a second transaction, known as the closing transaction. The funds in the channel are unlocked and given to both, Alice and Bob, in proportion to the balance they each owned at the time of closing.
Channels make sense when they are updated several times. Opening and closing the channel both require on-chain transactions, thus paying fees and waiting for confirmation times. Also, while the channel is open their funds are locked, meaning they cannot use them elsewhere. If Alice and Bob use a channel to make a single off-chain transaction, they are wasting money and time.
HTLC
Alice might also want to transact with Eve and Dave. To do so she could open a channel with each one of them, and decide how much money she will commit to each channel.
Funds committed to a channel can only be used for payments in that channel. Alice cannot pay Bob with the money she committed to a channel with Eve, despite owning those bitcoins. In order to pay Eve, she will first need to close the existing channels.
The problem with Alice splitting her money between too many channels, is that she won't be able to make a big payment to anyone. Sooner or later, she will have to close the existing channels and replace them with new ones. This will cost her money and time.
The solution to this problem is a special kind of transaction output called HTLC (hashed timelock contract). They are the second building block of the Lightning Network.
HTLCs bring the possibility of sending money through several chained channels. This means that it may not be necessary for pairs of users to create a direct channel between them to make a payment.
If Bob, Eve, and Dave are connected to another user - Carol - Alice could open a single channel with Carol and commit all her funds there. She would not be directly connected to any of the people she wants to transact with, but this would be no impediment.
Carol is a routing node and will route payments between the users she is connected with. Let's zoom in on Alice, Carol, and Bob, and take a look at the state of their channels.
A single payment between Alice and Bob involves an update in all the channels along the route. First, Alice sends money to Carol updating their channel. Then Carol sends money to Bob updating theirs.
Operations with HTLCs are atomic and trustless. Although the payment was divided into two (first Alice paid Carol, then Carol paid Bob) the operation is either performed entirely or not performed at all. Carol knows she will receive Alice's money if, and only if, she pays Bob what was intended.
Rebalancing
Chaining channels presents a problem that is easy to miss. For the whole thing to work, routing nodes must have their channels funded in advance. Carol can only route a payment if she has a high enough balance in her channel with Bob.
Occasionally, routing nodes will be left without sufficient funds to route payments. This happens because every time a node routes a payment, her balance with the receiver decreases while her balance with the sender increases. Although her total amount remains the same, her money is more unevenly distributed.
To keep routing payments, Carol needs to rebalance her channels. Rebalancing is the strategic action a node takes to increase their balance in a payment channel, at the expense of decreasing their balance in another one, to keep routing payments.
Splices
Carol could choose to move her money from one of her channels to another one using on-chain transactions. To do so, she must first close her channel with Alice and reopen it, keeping some funds aside. This operation is called splice out and can be done in a single on-chain transaction.
In a similar way, Carol will then broadcast another transaction and make a splice in. This operation involves closing her channel with Bob and reopening it with extra funds.
Conclusion
Rebalancing channels costs money. Though splices are far more convenient than closing and opening channels separately, they still involve broadcasting transactions and paying on-chain fees.
Therefore, there are at least two costs involved in routing payments: the operational costs of opening and closing channels, and the financial costs of having money locked in.
One question you are probably asking yourself is how will Carol cover the costs of routing payments?
The answer is Carol will charge a fee for every payment she routes.
How exactly does rebalancing impact the fees of the Lightning Network? We’ll talk about this in the next post.
Visit Muun Website: https://muun.com/
Follow Muun on Twitter: https://twitter.com/MuunWallet