The bitcoin on-chain fees increased rapidly within a short amount of time (spiking by more than 500x). Channels may automatically close as a protective measure. This isn't something specific to Alby, it's a built-in failsafe mechanism within the Lightning Network itself, designed to keep your funds secure during unexpected network events.
Is there a way to recover my funds without opening another channel?
No funds are lost and you don't need to do anything. Since this was a forced channel closure, your bitcoin will reappear in the savings balance of your Hub within 14 days.
Where's my savings account?
Your savings account is your bitcoin onchain wallet. You find it on the "Node" page of your Hub.
Sure thing! So, @felipe was worried because he couldn't find his savings or money after something called a "channel" closed on his Hub. He didn't want to open a new "channel" because it costs a lot and he was scared of losing more money.
Then, @Alby explained it like this - Sometimes, when the cost of doing things with bitcoin goes up really fast, these "channels" closes on their own to keep everything safe. It's like a seatbelt in a car that tightens when there's a sudden stop to keep you safe in your seat.
@Alby also told @felipe that his money isn't gone, it's just going back to his savings account in his Hub (it's like his piggy bank). This could take about 2 weeks. And he mentioned that @felipe's savings account is really his bitcoin wallet, which can be found on a page called "Node" on his Hub. So, Felipe doesn't have to worry about losing his money, it's just taking a little time to return to his piggy bank.
What's next
The bitcoin on your closed channel will become available again within 14 days in the Savings Balance on the "Node" page of your Hub. Users subscribed to Alby Cloud received a new channel for free.
This was possible due to their monthly subscription and our collaboration with Megalith, the LSP (channel provider). If you are in need of re opening a channel urgently, you can do so following this guide.
Thanks for coming here and give an explanation. Many noobs are starting with Alby Hub and do not understand fully how LN channels behave in high fee env.
Will be nice to add into Alby Hub more info about closed channels, so the user could see what really happen and how much time will take to recover their funds. Right now for a total new user to LN, this could look like a terrible situation where their funds just disappear and there's no way to recover (and we know that is not true).
Channels across different lightning implementations can be better configured.
Phoenix has the advantage that their LSP service has been built by the same team that build the mobile wallet. So both lightning implementations are well aligned.
But you only can open channels to their LSP afaik.
Alby Hub lets you choose the channel partner and allows you to open channels to several LSPs. That's why we are actively working with them better cross-implementation configurations.
A forced closure doesn't automatically result in loss of funds? I thought that was one of the reasons people are still a bit unsure about using LN? (I'm a LN-noob)
Nevertheless, one has to pay the fees for a new channel again, which still hurts.
The underlying problem is that commitment transactions need to surpass the dynamic minimum mempool feerates of nodes in order to be admissible to mempools. When there is a huge spike in blockspace demand, mempools may overflow and begin evicting transactions. This may raise the bottom feerate of nodesโ mempools beyond prenegotiated feerates of commitment transactions. Those commitment transactions would then no longer be able to reliably close channels unilaterally. Some node implementations therefore preemptively close channels on feerate spikes.
With the release of Bitcoin Core 28.0 we will get opportunistic package relay for child-pays-for-parent transaction pairs. This will allow Lightning Commitment transactions to be submitted into mempools even if their individual feerate is lower than nodesโ dynamic mempool minimum feerates by sending them alongside a child transaction that raises the packageโs feerate above the mempool minimum. Hopefully this work in Lightning implementations will progress quickly after the Bitcoin Core v28 release.
This happened due to this huge fee, short fee spike and an issue with some LSPs. It's actually a default lightning mechanism and a protective measure implemented in LDK.
It's independent of Alby and happens across implementations. and it's a closure, the sats will become available in the savings balance.
we are investigating this and also collaborating with LSPs to see how this can be avoided in such a LSP relationship. It's independent of Alby and happens across implementations.
Wow this is a total tragedy... a few months ago something similar happened to me with a channel I had on Blixt, fortunately there were not many SATS around 30,000 SATS. I tried to restore my wallet but my SATS never appeared in LN, nor onchain, simply all channel records disappeared along with the SATS.
I opened mine when fees were 2-3 sats/vB. Shame it still closes during short spikes. Iโm not going to waste my sats on this again. Sats are like glue, the more you handle it, the more you lose
understandable, though technically there is still a lot more to it than a "short spike".
But did you get our email? we work hard with the LSPs to prevent this but we put this on auto-pilot for users, so you don't need to care.
did you were able to withdraw those funds?
Mine is not working. I wanted to switch the LN implementation of Alby Hub to LND so I have to swipe all the remaining funds from that node.
Sorry about this. The withdraw function a bit broken (it didn't set aside enough fees to pay the onchain transaction) and will be fixed in 1.6.0 (released on github) which should also go out to Alby Cloud in the next few days.
Also, if you don't use the wallet any more and have no channels, you can import the seed into Sparrow wallet and send the sats out from there (only recommended if you are not actively using Alby Hub)
Yes I know that.
I just wanted to be able to use as is (testing all functionalities) and also I tried to open a new channel with those onchain funds with no success. The wallet is locked.
But I will wait for new release and reset the node switching to LND backend.
More testing.
New apps like this must be intense tested and improved with feedback. I do not complain that is not workinng smooth from beggining, these are normal issues that must be informed to devs and give as much feedback is possible.
locked - not being able to do any tx with it.
I tried to look into logs (debug section), but there is not very detailed and seems to be ok.
It's OK, if you already found the problem and will be fixed, no problem, will wait for the fix and test again.
I really like this idea of Alby Hub and want to go discovering more about it. Will send also some more feedbacks.
For the logs, you'd have to change the log level. This will be difficult currently in Alby Cloud, but if you run Alby Hub self-hosted you can change the LDK_LOG_LEVEL environment variable (e.g. LDK_LOG_LEVEL=1 to enable trace logs).
@Alby can you give more details?
Indeed same happen to my Alby hub with a LDK backend.
I think was due to these crazy high mempool fees going on.
It really sucks when you buy an inbound channel and they FC on you...
Also is really confusing, no info about the closing channel and where the sats are going, to which onchain wallet, closing tx, no way to trace that closing channel.
This happened due to this huge fee, short fee spike and an issue with some LSPs. It's actually a default lightning mechanism and a protective measure implemented in LDK.
it's a closure and the sats will become available in the savings balance.
we are investigating this and also collaborating with LSPs to see how this can be avoided in such a LSP relationship.
The fee negotiating process between LN implementations is terrible. And that could trigger this nightmare. LN devs should really consider to fix or change this behavior. I know is a protection mechanism in LN protocol, but it doesn't make any sense to get fucked so easily for no reason.
People are paying sats to buy those LSP channels and closing them just like that will have a huge impact in using this kind of nodes and LN in general.
yes, we also worked hard on this and have quite some measures around fee negotiation to protect users. it eats a lot of resources :)
it's also a bit of a balance depending on the channel partners and how "trusted" those are. some implementations are rather strict which does not make sense in a LSP context.
this case was even another edge case...
We hate force closures as everybody else. Although they can protect users. That's why they exist.
Step by step we are able to reduce the probability of these events.
On top Alby Cloud subscribers receive new channels.
In this case, due to such a rapid jump in fees, there was a big difference between fee estimates for different block confirmation targets, and different node implementations used different confirmation targets for the fees.
We have a workaround in place for Alby Hub as we run a blended fee estimator, so this particular force close issue will not happen again.
I don't believe it's a channel size issue, and Alby Hub users have full control over their channel management. You can open channels with whoever you want. If you decide to buy a channel with an LSP, then yes we help users there to make things simple to get started.
Thatโs what it looks like. I wish there was a warning for you to wait for fees to come down. Folks on Nostr think you paid way too much. But you live you learn right.
Due to this huge onchain fee spike a few users saw channel force closures. This is a normal protective measure by the lightning implementation and the sats will become available in the savings balance. Alby Cloud subscribers will receive a new payment channel thanks to the collaboration with our LSP.