Relevance of Balancing Channels \ stacker news ~bitcoin

226 sats \ 10 comments \ @2bithits 29 Apr 2023 bitcoin

Just wondering why this is important?

If a channel is 100% on your side, what is the problem with that?

If a channel is 100% on the oher side, what is the problem with that?

As I understand if a payment gets routed through your node, it comes out of 1 channel & into another channel. Seems fine.

What am I missing here?

view all related items

333 sats \ 1 reply \ @k00b 30 Apr 2023

You can’t receive on a channel where all the liquidity sits on your side, or send on a channel when it sits on your channel partner’s side.

So it might matter depending on the state of your other channels, your peers, and the state of the graph.

Your node will remain “balanced” in a naive sense but your channels won’t as it’s unlikely all routes and directions through your node are evenly used.

0 sats \ 0 replies \ @2bithits OP 30 Apr 2023

I've found that a lot of my channels have been pulled to my peers side & then remain there. I'm wondering if I'm being gamed, but I still see an equal amount of sats received into another channel.

What do you think if at least SOME of the channels are balanced? The others just leave open even though they may only be used rarely if ever again.

21 sats \ 2 replies \ @gnilma 30 Apr 2023

It depends what you aim to use your node for. If you want to be a routing node, then balanced channels allow you to have more routing capability. Like what k00b said, if all liquidity is on your side, you can't receive; if all liquidity is on the partner's side, you can't send. Imagine if a transaction wants to route through your node via one of the channel you're connected to, but your channel can't do it because the liquidity is all on your side (can't receive) or all on the partner's side (can't send).

If you plan on using your node to just do spending and receiving on lightning, then it shouldn't matter as much. Except that you want to make sure the nodes you have channels opened to have good connections / are good routing nodes. You would just be spending from channels where the liquidity is on your side, and receiving into channels where the liquidity is on the partner's side.

0 sats \ 1 reply \ @2bithits OP 30 Apr 2023

Thanks

That's kind of makes it clearer as to what the difference between a routing node & a send/receive node.

So a routing node would cost a lot more as you'd have to constantly rebalance channels too far in outbound/inbound liquidity?

21 sats \ 0 replies \ @gnilma 30 Apr 2023

Your send/receive node can route too, but it's just not optimized for routing. As such, the routing volume might not be very high, or the volume might even be insignificant / nonexistent. But if your goal is not to be a profitable routing node, then I don't think it's a problem.

Yes, running a profitable routing node is not trivial. You have to manage liquidity, set appropriate fees, and balance channels accordingly (but at the same time, need to be mindful of the cost of balancing channels). Many of the well connected channels on the network right now either pushes liquidity or pulls liquidity. That is probably why you are seeing a lot of your channels sitting one sided, with either all liquidity on your side or your partner's side. That's normal behavior. In fact, LND 0.16 onwards updated its routing algorithm to assume most channels are lopsided, where before, the routing assumes channels are balanced.

21 sats \ 3 replies \ @siggy47 29 Apr 2023

Routing on the lightning network relies on having payment channels with available liquidity in both directions, so your node may not be able to route payments. Another thing: you stand to lose funds if all your liquidity is on the other side and a channel is closed, assuming you're dealing with a bad actor.

0 sats \ 2 replies \ @2bithits OP 30 Apr 2023

If all liquidity is on the other side there must have been an equal amount if sats received in another channel right? So if the "bad actor" closed the channel I don't see how I could lose funds.

31 sats \ 1 reply \ @siggy47 30 Apr 2023

By broadcasting an old channel state. Using a watchtower can prevent this from happening

0 sats \ 0 replies \ @2bithits OP 30 Apr 2023

Ok, great. I thought you might have been talking about something else

0 sats \ 0 replies \ @DarthCoin 30 Apr 2023

Consider reading these: