Bitcoin Core

Bitcoin Core the most popular software implementation of Bitcoin, openly developed on GitHub (https://github.com/bitcoin/bitcoin) and publishing releases on https://bitcoincore.org. The BitBoxBase uses the latest stable binary release to communicate with the Bitcoin peer-to-peer network, for example to learn about current transactions and receive newly mined blocks. All data is regarded as untrusted until it is locally verified to match the consensus rules of Bitcoin Core.

Using binary releases

While the branch on GitHub reflects the current development process, a new stable release is tagged and tested every few months. This release is built from the source code in a reproducible way for various platforms by many contributors, verifying that they get the exact same binary executables by comparing the sha256 hash. These hash values for all images are provided in the file, which is signed by a Bitcoin Core maintainer, currently laanwj.

Instead of compiling Bitcoin Core from source when building the Armbian image, or poviding our own binaries, we believe that following the official binary releases is a good way to minimize trusting any single entity and keep the build process performant.

To ensure that the official binary is used, we store the verified signing key independently from the Bitcoin Core release site and validate the downloaded binary against the signed hash values. If this verification does not succeed (a single bit difference would be enough) the build script aborts with an error.

Configuration

The application configuration is specified in the local file. The file is generated from a template during the build process of the Armbian image. It can updated during regular operations. These are the initial settings:

Some notes about this specific configuration:

• Network options
  • /: the build script defaults to building a mainnet node, but can be reconfigured by:
• Server options
  • : enables the RPC interface
  • : accept connections from other nodes
  • : create a Tor hidden service and accept incoming connections from other nodes on that address
  • : to caputre all log output with the option, bitcoind must not run as a daemon
  • : a full transaction index is not necessary, as we use electrs with its own indices to serve transaction information
  • : both c-lightning as well as electrs do not fully support pruned Bitcoin nodes at the moment
  • : wallet functionality of bitcoind is not used and therefore disabled
• RPC options
  • : specifying , the bitcoind api listens only for local connections
  • : the bitcoind api always listens on port , both for mainnet and testnet
  • : authentication to bitcoind api uses the method, with clients using static and values. Credentials are created using an adapted version of the Bitcoin Core rpcauth.py Python script
• Performance options
  • : initially, the database cache is optimized for the initial block download (IBD), allocating 2GB memory. This value is set to a lower value (default: 300 MB) after bitcoind is fully synced.
  • : upper limit number of connections to other Bitcoin nodes
  • : upper limit for daily upload data volume
• Tor
  • : set bitcoind to also use the Tor proxy for IPv4 and IPv6 connections
  • : initial Tor nodes to bootstrap connections and discover additional nodes
• Validation
  • : if this option is set to , e.g. by the script , bitcoind discards the current UTXO set on restart and revalidates the whole blockchain from Genesis.

Service management

The bitcoind service is managed by systemd. Relevant parameters are specified in the unit file shown below. Please check the most current initial configuration in .

Some notes about this specific configuration:

• : started after regular Linux start and after Redis is available.
• : the must run successfully.
• : a preparation script is run as root (see option) to check Redis availability, valid RPCAUTH credentials and access to the SSD
• : starts
• / : runs as service user “bitcoin”
• : always restarted, unless manually stopped
• : using a private tmp directory
• : mount /usr, /boot/ and /etc read-only for the process
• : disallow the process and all of its children to gain new privileges through execve()
• : use a new /dev namespace only populated with API pseudo devices such as /dev/null, /dev/zero and /dev/random
• : deny the creation of writable and executable memory mappings
• : custom applications are executed after Linux system boot (target ) for the custom target

Data storage

As bitcoind is run as user “bitcoin”, it uses the user’s home directory (set to the SSD as ) as the standard data directory and creates the directory at this location.