Tl;rd: A plug & play Bitcoin full node is important, but I don’t have one ready. It’s too much for a side project, so I lay out my thoughts, previous tinkering and a possible architecture in case somebody wants to help or try to build it.

The importance to run my own full node became clear to me within my first year in the Bitcoin space. This is the reason I used old Laptops to run Bitcoin and Electrum nodes, and started building Lightning nodes using cheap hardware. My RaspiBolt guide became quite popular and like to think it had some positive impact in bootstrapping the Lightning network.

All this is for geeks, however. The ultimate goal is to have an easy to use appliance that just works.

Why run The Box?

Here’s why I think running The Box at home is important:

Don’t trust, verify : for Bitcoin transactions of a significant amount, it’s important to make sure you really have been paid by checking the validity of incoming transactions. This should not be outsourced to a third party.

: for Bitcoin transactions of a significant amount, it’s important to make sure you really have been paid by checking the validity of incoming transactions. This should not be outsourced to a third party. Don’t leak your bank statement : when using any wallet (web, mobile, hardware), the manufacturer knows exactly how much bitcoins you have and can monitor all your transactions. The only way to prevent that is to aks your own Bitcoin node about the current state of the blockchain.

: when using any wallet (web, mobile, hardware), the manufacturer knows exactly how much bitcoins you have and can monitor all your transactions. The only way to prevent that is to aks your own Bitcoin node about the current state of the blockchain. Be in control of consensus rules : in case of contentious forks or threats to Bitcoin, you only have a say if you have full control over what blockchain to follow.

: in case of contentious forks or threats to Bitcoin, you only have a say if you have full control over what blockchain to follow. Enable additional services : additional layers are built on top of Bitcoin. With Lightning for example, there is the need to constantly watch the blockchain, but also the opportunity to route transactions and earn fees.

: additional layers are built on top of Bitcoin. With Lightning for example, there is the need to constantly watch the blockchain, but also the opportunity to route transactions and earn fees. Additional security: eventually, hardware wallets / HSM could be part of The Box to provide additional security, eg. using multisig or acting as a 2nd factor to authorize payments.

Requirements

Current solutions do not provide a comprehensive solution for end users. In my opinion, these are the areas that need to be addressed:

Plug & play : after plugging it in, it is instantly ready for configuration and fully operational within minutes.

Needed: initial SPV-mode with background full sync until finished (like BIP157 / 158), on-device screen, setup wizard

: after plugging it in, it is instantly ready for configuration and fully operational within minutes. Needed: initial SPV-mode with background full sync until finished (like BIP157 / 158), on-device screen, setup wizard Convenient : the user must never touch a command line. He uses the device using a combination of on-device screen / buttons and web-interface. Following standards (Bitcoin, Lightning, Electrum) ensures interoperability with desktop and mobile applications.

Needed: solid UX, robust software architecture, upgrade process

: the user must never touch a command line. He uses the device using a combination of on-device screen / buttons and web-interface. Following standards (Bitcoin, Lightning, Electrum) ensures interoperability with desktop and mobile applications. Needed: solid UX, robust software architecture, upgrade process Secure : only one password + a 2nd factor is needed to manage everything. Internal communication security and certificates for outside access are hidden from the user.

Needed: Password / RPC derivation from master password

: only one password + a 2nd factor is needed to manage everything. Internal communication security and certificates for outside access are hidden from the user. Needed: Password / RPC derivation from master password Connected : the device is accessible from the internet in a secure way to allow connectivity from mobile wallets.

Technical: router port forwarding, Tor, dynamic DNS service, SSL certs, display QR connection code on screen

: the device is accessible from the internet in a secure way to allow connectivity from mobile wallets. Technical: router port forwarding, Tor, dynamic DNS service, SSL certs, display QR connection code on screen Trustless : the user does not need to trust the manufacturer as the hardware is based on standard components and the operating system / custom software is open source, free to be inspected by anyone. Special components (like hardware wallets) are optional and integrated transparently.

Needed: open-source, transparent architecture, reproducible setup

: the user does not need to trust the manufacturer as the hardware is based on standard components and the operating system / custom software is open source, free to be inspected by anyone. Special components (like hardware wallets) are optional and integrated transparently. Needed: open-source, transparent architecture, reproducible setup Affordable: th device does not need to be super-cheap, but should be less expensive than a general purpose computer like a cheap laptop. Could be great to sell in combination with hardware wallets.

Needed: usage of available hardware, standard components

I focus mainly on the low-level elements: hardware, operating system and application architecture. Web development and UX are outside my area of expertise and I am confident that there are capable people already working on solutions. The next step could be to align the low-level stuff with the UX to build a comprehensive solution.

Why I just put everything out there

I am posting all my findings because I find it very important that The Box gets built. I started down the Full Node rabbit-hole with my Raspberry Pi & Odroid guides and dove into many of the necessary components and technologies. Every aspect of this endeavour is so interesting, but also so extremely time-consuming for a non-expert like me. In the end, I can not put as much time as I think is needed into this without sacrificing other important aspects of my life.

There are promising projects like lightning.farm and great companies like Shift Cryptosecurity (maker of the Digital Bitbox) or Fulmo Lightning working on solutions, but I’d like to leave my ideas open to the community to maybe use in other projects as well. Most is probably common knowledge, but I could not find a place that combined all these specific ideas for this one goal.

Hardware

Everything started with the Raspberry Pi. It’s available everywhere, works reliably and has a lot of neat hardware addons. On the other hand, it’s already operating at it’s limit, even with the early-stage Lightning Network, additional services are not feasible. It’s also a mess without a case and two power adapters once an additional harddisk is needed. There are tons of use-cases, even for the tiny Raspberry Pi Zero.

There are many similar single-board computers available, and I researched them all: Orange Pi, Nano Pi, Odroid… and they are not really better. They may pack more RAM or CPU power, but at a higher price, less addons or other tradeoffs. A big drawback of all these platforms is the lack of USB3 support to attach an external hard drive. This is important to download and index the chain initially.

I kept getting back to the Hardkernel Odroid HC1, which is focused on high-performance NAS use-cases.

very affordable price: $49 + ~$10 for power adapter & case.

based on the powerful XU4: 8 core CPU, 2 GB RAM, Gigabit Ethernet

internal hard disk housing, direct connection using SATA3, the casing also allows for fan-less passive cooling

only one powerplug for everything. And a real one, not a flimsy USB plug. This is a detail but an absolute must in my opionion.

Ingenius, but there is stuff missing: no eMMC (available for XU4), no HDMI and no GPIO pins to drive buttons or a display. The missing eMMC is a pity, but not that critical. And what if the missing GPIO could be handled through USB?

Enter Adafruit (or Odroid, or stuff from AliExpress). Using the FT232H chip, the missing GPIO pins can be extended on USB: SPI pins for the display, digital inputs for buttons and other maker stuff… I tried the Adafruit variant and got a few LEDs blinking with Python very quickly. I did not succeed to drive the display at this point, but that should not be a real issue. Adafruit / Odroid are about $15, but there are also chips for $2 available.

Now that the basic platform is ready, we can build on it. The easiest way to extend the HC1 I could come up with is to stack a second layer on top.

From left: a real power adapter, spacers, the Odroid HC1, a few USB-to-GPIO boards (front), displays, rotary encoders and a wobbly cardboard extension board.

Necessary parts:

Extension board: easy to laser cut and even engrave from acrylic, for the prototype I just used cardboard (see schematics on GitHub, for print or laser cutting with Ponoko or Formulor)

Hex Spacer: using the official HC1 case, just drill six holes to attach the spacers and mount the extension board on top. ~$1

Display: the FT232H can drive any SPI or I2C display. I like the OLED displays that are available for ~$2 - $10, depending on size.

Rotary Encoder with push button: instead of multiple buttons, I like the turn & push way to navigate, which minimizes assembly. ~$1

The possible result? Something like this, potentially with a nice engraved logo instead of my kindergarden drawing skills:

If in the future a solution could be build with a pruned Full Node that no longer requires a harddisk, the Odroid XU4 with eMMC and full GPIO support would be a great choice, running without the FT232H extension board.

Operating system

Based on the assumption that the whole Box is trustless, just shipping a binary image with all software preinstalled is not feasible. The build process needs to be reproducible and mostly automated. Starting with Linux base, it would be great to have an automated setup and the possibility to execute a script at the end that sets up everything in a transparent manner:

Download standard Linux image Make a few easy adjustments to the sdcard Boot up for automated install, that then automated download of the Github repo, setup specific software and starting the user interfaces.

This is possible with DietPi: based on Debian, very lightweight, open-source, available for many platforms, automated setup incl. running a custom script at the end. I created a prototype that works quite reliably.

I don’t see hard challenges in this area, as the script can configure the whole system and set up all necessary services. The only caveat in combination with the Odroid HC1 is that it really needs to work 100%, as there is no display for debugging in the beginning.

Software Architecture

Setting up the application software for smooth interoperability between modules without creating undefined states due to other changes, eg. in the operating system or during updates, is a prime use-case for Docker. It’s harder to engineer initially, and it adds some overhead, but it provides a completely transparent build process and forces strict modularity and clean interfaces. On every start, the modules start in a clearly defined state, no legacy configuration can accumulate over time.

Together with Docker Compose, the modules can be built and started together. There are a lot of great templates out there, but I could not find any that work well together and work also on other devices than Raspberry Pis. In the raspibolt-setup repository I started setting up the necessary Dockerfiles for the first modules. In the end, I could imagine the modules like this:

Core OS configuration

as minimal as possible, no Dockerfile, handled by setup script User interface

run web-interface with webserver for Lightning interface and node configuration, plus scripts for on-device screen interaction Bitcoin Core node

Full non-pruning Bitcoind node with transaction indexing, communicates via RPC to other modules, no special configuration necessary Lightning node

Bitcoin Lightning node, probably LND, handling on- and offchain funds, managed via web-interface and mobile apps, monitoring the blockchain using the Bitcoin Core node ElectrumX node

Providing full blockchain information on demand for Electrum desktop wallet (supporting most hardware wallets) or other solutions like the Bitbox hardware wallet with private backend option. Advantage to the “Electrum Personal Server”: no configuration regarding xpub-keys necessary and contributing to the Electrum network.

Additional services could be integrated without affecting existing modules. The only “secret” necessary for communication with the Bicoin Core server would be the (internal) RPCAUTH password.

Various thoughs

It would be interesting to sell all addon-components including the extension board as a kit, without harddisk and Odroid HC1.

Tor support is helpful for privacy, but also to avoid port forwarding & dyndns issues, and is already on the Roadmap for the Shango wallet. Wireguard is another possibility to punch through firewalls.

Merchant support: in combination with Zap PoS & Zap Commerce, this solution could provide a great cornerstone of merchant integration.

In closing

I would love to see my ideas & findings getting used in a Bitcoin full node project and will continue to work on stuff I like and find interesting. If something like this takes form I’d happily contribute.

h/t to Damian Mee for feedback.