A Technical Guide With Commentary

Preamble

Ahhh, that feeling when a lightning payment goes through. Especially cool when it's done using a self hosted web wallet!

I recently followed Mutiny's self hosting instructions that they published, and this writeup contains some notes that might be useful to anyone else wanting to try this out.

Why Mutiny some may ask? A full comparison of self-hosted lightning wallets is beyond the scope of this article. Suffice it to say that I like playing with new tech and I'm a Bitcoin and web tech junkie 😁 See the Appendix for additional meta.

Part 1: Installation

I started off by following the official installation instructions. I ran into a couple of snags but the Mutiny team quickly merged my feedback into the instructions.

Things seem to work pretty well on a 1GB/1CPU server, so I'd suggest going with those specs to start with.

Part 2: Running Mutiny

At this point I was able to:

1. Deposit sats
2. Open a channel
3. Paying an invoice failed - unable to find route :(

So I left it overnight and attempted paying the invoice again in the morning - it worked! I used Mutiny to pay a HODL invoice on RoboSats 💪

I was now fully up and running with Mutiny. However I didn't want random vulnerability scanners finding my server, so I looked at options to lock down access. The simple options for this are basically:

1. IP whitelisting
2. Basic auth
3. Hosting on a hidden (very random) path

Neither 1 nor 2 are ideal because I want to access my wallet from anywhere, and basic auth is annoying AF. So you should go for option 3. Instructions here:

https://github.com/MutinyWallet/mutiny-deploy/blob/master/docs/hidden-site.md

Be sure to make sure there is lots of entropy in your hidden path using something like pwgen or uuidgen.

Another criteria that is important to me in terms of "accessing my wallet from anywhere", is accessing my wallet from different devices i.e. different browser tabs on different machines. Mutiny currently supports this! The only caveat is don't use the tabs within 2 minutes of each other, but the wallet warns you if you try to do this so you're good. Mutiny are aware of one issue around multiple-tab access so I'll be keeping an eye open for that.

Part 3: Maintenance

The next day I needed to reboot my server and ran into a world of pain. After rebooting the server, hitting the URL resulted in 502 Bad Gateway which basically means the upstream web server used by nginx-in-reverse-proxy-mode is not reachable. So I ran docker ps and noticed only two containers were running (vss and proxy).

Taking a look at Mutiny's docker-compose.yml, I noticed that all the services were set to restart: on-failure however when rebooting using sudo reboot, the containers will exit 0 and therefore won't restart. So I changed this to restart: unless-stopped and rebooted. This time all services were running and I was able to access my wallet! This still leaves the curious question of why vss and proxy were running after the first reboot, but I assume that they aren't shutting down cleanly or something and actually did exit with nonzero codes.

Part 4: The Future

This was a wildly successful experiment for me compared to some other Bitcoin tech I've tried out, so hats off to the Mutiny team. Next steps I want to get to at some point:

1. It currently takes about 30 seconds to pay an invoice. I need to see if I can bring that time down.
2. Open another 1 or 2 public channels for better privacy.
3. Bundle into a StartOS app once they support multiple docker containers per app.
4. Ask the Mutiny team for "Uncle Jim" mode.

Appendix: Why I Did This

One of the main reasons that I'm so interested in Bitcoin is that it has the potential to usher in a new era of world peace ⁴. In order for Bitcoin to win, however, it needs to become widely accepted as money. In order for it to be a successful money, we need scaling solutions. Anyone arguing against this is not being pragmatic. I regularly spend as little as $1 at a merchant, however spending $1 of on-chain BTC in a high fee environment is not sustaineable. Not to mention confirmation time issues, refund issues, etc. Hence lightning.

So that's why I'm really into Bitcoin and Lightning.

It's important to take Bitcoin privacy seriously though. Unlike your credit card, all base layer Bitcoin transactions are public, so it's quite easy to botch your opsec. I feel like I have a pretty good grip on on-chain privacy. Lightning privacy is, however, far more complicated. The best post I've ever read on the topic was Tony's "Current State of Lightning Network Privacy". After reading that, my Lightning setup looked like this:

This might seem like overkill, but I had some other reasons for hosting my own routing node besides privacy:

1. I wanted to learn how to do it
2. I was under the impression that it would support the network
3. I thought it would grant me a larger anonset than, say, using Phoenix or Blixt.

Given the recent shenanigans around lightning replacement cycling attacks, I decided to revisit my motivations for running a node.

1. I wanted to learn how to do it: certainly did ✅
2. I was under the impression that it would support the network: I've since come to learn that Lightning doesn't need small amateur node operators to survive ✅
3. I thought it would grant me a larger anonset. I kind of do still think this, but unfortunately I don't have the time at the moment to figure this out from first principles ❌

Anyway, after a brief chat with Tony on Stacker News, I decided to take the plunge and switch to Mutiny's self hosted version. If things are looking good after a week of soak testing, I'll be decommissioning my routing node.

Originally published on shyfire's weblog