In the previous post we’ve built a pruned bitcoin full node running on an old Android phone. Quite some people seemed to be interested in this (thank you for your encouragement!) and so I’ve decided to keep on experimenting in this direction and pass on my learnings.
Things I’ve learned since the last post
The first thing that might need clarification is that all that stuff we’re running does actually run on the Linux that is built into the phone. Termux is really just a terminal emulator that lets us access this native Linux — but a brilliant one at that. However, the binaries for bitcoind, LND and EPS wouldn’t work directly in Termux (mostly because of a different path layout), and so I’m running them inside a pseudo-root Ubuntu environment. More about this later on.
Secondly, I learned that you should really turn off auto-updates in google play, since this kills Termux (and all the processes running there) whenever it updates the package.
Thirdly, the limitation that kept me from running a Lightning client before was that the internal flash storage only held 16GB. This isn’t just impractical for running a Lightning client (because up to now, these only work with channels where they can inspect the funding transcation — so ideally, a pruned node should have all the blocks until back when Lightning started on mainnet — early 2018), but our server also writes to disk a lot (about 10-20 GB/day — iostat is your friend), which in the long term might wreck that internal eMMC.
Micro SD cards — a modern miracle
I researched a lot about micro SD cards, and it turns out that in practice they mostly do last longer than the 250-600 write cycles that they promise. And that might be good enough for you, especially given that you could just replace them when they do give in eventually (or the blockchain gets bigger than the 400GB you bought). So you might just go for that unpruned node.
However, there are also so called High Endurance cards from all major manufacturers which cost about double from the cheapest available micro SD cards, but last up to 25 times as many write cycles. Samsung Pro Endurance promises the best values here (and the tech there seems to be 3D MLC which should last considerably longer than 3D NAND), but costs again twice as much as the competitors here in Europe (but not in the US) ATM. Sandisk High Endurance cards have actually been tried by someone in a RaspBerry Pi forum (can’t find the link right now, but they gave up trying to break it after successfully writing 70TB to a 32GB card IIRC). Kingston ones are the cheapest but I couldn’t find any decent stats on them. I went for the Transcend 350V 128GB, which promises 170TBW. That’s about 10000 days of bitcoind and LND at current levels, which is about 30 years — good enough for me. Granted, it set me back about 35 Euro, so I can’t claim my node came for free anymore. Bummer. Still the cheapest in the world, I think. Plus, I absolutely expect SD card prices to fall way faster than the blockchain grows.
Let’s get this micro marvel working
Once you got the micro SD card, shut down bitcoind and Termux (yeah, I know it sucks), insert the card, restart Termux (and sshd) and do
This should set up everything that’s necessary to get a nice symlink in your home directory:
or similar. If you’re on Android 6 or newer you might have to explicitly allow Termux the access.
Unfortunately, there is currently no way to quickly unprune a bitcoind (IMHO it shouldn’t be so hard). So I ended up re-pruning a copy (!) of an unpruned full node on my laptop again (prune=110000) and copying the blocks and chainstate directories to the card — into
If you have EPS, don’t forget to also resync that and copy wallet.dat over. Then set symlinks in .bitcoin with
ln -s /storage/sdcard1/Android/data/com.termux/files/chainstate .
ln -s /storage/sdcard1/Android/data/com.termux/files/blocks .
Now before you restart bitcoind don’t forget to edit bitcoin.conf (or it’ll reprune everything again!). It should look like this:
The zmq stuff already hints at LND, which is up next. But before that, make sure everything is running smoothly by restarting
and in ubuntu:
Finally, we get to deploy one of these infamous, centralized, global player banks — a Lightning Network hub! Eclair doesn’t seem to support pruned nodes and the server version would probably need a little more RAM than the alternatives anyway. I guess cLightning would have the smallest fingerprint, but AFAIK only LND implements static channel backups — a key feature that allows us to rescue funds in a channel, were our high availability hardware ever to fail. So LND it is; and again, our ubuntu-in-a-proot-jail allows us to simply download and verify the binary release. Then
tar xzvf lnd-linux-armv7-v0.6.1-beta.tar.gz
ln -s /storage/sdcard1/Android/data/com.termux/files/.lnd .
lnd-linux-armv7-v0.6.1-beta/lnd --bitcoin.active --bitcoin.mainnet --bitcoin.node=bitcoind --tor.active --tor.v3 --listen=localhost --tor.streamisolation &
Copy the seed somewhere safe and wait for lnd to sync. Voila! It’s that simple!
Alex Bosworth gave us an elegant minimal backup solution: copy the channel.backup to the internal storage whenever it changes. Others have made more elaborate schemes including google drive, scp and many more. (Update: This step isn’t necessary anymore when you use RTL (see below). The latest version includes automatic channel backups)
A little more comfort
This is a good enough setup for CLI enthusiasts. But Ride-the-Lightning (RTL) is a nice web frontend for managing our node that can be easily added for extra comfort. Just (in Termux)
pkg install nodejs-lts
and follow the installation instructions over at RTL. I did get error messages (probably because of the node-sass dependency) during the installation, but it worked all the same.
And there you have it. A routing always-on full-node-backed Lightning node with backups and a web frontend, all for the price of a micro SD card (and an old broken phone).
Of course, this is still a kind of experimental setup. It works for me, and it can work for you, if you aren’t afraid of the command line. But there is room for improvement:
First, I’m not fully satisfied with the proot approach. It’s easiest for experimentation, but not only does it make the installation process more complex, it also has a performance cost. And with all my current setup, I have a system load of 6–9 at all times (on a 4-thread cpu). I’d really like to find out how much this can be improved by compiling proper termux binaries. It appears esotericnonsense has done work on compiling bitcoin-core in Termux years ago. So I guess it should be do-able. LND should be even easier, since it’s in go. Same thing with EPS in python.
Once this is done, running everything in a nice, simple service system like runit should be much more convenient and scalable in the long run than my manual tmux approach.
And then it doesn’t seem far-fetched to arrive at a simple script that automates the entire process. I’m not sure if making it even more one-clickable makes much sense, since this remains a server, and working on the unix command line remains the best way to work with servers that I know of.
I hope you could use some of my experiences and let me know some of yours!
stefan June 18, 2019
Posted In: Code