Mutiny wallet - questions to be answered \ stacker news ~bitcoin

pull down to refresh

Mutiny wallet - questions to be answered

15k sats \ 43 comments \ @DarthCoin 2 Nov 2023 bitcoin

zaps forwarded to @benthecarman (50%) @TonyGiorgio (50%)

Few weeks ago I start testing Mutiny wallet. I had some of my readers asking me about this wallet so I decided to test it for them.

I know is still in beta and there's a long way until will be a mature app. But I gave it a try.

I like this idea of running a LN node in a browser. It can have many use cases.
is a simple UI and quite friendly for a new LN user that have no idea how LN works.
LDK still have some issues with opening channels with other implementations and you can get force closing channels if you do not use so often your Mutiny node. But I understand this that is not Mutiny team fault entirely and is fixable.
works pretty well, no big issues as I expected for a beta version.

Disclaimer As I always do, with all kind of wallet apps, I test from a normal user perspective. I play the role of a normal guy, that get into Bitcoin right now, and have little knowledge about how these things works. After that I go deep and learn more about the app/solution with more technical details.

So I have some questions for @TonyGiorgio and @benthecarman if they please to answer them. So please consider these questions like

When you will have a proper FAQ page with more details for regular users?
The fact that right now it can be run only on a hosted 3rd party domain (mutinywallet.com) it doesn't make it so "non-custodial" wallet/node. If the domain goes bust, also users can't access anymore their wallets. Yes, the 12 words seed of LDK could be imported in Electrum (I test it) but usually the funds are in LN channels and those cannot be recovered in any other LN implementation. I tested also to use Bluewallet LDK (as disaster recovery) and it doesn't work.

So, as a regular user that have no idea how to build from github source the LDK node and the web frontend, the user could be stuck. (I could say same way as using WoS and it goes bust).

How do you mitigate this aspect? Is not a yet released option?

On the website you mention "Self-hostable. No need to trust us. Host your own copy of Mutiny Wallet for ultimate self-sovereignty." But there are no instructions how to do it.

Let's say the user can't access anymore the domain mutinywallet.com . Shit can happen, is understandable. Is there a procedure that user can initiate to close the existing channels and recover his funds onchain ? Do you provide assistance / help for these cases ? Can you provide some kind of chaintools offline (without running a LDK node) where the user can trigger an automated force close and recover his funds?

view all related items

2410 sats \ 12 replies \ @bluematt 2 Nov 2023 freebie

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.

LDK still have some issues with opening channels with other implementations and you can get force closing channels if you do not use so often your Mutiny node. But I understand this that is not Mutiny team fault entirely and is fixable.

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.

100 sats \ 4 replies \ @0330830bf9 6 Nov 2023

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.

0 sats \ 3 replies \ @bluematt 8 Nov 2023

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.

100 sats \ 2 replies \ @0330830bf9 8 Nov 2023 freebie

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.

0 sats \ 1 reply \ @bluematt 8 Nov 2023

"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).

271 sats \ 0 replies \ @0330830bf9 8 Nov 2023

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.

0 sats \ 6 replies \ @nemo 3 Nov 2023

deleted by author

21 sats \ 1 reply \ @DarthCoin OP 3 Nov 2023

maybe TheBlueMatt got his LDK node fucked due to a bug 😂😂😂

21 sats \ 0 replies \ @bluematt 3 Nov 2023

Nah, my (lazy, just running the sample code) LDK node is quite reliable :p

0 sats \ 3 replies \ @bluematt 3 Nov 2023

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 :).

22 sats \ 0 replies \ @bluematt 3 Nov 2023

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.

0 sats \ 1 reply \ @DarthCoin OP 3 Nov 2023

Presumably I logged in via a shared service

This just sad, coming from the main dev of LDK....

22 sats \ 0 replies \ @bluematt 3 Nov 2023

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).

931 sats \ 0 replies \ @TonyGiorgio fwd 2 Nov 2023

FAQ: https://github.com/MutinyWallet/mutiny-web/wiki/Mutiny-Beta-Readme

Self hosting guide: https://blog.mutinywallet.com/self-hosting-mutiny/

Recovery tool: https://github.com/MutinyWallet/mutiny-data-recovery

Things are in a lot of different places but it's all there. Documentation PRs welcomed.

468 sats \ 9 replies \ @0330830bf9 2 Nov 2023

"Self-hostable", sure, great... but if I was going to go through the hassle of setting up my own server for it, why wouldn't I just run a proper remote node to Zeus etc?

The other thing that's very wtf is the reverse proxy. Communication with the network can't be done from a browser context directly and so all traffic has to get routed through their servers over sockets. This creates metadata honeypot that is a disaster for privacy, it's also single point of failure that will be extremely difficult to scale.

This architecture also just doubles down on all the hacky crap that comes with other mobile node wallets that no one is happy with... "muh async payments!", "muh static offers!"

I love to see PWA efforts because obviously fuck app stores, but this is just another example of how bad the state of Lightning wallets is if people pay it any mind. It makes no sense.

"So preoccupied with whether or not they could, they didn't stop to think if they should."

Unless of course the entire point of it was to wash "grant" money through astroturf and make the LDK ecosystem appear to have any relevance?

0 sats \ 7 replies \ @benthecarman fwd 2 Nov 2023

You're not wrong if you're self hosting the website you could just self host a node. A node is more expensive to run than a website but I do see your point.

We don't get much information from the proxy, all of lightning communication is encrypted and authenticated so we only see who is connected to who and for us it's just users to the LSP.

Mobile lightning still has a lot of ways to go but we think we'll be able to make it 100x better than the lnd on the phone guys. We should be able to run the lightning node in the background and it let it claim payments. All in due time.

0 sats \ 6 replies \ @0330830bf9 2 Nov 2023

That's all well and fair, but even then, what are the advantages vs. cloud nodes with a leaner remote signing wallet?

1493 sats \ 1 reply \ @moneyball 5 Nov 2023

It isn't really leaner. For it to be secure and non-custodial, it requires running a LN state machine on the device (eg VLS). So, for a single node and user, they must run two LN state machines. This increases complexity dramatically.

And, while it might sound simpler on the surface, it does not actually solve the big challenges of mobile non-custodial LN wallets. Offline receive is not solved by this. Multi-app interfaces are not solved by this. Backups are not uniqued solved this. In fact backups are more complex because you have 4 copies of the LN state instead of 2! You have the VLS local copy, the VLS cloud copy, the CLN/Greenlight copy, and the CLN/Greenlight cloud copy.

The only real benefit to the Greenlight model is to bundle up all the various server-based services that are needed for a LN wallet into a single provider, improving dev UX. However, that can be done with the LDK ecosystem too, it just hasn't yet (eg LSP, Esplora, VSS/backups, RGS, probing for payment success). Also, a single provider from either ecosystem weakens security and self-custody nature, as LN state backups ideally are not provided by the LSP.

Also, because the LDK ecosystem supports pathfinding on mobile (made performant with RGS and probing/scoring files), an LDK-based wallet has dramatically better privacy than having every single user payment sitting on Blockstream's servers.

0 sats \ 0 replies \ @0330830bf9 6 Nov 2023

This confirms then what we knew, self-hosted or at worse uncle Jim hosted, is the most decentralized path forward and these self-custodial in name only mobile nodes still make no sense.

0 sats \ 3 replies \ @benthecarman fwd 2 Nov 2023

You're talking about greenlight, which imo is custodial. Unless you're saving every state update locally, then you're trusting everything to the cloud provider. Almost all the complexity with lightning is making sure you have the latest state, so if you're going through the trouble of saving everything on the phone, may as well run it on the phone too

197 sats \ 2 replies \ @0330830bf9 2 Nov 2023

That's a conflation of trust and custody. Users are trusting you to serve non-malicious code to the device, that's really no different than trusting the greenlight to do the same to their own device, since both are impractical to self-host.

Also isn't LDK's pushing vss state storage as a feature? I thought I had seen somewhere that you were using that / planning to?

1 sat \ 1 reply \ @benthecarman fwd 2 Nov 2023

With mutiny if we disappear, the user can recover their funds, with greenlight you cannot, that is the main difference.

We are using VSS but that is for encrypted backups, we always write to the user's device first

237 sats \ 0 replies \ @0330830bf9 2 Nov 2023

That would not surprise me and I am no defender of Blockstream, but I doubt that's true or will be for long as it's a relatively trivial matter to provide some recovery options.

Good luck in either case. The state of wallets is shit and needs improvement.

20 sats \ 0 replies \ @deletedd 2 Nov 2023

deleted by author

40 sats \ 4 replies \ @DarthCoin OP 2 Nov 2023

How do I open a channel with a specific peer (not voltage) if I cannot deposit onchain to Mutiny? The only way to receive in Mutiny is through opening a LSP channel over LN.

This could be very useful for a total noob, but once he start learning about other peers, still do not have this option. You mention in the blog the "admin page" option, but there it says clearly "open a channel with a peer using your onchain balance".

So how do i get some onchain balance without closing a LSP channel? Is this a feature to come later?

0 sats \ 2 replies \ @benthecarman fwd 2 Nov 2023

You can receive on chain to mutiny

0 sats \ 1 reply \ @DarthCoin OP 2 Nov 2023

OK but that is opening automatically a new channel with LSP. I do not want that, I want to receive onchain and then open a channel manually with a peer that I want to.

1 sat \ 0 replies \ @benthecarman fwd 2 Nov 2023

If you receive on chain it doesn't automatically open a channel.

You can open channels to anyone in the admin settings

0 sats \ 0 replies \ @TonyGiorgio fwd 2 Nov 2023

How do you open a channel without funds? Is that your question? You can't. Have someone open to you.

1 sat \ 1 reply \ @DarthCoin OP 2 Nov 2023

@TonyGiorgio I think you should add Mutiny wallet on NVK's page of https://walletsrecovery.org/ Is a good resource for all kind of wallets.

231 sats \ 0 replies \ @benthecarman fwd 2 Nov 2023

https://github.com/nvk/walletsrecovery.org/pull/207

0 sats \ 4 replies \ @BitByBit21 2 Nov 2023

I would also like to connect to my own node as well. Is it possible or is this planned in the future?

0 sats \ 3 replies \ @DarthCoin OP 2 Nov 2023

The idea of Mutiny is to be itself a LDK node, you hosted on your own hardware / domain or use the default from mutinywallet.com. LDK have its own incorporated node.

If you refer top "connect to my node" means opening a channel with your own LN node, then yes, that is possible to add it as peer, but as i said, right now I do not see where to deposit sats in onchain wallet in order to open that channels towards my own node.

Same case was with Bluewallet LDK that I tested and opened a channel from a separate onchain wallet. But that end up in another issue (see here)

0 sats \ 1 reply \ @BitByBit21 2 Nov 2023

I was wondering rather if I can connect to my LND node too, just like with my Zeus wallet.

10 sats \ 0 replies \ @TonyGiorgio fwd 2 Nov 2023

No, just use Zeus for that it's great. We wouldn't want to make something that already exists well enough.

0 sats \ 0 replies \ @shyfire 2 Nov 2023

You can get an on-chain address to receive to by going through the receive workflow and then changing the format to "on-chain" on the last step.

0 sats \ 0 replies \ @shyfire 2 Nov 2023

I'm self hosting on my own domain for $5/month

p.s. Great commentary, nice post!

0 sats \ 1 reply \ @Bullen 2 Nov 2023

I feel stupid today.

I am concerned about this being a hot wallet, in my browser. And woah nelly, that's like hot hot.

What'd be the most tin foil hat way to create a wallet?

21 sats \ 0 replies \ @DarthCoin OP 2 Nov 2023

A LN wallet will ALWAYS be a hot wallet. And is nothing wrong with that. A LN wallet is supposed to be a spending wallet, not a holding wallet. I do not see any problem in Mutiny case.

Always have in mind this 3 levels strategy of using Bitcoin: HODL, cache, LN (spending)

https://i.postimg.cc/MTL2kvT0/3level-stash.jpg

10 sats \ 3 replies \ @deletedd 2 Nov 2023

deleted by author

0 sats \ 2 replies \ @DarthCoin OP 2 Nov 2023

True, you can download, as apk but you still depend on Mutiny servers, am I right?

0 sats \ 1 reply \ @deletedd 2 Nov 2023

deleted by author

0 sats \ 0 replies \ @DarthCoin OP 2 Nov 2023

No is not different. Is even better than Phoenix because you can manage your own channels/peers.

I am just thinking of disasters scenarios and how to mitigate them using Mutiny.