lightning-dev

Combined summary - channel rebalancing support kind of exists already?

Combined summary - channel rebalancing support kind of exists already?

A Lightning developer has commented on the possibility of balancing channels in the c-lightning implementation.

While technically feasible through manual creation of a circular route and using the sendpay JSON-RPC command, there is currently no built-in support for this feature. From a protocol perspective, it may not be necessary to consider channel balance. Another developer noted that channel balance may not necessarily be desirable and depends on use cases. An example was given where balancing channels would prevent Bob from paying a 1.5BTC invoice. However, once AMP (Atomic Multi-Path) is possible, this consideration will no longer be an issue.The Lightning protocol offers better possibilities for channel rebalancing compared to Amiko Pay. In Lightning, the source can explicitly specify the entire route and even profit by rebalancing other people's channels if they offer negative fee rates. Channel rebalancing can be useful to reduce the risk of saturation in certain channels at inconvenient times. For instance, if Bob receives a monthly salary from Alice and regularly purchases items from Carol, he would want to transfer funds from the A-B channel to the B-C channel as soon as possible. Another use case could be maintaining privacy by having pseudonymous contacts on the TOR network. To balance his channels, Bob can pay himself a 1BTC invoice, ensuring the route goes through Alice and comes back via Carol. Bob pays fees to avoid disturbing other balances in the network. However, there is a concern that if everyone in the network starts doing this, it will lead to oscillation.An email conversation between Robert Olsson and ZmnSCPxj explores the possibility of balancing channels in the Lightning Network. While ZmnSCPxj acknowledges the technical possibility, no implementation currently exists. The concept of "balance" itself may not be desirable for channels, as demonstrated by an example where a balanced scenario prevents Bob from paying a 1.5BTC invoice. However, with the future implementation of AMP, this limitation will be resolved. The email discussion also raises concerns about the risk of oscillation if everyone starts balancing their channels by paying themselves.In a conversation between Robert Olsson and Aleksej, the need for rebalancing without using blockchains is discussed. Olsson suggests implementing features to refuse routing through certain channels if it would result in less than a specified percentage of capacity, as well as automatically balancing channels to maintain a minimum percentage of capacity. Aleksej proposes that rebalancing can be done automatically during regular transactions, without the need for separate transactions. He believes that users typically have one channel for receiving funds and others for spending, allowing them to refund by spending funds through unbalanced channels in the direction where they own coins. In response, Olsson hypothetically suggests solving the issue of unbalanced channels by paying oneself an invoice and specifying the two channels to balance, while raising concerns about the risk of network-wide oscillation.In the email thread, Olsson presents a hypothetical scenario where Bob opens a channel with Alice for 2BTC and Carol opens a channel with Bob for 2BTC. Olsson proposes that Bob can balance the channels by paying himself a 1BTC invoice, ensuring the route goes through Alice and comes back via Carol. This would result in two nicely balanced channels and improve connectivity in both directions. Olsson suggests adding a function in the CLI to allow users to pay themselves and specify which two channels they want to balance, either manually or automatically. Aleksej responds by stating that rebalancing may not be necessary, as typical users have separate channels for receiving and spending funds. Refunding can be achieved by spending funds through more unbalanced channels in the direction where the user owns coins. Employers can pay employees through channels where they own the money. Aleksej suggests that rebalancing can occur automatically during regular transactions and expresses hope for safe, reliable, and quick routing in the Lightning Network.Overall, the conversation revolves around the possibility of balancing channels in the Lightning Network, with developers discussing technical feasibility, desirability, and potential risks. Various scenarios and use cases are explored, highlighting the need for better channel connectivity and the potential benefits of rebalancing. The discussion also touches upon the future implementation of AMP and its impact on channel balance considerations.

Discussion History

0
Robert OlssonOriginal Post
February 6, 2018 16:53 UTC
1
February 6, 2018 17:19 UTC
2
February 6, 2018 19:16 UTC
3
February 7, 2018 07:13 UTC
4
February 7, 2018 10:00 UTC
5
February 8, 2018 23:11 UTC
Bitcoin Logo

TLDR

Join Our Newsletter

We’ll email you summaries of the latest discussions from authoritative bitcoin sources, like bitcoin-dev, lightning-dev, and Delving Bitcoin.

Explore all Products

ChatBTC imageBitcoin searchBitcoin TranscriptsSaving SatoshiBitcoin Transcripts Review
Built with 🧡 by the Bitcoin Dev Project
View our public visitor count

We'd love to hear your feedback on this project?

Give Feedback