Redistribute Lightning Channel’s Balances
What to do when one Lightning Channel has too much fund while another has too little.
Disadvantages of too much and too little
Lightning Network Channels was designed to be bidirectional payment channels. Which means if Alice and Bob have a Lightning Channel, then Alice can send payments to Bob, and vice versa, Bob can send payments to Alice. If the conditions are right.
In practice it happens as follows: Alice funds a channel to Bob. In this initial state, all the channel’s balances belong to Alice. So Alice can send payments to Bob, but Bob has nothing to send to Alice. Not until Alice sends some money through the channel. And the same situation may occur later if one of the parties sends all available balance to the other. In this case, the payment channel is only unidirectional, works only one direction.
An ordinary Lightning Network Node has about 5 channels. Some channel may have balance only for unidirectional transactions. So it may a typical situation to Alice has only a couple of channel for outgoing payments and only a couple for incoming payments. This case has its drawbacks. If one or two of Alice’s partners go temporarily offline, it may seriously affect Alice ability to send or receive transactions. Besides, Alice could forward payments between her parties. With one direction channels, this feature also has severe limitations.
What can be done
It may optimize the channels balance’s distribution if a node would transfer some fund from one of its channels to another:
- issues an invoice for itself
- sends a payment out through an outgoing channel
- moves the payment across the network
- brings it back through an incoming channel
This way the outgoing channel will have some reserve for the incoming transactions in the future. And similarly, the incoming channel will have some reserve for the outgoing transactions. The used unidirectional channels become bidirectional.
Technical parts
I am running c-lightning 0.6.2rc1 as my Lightning Node. And I am using pylightning for easier manage Lightning Client with Python.
Investigate the current situation
Here are a few lines of Python code to make visible the available balances on connected channels:
The results are the following:
Where 100% is mine, it is an outgoing channel, no reserve for an incoming transaction there. Where 0% is mine, it is an incoming channel.
I have marked two nodes with red for a demonstration:
0279c22ed7a068d10dc1a38ae66d2d6461e269226c60258c021b1ddcdfe4b00bc4 looks appropriate for an incoming payment. And 0390b5d4492dc2f5318e5233ab2cebf6d48914881a33ef6a9c6bcdbb433ad986d0 looks appropriate for an outgoing.
I am going to try to move some funds between them.
Optimize the distribution
Here comes the hard part. There is some complicated administrative work with route planning, routing fee calculation, invoice handling, sending transaction with payment hash, etc.
Actually only three parameters are required:
- The outgoing node id: the public key of the node, through which the payment goes out
- The incoming node id: the public key of the node, through which the payment comes back
- The amount to be sent denominated in millisatoshi
Here is a script which takes these three parameters and does all the other work for us.
Let’s try to redistribute some fund and see what happens:
Redistribution succeeded. Fortunately, the outgoing and incoming nodes had an open channel between them. So I could choose a route with three steps: the outgoing node, the incoming node, and my node. Here are the results:
I’ve sent 0.015 BTC or 55 USD through the nodes, and it’s cost me 0.00000305015 BTC or 1 penny (2019 January prices).
With little effort, it is relative cheap to reallocate funds between Lightning Channels, and it may increase the network’s resilience and usability.
Thanks for reading! If you liked it, open a channel to my Lightning Network Node, or follow me on Medium or Twitter! Feedback, comments and suggestions are welcome!
