I got that warning about one of my channels on Alby Hub and they're suggesting I close it to improve my node's performance.
I'm curious if someone can give me a brief description of what's up and how this issue is degrading my node's performance.
pull down to refresh
I got that warning about one of my channels on Alby Hub and they're suggesting I close it to improve my node's performance.
I'm curious if someone can give me a brief description of what's up and how this issue is degrading my node's performance.
Every update to a channel creates a set of onchain transactions that you need to store until the channel is closed.
These transactions are how you keep your channel partners honest. At the time of any update, both nodes of a channel exchange transactions that say, and I'm paraphrasing, "if I try to screw you using this point in our history, these transactions I've signed allow you to take all of my money from this channel." So you store those transactions in case they try to screw you.
It sounds like you're rubbing against some storage limits that Alby has and I'd guess that rather than give you unlimited storage Alby prefers nagging you about it.
Could this be from me updating my fee policies too often?
anything you do with that channel. anything.
Routing fees? I don't see why that would cause the channel storage to blow up, but I don't have much experience trying to run nodes with limited storage.
Hmm, this isn't my most used channel, so I was trying to think why it might have more updates than the others.
Please give more details.
That's all the warning says.
Oh yes it could be a problem.
You had too many updates of the channel state, due to instability, restarts, going offline and coming back online in a short period of time.... in other words a shity node.
If is a private node is not so "disastrous" but if is a public routing node, then yes, is a problem in long run.
You could try first a compacting of database to see if you can cleanup some space. If not, then yes, a bigger db channel state could affect the performance and channel can get force closed.
Thanks
So, improving my uptime will make this less of a problem in the future?
Think about how a channel works, as k00b explained very well. Each update is an increase of data stored.
Each update is: state of the channel (offline or online), sats in HTLCs, balances etc almost the whole history is in there, routed or not routed. The more you do, the bigger it is the db.
Now, if you have a good machine for that node, will not be a big problem, but when that db gets too big, then yes, start time will be slower, update will be slower so trouble will come faster than you think and channel will get a nice force closure.
So I strongly suggest to try a compactation procedure before anything else.
idk why Alby is not offering an option to compact the db from their UI. That will be eeasier for the user. Now you will have to dig manually into the belly of your backend node and do it manually, in CLI.
What's the benefit of closing it now when I don't even know if there is a functional issue vs waiting for a force closure?
You start clean and avoid the trouble coming with a FC (longer waiting time, higher fees or even zombie channel etc).
14MB is not so much for a channel, but when you have some hundreds like that, it became a problem. Especially if is a hosted node, not on your own machine with lots of space available.
Ok. It is on my own machine and I only have 10 channels, so it seems like it's probably not a pressing issue yet.
You be zappin' too much on Stacker News, brudda, or gamblin' too much on Predyx
Neither of those are the channel in question, which is part of my confusion.
You should watch cloaer your node, see what could generate this increase in channel status.
I do not know a tool that could analyze the content of db but you could try to look more often into your node logs.
See if are more than usual error entries.
I’ll do that. This issue wasn’t on my radar yet. I keep an eye on which channels go offline and routing activity but never thought to look at the error logs.