pull down to refresh

I've been running a self-sovereign Bitcoin setup on Raspberry Pi hardware for about 6 months now. When I started, I couldn't find any guides for running a Bitcoin full node and a mining cluster on the same Pi 5 with a ClusterHAT — most guides cover one or the other, not both at once. I wasn't even sure it would work. I just had the hardware sitting around and wanted to do a test drive to see what a Pi 5 and a few Zeros could actually handle. Turns out, quite a lot.

The hardware:

One Raspberry Pi 5 (2GB) with an NVMe SSD running Bitcoin Core 27.0.0 pruned, Tor-only, accepting inbound connections. The same Pi 5 also acts as the controller for a ClusterHAT with 4 Pi Zero 2 W boards plugged in via USB. All 5 devices mine crypto simultaneously while the Pi 5 runs the full node.

Total power draw for the entire setup: about 15-20 watts. Runs 24/7 on my desk.

What's running:

The Pi 5 handles a lot. It runs the following: Bitcoin Core (pruned, Tor-only), crypto mining, ClusterHAT bridge networking for the 4 Zeros, dnsmasq for local DNS caching, hourly automated snapshots, and systemd timers for hourly reboots. The Zeros each run their own mining instance.

I started with Duino-Coin to learn the basics of cluster mining, then preserved my XMRig/MoneroOcean configs for Monero, and I'm currently running Bitcoin lottery mining through public-pool.io just for fun.

How I built it:

I'm not a programmer by trade, and there were no existing guides for this specific combo of hardware and software. I used AI (Claude) to help me write the systemd services, bash scripts, snapshot automation, and debug issues as they came up. I'd describe the problem or paste terminal output, and it would generate the commands and configs. I still made edits and decisions along the way. Those were choosing CBRIDGE over CNAT, picking which coins to mine, deciding on the network architecture, and troubleshooting hardware issues hands-on. The AI handled the scripting, I handled the hardware and the judgment calls. Between the two of us, we figured it out without a guide.

The problems nobody warns you about:

CBRIDGE networking on the ClusterHAT is fragile at boot. The Pi 5 would get a DHCP lease, start mining before DNS was ready, and the miner would crash. I spent weeks debugging DNS resolution failures that only happened after reboots. The fix was a combination of a local dnsmasq cache, an ExecStartPre DNS wait loop in the systemd service, and switching from a 4-hour to 1-hour reboot cycle to match the DHCP lease time.

One of my Zeros (p3) got soft bricked during an apt upgrade when the hourly reboot timer fired mid-kernel-update. The initramfs was only 80KB instead of 12MB. I fixed it by mounting the SD card on my laptop, chrooting in, and rebuilding the initramfs manually. That saved me from a full reflash.

The Bitcoin node had its own issues. The daemon=1 setting in bitcoin.conf conflicts with systemd's process management, and stale lock files after unclean shutdowns prevented bitcoind from starting. Once I cleaned those up and removed daemon=1, it's been rock solid and fully synced, 10+ Tor peers, accepting inbound connections.

What I'd do differently:

Set static IPs or DHCP reservations from day one. The ClusterHAT Zeros get new IPs after every reboot, which makes SSH scripts break constantly. Also, test your reboot timers against your apt upgrade schedule by never letting them overlap.

The setup today:

My node is live and discoverable on the Bitcoin network:

Onion: 27wd756hjrgqwoghcnyihpnelqm25z7k2uhneytzlxlhtvotbffdzvad.onion:8333

If you connect to my node, you'll see the donation address right in the user agent string. If this post was useful or you want to support a small Tor node, sats are appreciated:

BTC = bc1pylktvecsxya9n3s7aamfa76z4s3jwxx0v24nmdalk67yrgpvhf7q3qs3et