2410 sats \ 12 replies \ @bluematt 2 Nov 2023 freebie \ on: Mutiny wallet - questions to be answered bitcoin
Broadly, I want to highlight that while some of the comments here have focused on "why not just run a full node on your RPi at home", that's simply not realistic for normies. Unless we want ~everyone to be stuck using custodial providers, things like Mutiny are absolutely critical to getting people onto Bitcoin/Lightning. Mutiny is still super new, and there's been some hiccups, but the rate they've been shipping has been impressive and they've definitely fixed a boatload of issues over the past month or two.
I want to respond a bit to this, because this implies that there's some general node compatibility issues here, but that's not really the case. These days we don't really see any issues between LDK and CLN or LDK and LND regarding general compatibility issues.
Mutiny has suffered from several force-close issues, sadly, but I understand they've made good progress on several of them (including contributing upstream to LDK the API tweaks they required to have the flexibility they needed for their improvements!)
a) Until recently LDK did not fully support anchor channels, CLN, which Mutiny's LSP currently uses, only supports anchor channels as a development feature, and Mutiny has not yet had the bandwidth to integrate anchor channels. Without anchor channels, lightning nodes to have to enforce the feerates on the channel as within a range that their feerate estimator gives them, as otherwise the channel is not enforceable on-chain. LDK is relatively strict about this, other lightning nodes have loosened their enforcement here to avoid force-closes and instead risk on-chain enforcement can fail. Of course anchor channels addresses this, but in the mean time Mutiny has contributed upstream to LDK to give more flexibility to users to let them loosen the enforcement, which I understand Mutiny now has.
b) Mutiny doesn't generally have the users' private key online, and many users receive HTLCs which are set to expire soon and then they close the site and don't reopen it for a week. Sadly, at this point on startup the channel has timed out and we have an HTLC which the lightning protocol mandates we go to chain to enforce. We've chatted a bit with Mutiny about how we might go about working around the Lightning protocol's requirements, and I'm quite confident we'll figure things out, with better initial sync steps in LDK and Mutiny, and looking towards the future with things like async payments.
c) Mutiny has been taking advantage of a beta feature in LDK where storage is asynchronous, as well as built a lot of infrastructure around supporting the same wallet/node running on several different machines at the same time. This is an impressive bit of engineering, but still has some kinks we're working out.
This is a very disingenuous response (as seems to be typical).
The context about remote nodes is explicitly that mutiny is still a cloud service. If users aren't running the full stack it is effectively custodial regardless of which device the processes run on. Normies incapable of self hosting code would be better running code hosted by Uncle Jim vs. Fragile Tony.
This model is extremely centralizing, high trust, and still very far away from solving the problems that make mobile nodes utter nonsense.
reply
Not quite sure why you feel the need to start with insults, that seems unnecessary.
I think you're mostly referring to the auto-update problem, which, indeed, is an issue for all mobile nodes - both a PWA, which auto-updates by website load, but also the OS auto-updates apps, and in both cases there's little validation a user can do to check that they're running the open source software they expect.
This is something that is an inherit limitation in the platform, sadly. Even if you're using Uncle Jim's node hosting service, whatever you're using to remote control it on your phone still has the same problem - it can intercept your API calls and steal your money.
That said, "self-hosting" Mutiny is...trivial, unlike Uncle Jim's node hosting service. All you have to do is unzip the source into a web server. Now you have a fully self-hosted copy of Mutiny that you can use that Tony can't auto-update out from under you. Until mobile platforms provide something better, that's arguably the most trustworthy model of any mobile node.
reply
Not quite sure why you feel the need to start with insults, that seems unnecessary.
Where?
That said, "self-hosting" Mutiny is...trivial, unlike Uncle Jim's node hosting service.
That's nonsense. The web-server itself (ip4 ssl and so on), plus the reverse proxy required by Mutiny, is the bulk of the lift. Running the node daemon beyond that is also a "trivial" unpack.
Packaging options for Uncle Jim does in general leave much to be desired, which is my point, and that's why I'm working on and advocating for that vs. this Quixotic mobile fiasco.
Until mobile platforms provide something better
Exactly why it's best to have the node off-phone so that the mobile only has access to nerfed account keys, not the whole private key that can be swept without a trace.
reply
"as seems to be typical" and "Fragile Tony" are both rather insulting comments.
Its worth noting that the reverse proxy used by mutiny is not trusted. You can use anyone running it without worrying they can take your money or see what you're doing (only when you're doing it, which can correlate). There are a number of things Mutiny connects to server-wise, but the only trusted piece is just the download of the code which gets run locally. that can be put on any web server (which, come on, isn't all that much work to host, you can even do it via a standard hosting provider).
reply
Fragile Tony already has anyone outside his echo chamber muted (hense the name) so that's irrelevant...
I'd consider concession on the former, but here again you're doing it: I didn't say the reverse proxy was trusted.
The topic was self-host complexity, and the reverse proxy would need the same process hosting capabilities as a node.
reply
deleted by author
reply
maybe TheBlueMatt got his LDK node fucked due to a bug 😂😂😂
reply
Nah, my (lazy, just running the sample code) LDK node is quite reliable :p
reply
No idea! Its not in my password manager so I just kinda assumed I didn't have an account. Presumably I logged in via a shared service for that account (which I generally avoid, but didn't for some reason), and then forgot about it :).
reply
Actually, I don't think that's my account? Twitter login isn't there and I don't see any posts from that account I recognize.
reply
Presumably I logged in via a shared service
This just sad, coming from the main dev of LDK....
reply
Nope, turns out I did not, its definitely not my account (I definitely didn't join by posting an announcement of the fact that I joined lol).
reply