ABACUS asked about 1 year ago
Feature Idea
it would be good to have a list view, similar to my swaps .. which shows .. channel size and the two peers you have channels with .. and the expiry date.
That way, we can use the view to help with closing inactive or commercially bad channels.
Right now (unless i'm missing something) it's hard to tell which swap a particular channel/peer belongs to.
Just imagine going through your list of channels, and thinking "mmm is this from a LN+ swap" if not, i can close, if so, when can i close.
SWAP ID, SIZE, IN CHANNEL PEER, OUT CHANNEL PEER, SWAP ESTABLISH DATE, EXPIRY DATE
would be an excellent view,
That way, we can use the view to help with closing inactive or commercially bad channels.
Right now (unless i'm missing something) it's hard to tell which swap a particular channel/peer belongs to.
Just imagine going through your list of channels, and thinking "mmm is this from a LN+ swap" if not, i can close, if so, when can i close.
SWAP ID, SIZE, IN CHANNEL PEER, OUT CHANNEL PEER, SWAP ESTABLISH DATE, EXPIRY DATE
would be an excellent view,
4 Comments
Traverse wrote about 1 year ago
An inactive / commercially bad channel is likely to be a channel where you have a connection to a node at a higher pressure than yours. i.e. the sats get pushed to your side of the channel and stay there.
They are a type of zombie channel. The liquidity is bound up in them and there is nothing you can do other than close the channel and re-open using those sats to a node where sats can flow. That is, a node with a lower or approximately equal price pressure to your own.
They are commercially bad as they consume your liquidity, not the counterparty node liquidity, and they are bad for the network because liquidity invested in the network is rendered useless. And they are bad because an apparently routable channel is not routable in one direction. This is perhaps the cause of nearly all routing failures.
If we had dual-funded channels as standard at the protocol level, this situation would likely not persist. In the absence of that, then node operators need to move to a mindset that channels stuck with all liquidity at their end are ripe for closure. Perhaps also the mindset that if you have a channel with sats stuck at the other end, then it needs to be closed and re-opened.
Sats can't naturally flow through the lightning network consisting of static channels. It can, on aggregate only move back and forth in equal measure. A huge improvement will come when we have channel recommenders (or autopilots) which direct new users not to graph centrality, but to nodes which have reasonable connectivity but could use the inbound liquidity. Using a metric which doesn't account for the balance of node liquidity will inevitably cause problems in the absence of dual funded channels. A good approximation for the balance of satoshis on a node is "price pressure".
They are a type of zombie channel. The liquidity is bound up in them and there is nothing you can do other than close the channel and re-open using those sats to a node where sats can flow. That is, a node with a lower or approximately equal price pressure to your own.
They are commercially bad as they consume your liquidity, not the counterparty node liquidity, and they are bad for the network because liquidity invested in the network is rendered useless. And they are bad because an apparently routable channel is not routable in one direction. This is perhaps the cause of nearly all routing failures.
If we had dual-funded channels as standard at the protocol level, this situation would likely not persist. In the absence of that, then node operators need to move to a mindset that channels stuck with all liquidity at their end are ripe for closure. Perhaps also the mindset that if you have a channel with sats stuck at the other end, then it needs to be closed and re-opened.
Sats can't naturally flow through the lightning network consisting of static channels. It can, on aggregate only move back and forth in equal measure. A huge improvement will come when we have channel recommenders (or autopilots) which direct new users not to graph centrality, but to nodes which have reasonable connectivity but could use the inbound liquidity. Using a metric which doesn't account for the balance of node liquidity will inevitably cause problems in the absence of dual funded channels. A good approximation for the balance of satoshis on a node is "price pressure".
Denaro Libre wrote about 1 year ago
+1 👍🏼 for the proposed feature -- if possible sortable by expiry date
ABACUS wrote about 1 year ago
Thanks @traverse for the post, but it's not really relevant to my feature request.
ABACUS wrote about 1 year ago
Thanks @denaro libre
Please login to post comments.