We're really sorry about this and working to fix the issues.
Currently there are two main issues that cause force closes in mutiny.
Paying to a zeus lightning address almost always causes a force closure because it uses hodl invoices so the user need to come online between the time the zeus user claims the payment and before the htlcs time out, this can be a few hour window and often no user will hit it. Ldk is doing some work to help prevent this to give us more leeway in when the user can come back online but this will still be a problem, frankly zeus lightning addresses are just a nonsensical way to use lightning. https://github.com/lightningdevkit/rust-lightning/issues/2698
The second being multiple instances of mutiny running for the same seed. We have a bunch of checks to try to prevent this but it is difficult. We've exhausted so many options we're beginning to suspect some browsers (mainly safari) just clears some of our state which can cause the error. In our latest release we've started using a fork of ldk so instead of force closing it'll fail to start up instead, just to add more protection.
After all this, if you do everything right but still get a force close, you needed to come back online within 24 hours of the force close to sweep your money. This is just the nature of lightning with its high availability requirements. Our latest release extended this to two days but the best solution would be to add watch tower support so it can be swept without the user. Ldk does have experimental support for this but not something we've built out yet.
We do work closely with the LSP and if the user's funds are swept we are always able to get the money back.
These always really pain me because everyone on the team uses the wallet everyday and haven't ran into any loss of funds issues, so it's really hard to try and reproduce what exactly is causing all the problems. Fixing these is our top priority but a lot of it is just trying something and putting it out into the wild and seeing if our number of channel closures go up or down. Posting any logs when you get an issue is always extremely helpful.
frankly zeus lightning addresses are just a nonsensical way to use lightning
I disagree. One of the reasons they are not nonsensical is that they expose liveness assumptions about LN that many users (including wallet devs) did not realize it has or did not prepare for. Users often only learn when they get burned. More users are informed now, thanks to a perfectly innocent feature of zeus wallet, and that is a good thing. Also, LN wallets will have to handle hodl invoices better now, and that is good too. Hopefully, wallet devs will design better wallets as a result, including by disabling payments to destinations that they can't yet handle in a way that protects user funds.
reply
Also, LN wallets will have to handle hodl invoices better now, and that is good too.
Sorry for my ignorance, but I thought hodl invoices are indistinguishable to wallets? To them it just looks like the payment is still on route? Which is kind of a feature and not a bug?
So how could a wallet handle this case better if this case is not even reliably detectable?
On the other hand, iirc, Phoenix was able to tell that my payment is on hold when I used it to pay a bond on RoboSats 🤔
reply
Only way to detect it is having a list of nodes that create them. Ideally there should be a flag in the invoice saying that so wallets can act differently
reply
So how could a wallet handle this case better if this case is not even reliably detectable?
The main way has been by manually banning payments to LN nodes that are known for hodl invoices.
In the future, there will probably be more defenses implemented, like better ways to cancel a pending payment, charges for holding up HTLCs, etc.
reply
We've exhausted so many options we're beginning to suspect some browsers (mainly safari) just clears some of our state which can cause the error.
It's always Safari...
reply