pull down to refresh
245 sats \ 30 replies \ @DarthCoin 14 Nov 2023 \ on: Mutiny Wallet forced closed, on-chain balance zero bitcoin
Similar cases with LDK mobile nodes here (that are still not resolved until today, nobody knows where the funds go after the FC):
- https://github.com/synonymdev/bitkit/issues/647
- https://github.com/synonymdev/bitkit/issues/770
- https://github.com/BlueWallet/BlueWallet/issues/5157
LDK have issues.
reply
I know. That's why I am very reticent using LDK wallets as daily apps. I just test them to know how are working.
reply
I accept FCs being "issues", but a bug that causes loss of funds to me is a more serious matter as Mutiny calls itself self custodial. But if the LSP is able to sweep your funds then it clearly is not actually self custodial. So unless I'm missing something Mutiny seems to be misrepresenting itself. However, if this issue is not just Mutiny but other wallets like Phoenix too that would be a major concern as I have more sats in Phoenix and am also under the assumption it's "self custodial". But if this is an illusion I will need to rethink my threat model.
reply
But if the LSP is able to sweep your funds then it clearly is not actually self custodial.
The reason the LSP was able to sweep funds was because what is essentially a bug in Mutiny lead to an invalid, revoked, transaction being signed and published by the Mutiny wallet. This can also be an attempt at fraud, intended to steal money from the LSP. So the Lightning protocol deals with this by allowing the LSP to sweep all the funds, discouraging attempts at fraud.
Harsh. But still self-custodial.
The solution here is to use better wallets that don't have bugs like this. IIUC Mutiny is particularly vulnerable due to bugs in the underlying web browser storage implementation, which can lead to state information not being recorded/modified correctly.
reply
But if the LSP is able to sweep your funds then it clearly is not actually self custodial.
This is how all lightning works, and is not specific to Mutiny, LDK, or any other lightning node software. If you run two copies of your lightning node, one is behind, and that one that is behind force-closes, you will lose your funds. Sadly iOS-PWA has a bug which has been causing that for Mutiny, but they've been working with their LSP to send users their funds back in that case.
reply
Not sure if this is an issue specifically for Mutiny. I think is more about LDK. Let's not forget that Mutiny is an "interface" for the LDK node under the hood.
If Phoenix app will have the same issue, it doesn't mean that is Phoenix app fault because the Acinq node behind is having issues.
Let's separate these things and treat them separately.
reply
That's point.
reply
Maybe you should pay attention to the beta warning. That should be in your threat model.
reply
Perfect. I'm building an app use LDK, I'm thinking remove and add other lightning implementations.
reply
other options are harder to uses by a mile...
reply
Why?
reply
Sadly there are only really three (and a half) options for integrating lightning into an existing application - (full) LDK, ldk-node, greenlight/breez, and (kinda) LND. Integrating LND into an existing application is a ton of work, and lots to maintain, so generally hasn't been something people do, or have stuck with long-term.
The full LDK interface is a lot of work, but very flexible in terms of how it gets integrated into an existing application, with customization for how/where you store your data, how you generate all key material, how/where you get blockchain data from, how/where you do signing operations, several different models of potential watchtower integration, etc, etc. This is great if you need some of that customization, but if not its a lot of work just to build the same thing everyone else has.
ldk-node is a standard node that does all the usual things to build a lightning node, packaged up with a super simple API (start node, open channel, pay money, list transactions) that handles storage and keys and blockchain sync for you. It works great on mobile, and has some flexibility, but is generally targeted at devs who just want something that just works.
greenlight/breez SDK are fairly similar to ldk-node in their API design, but unlike ldk-node they rely on hosting from greenlight/blockstream and integration with the breez LSP, rather than being able to choose your own.
reply
You can use your own LSP with the Breez SDK
reply
Ah, apologies, I didn't realize that.
Good points Matt. I'll rethink again. I still no removed LDK.
reply
If you're using either LDK option, please join our discord! We try very hard to help developers using LDK or ldk-node as much as possible, and appreciate hearing from developers what is going wrong or what they're struggling with. This allows us to improve the interfaces going forward, as well as help developers resolve issues quickly rather than struggling.
Does Phoenix use LDK?
reply
No, Phoenix is using Eclair implementation.
Eclair in French means lightning. Acinq - the dev team behind Eclair and Phoenix is a french team
reply
Ok. Thanks Darth that is reassuring I guess.
reply
Exactly
reply
This is a property of LN. I can go through LND and CLN GitHub issues and pull many instances of funds being revoked and swept by the other counterparty due to software bugs. This has nothing to do with LDK explicitly.
reply
Make sense
reply
This is a strange comment - both of the wallets linked are unreleased beta wallets, with bluewallet LDK support being quite a long ways from production, and has gone unmaintained for several years now. The issue you linked is also now a year old, and last I checked Bluewallet ldk was running an LDK version from several years ago (because its been unmaintained - they never shipped it and haven't removed the code). Bitkit is in beta, and both of the issues you link to the Bitkit folks have commented that they've fixed (without talking to us, I guess it wasn't an LDK bug).
Trying to suggest these issues are representative of production LDK use is more than a little insulting, not to mention the insinuation of theft. Cash App has used LDK in production for several years, powering a large volume of payments. While it wasn't always easy, its been very stable for a year or more (modulo lightning network hiccups, which come and go...).
Of course you shouldn't select a "beta" wallet as your daily driver, that's the point of "beta" :)
Indeed, its the case that some dev teams have taken some time to go from zero to production with LDK. This is an issue we've recognized and months ago we built ldk-node to address it - providing a super easy to use API which bundles everything for developers so they don't have to think about the super flexible, but somewhat complicated full LDK API. Sadly, none of the wallets mentioned here use it, in large part because it didn't exist when they started, but in some cases because they have different requirements.
The original issue in this thread with Mutiny appears to actually be an iOS-PWA issue, not an LDK one (though LDK did update to be a bit safer in the face of this bug recently), and not really a Mutiny one either (though one they'll have to fix, or maybe have by now). For some reason iOS allows PWAs to have two running copies at once, which of course causes lightning state machines to go haywire...not a lot we can do about that on the LDK end.
reply
None of those issues are fixed... not even after 1 year, the funds were never recovered.
Beta or non-beta, the issue is there, don't try to pass the dead cat into their garden.
That's why we test these beta version, to inform you about these issues.
You guys should talk more to each others and deliver better apps if you really want users to trust your software.
reply
The bitkit issue the devs believe has been addressed, at least per the final comment on the issue, I assume they're waiting on confirmation from the user before closing the issue. As I said above BlueWallet's LDK integration is fully unmaintained at this point. They haven't touched it in several years and never got it through a lot of testing. I'd believe it has bugs, it may even have bugs with the several year old version of LDK its using. But in either case its definitely not an example of how LDK performs :)
reply
All software have bugs, is understandable, especially in the early phase.
The only thing that I expect is that these kind of serious issues (losing funds) will get more PRIORITY.
As you saw, that issue is old from 1+ year ago and is still not fixed! After that last comment on github, where more back and forth emails with the support guy, that went nowhere. Funds are still lost or nobody knows where they go.
If LDK have some devs building some new apps, you should stay in touch all the time with them and see all these serious issues, trying to help them identify the problems.
Blaming them or the users using beta (for testing) is not the way...
reply
Software that is pre-release has very different priorities from software that is released. Indeed, released software with end-users putting lots of funds in these kinds of issues become high priority, but before its released, they may not always be, depending on what other issues developers are working on.
If LDK have some devs building some new apps, you should stay in touch all the time with them and see all these serious issues, trying to help them identify the problems.
We tend to! LDK in general provides very hands-on support for developers building LDK-based applications. Some developers take more or less advantage of that, but we generally don't have time to actively monitor github issues for all dependent projects. Instead, we let developers using LDK bring issues to us when they feel like it may be a bug in LDK or that LDK is doing something they don't understand. We are generally pretty responsive and get back to such requests within a day or so.
If LDK have some devs building some new apps, you should stay in touch all the time with them and see all these serious issues, trying to help them identify the problems.
I don't believe I ever blamed Mutiny, BlueWallet, or bitkit here. I only pointed out that looking at unmaintained multi-year-stale code (BlueWallet) and pre-release software (bitkit) is not a good indication of the maturity of LDK. None of that is blame, BlueWallet decided to go a different direction and never shipped their LDK logic, bitkit is working towards release but isn't there yet. There's nothing wrong with either of those.
I also noted that LDK can be hard to use, and that can cause issues by itself, that's on us, we don't ever blame any downstream developer for misunderstanding how LDK works, we try to improve the interface and documentation instead! But, LDK's interface is very powerful and low-level, which certainly requires a lot of work. This is why, mentioned above, we built ldk-node, to get developers from 0 to a running, safe, reliable lightning node in a week or less.
reply
There's nothing wrong with either of those.
Only that users testing them are losing funds and when are reporting these issues, the devs are trying to suppress their voice, ignore the github issues for months and not responding to support calls.
John Carvlaho called me crazy because I was trying to report the issue on their telegram group and on github: #155848
When in fact I was just trying to help identify the problem.
reply
Okay, I'm done arguing this, you can take it up with bitkit, but it sounds like you have and they told you to chill out and wait until they finish building before you complain about specific bugs. Maybe worth listening to them.
reply