Exporting the Blockchain from an Encrypted Start9 System

10 February 2026 · 6 Min. read

You've synced 880,000+ blocks on your Start9 server. Now you want to run a second Bitcoin node on different hardware — maybe a Raspberry Pi, a mini-PC, or a laptop — without waiting days for another full sync.

The blockchain is right there on your Start9. But getting it out is harder than you'd think.

The Problem

Start9 (StartOS) encrypts all package data with LUKS. Bitcoin's blockchain lives deep inside the encrypted volume at:

/embassy-data/package-data/volumes/bitcoind/data/main/

When you SSH in as the start9 user, you'll run into three walls:

Wall 1: No package manager. StartOS blocks apt. You can't install NFS, Samba, or any file-sharing daemon.

Wall 2: Root-owned files. The blockchain data belongs to root (it runs inside a Podman container). The start9 user can't read it directly.

Wall 3: SSHFS is too slow. You can mount the files via SSHFS, but Bitcoin's random I/O pattern (millions of small reads for UTXO lookups) performs terribly over SSH — often under 1 MB/s.

The Solution: NFS via Podman

Start9 ships with Podman (its container runtime for all Embassy services). We can use it to run an NFS server in a container — no apt required.

            Key insight: Podman is already installed on every Start9
            system. We just need to run a lightweight NFS container that exports
            the blockchain directory.
        

Step by Step

Step 1: Load the NFS kernel modules

SSH into your Start9 and load the NFS modules:

ssh start9@your-start9-ip
sudo modprobe nfs
sudo modprobe nfsd

These modules are included in the StartOS kernel but not loaded by default.

Step 2: Start the NFS container

One command does it all:

sudo podman run -d \
  --name nfs-blocks \
  --privileged \
  --network=host \
  -v /embassy-data/package-data/volumes/bitcoind/data/main/blocks:/export/blocks \
  -e NFS_EXPORT_0='/export/blocks 192.168.1.0/24(ro,no_subtree_check,all_squash,anonuid=0,anongid=0)' \
  docker.io/erichough/nfs-server:2.2.1

This exports the blocks directory read-only to your local network. Change 192.168.1.0/24 to match your subnet.

Step 3: Mount on your target machine

On your Pi, laptop, or mini-PC:

sudo apt install -y nfs-common
sudo mkdir -p /mnt/bitcoin-blocks
sudo mount -t nfs -o ro,vers=3 your-start9-ip:/export/blocks /mnt/bitcoin-blocks

Verify it works:

ls /mnt/bitcoin-blocks/blk00000.dat  # Should exist
ls /mnt/bitcoin-blocks/ | wc -l      # Should show thousands of files

What to Copy

You don't need to copy 800 GB of block files. Bitcoin stores three types of data, and you only need to copy two small ones:

Start9 Bitcoin Data ├── blocks/ (~760 GB) ← Keep on Start9, serve via NFS │ ├── blk*.dat (raw block data) │ ├── rev*.dat (undo data) │ └── xor.dat (obfuscation key, 8 bytes) ├── blocks/index/ (~215 MB) ← Copy this └── chainstate/ (~11 GB) ← Copy this

The block index maps block hashes to file positions. The chainstate is the UTXO set — every unspent transaction output in Bitcoin. Together they're ~11 GB. The 760 GB of raw blocks stay on Start9 and are served over the network.

Important: Stop Start9's bitcoind before copying the chainstate. A running node constantly modifies the UTXO database, so copying while running would give you a corrupt snapshot.

Copying the Data

Stop the Bitcoin service on Start9 (via the Start9 UI or command line), then copy via SSH:

# From your target machine:
SRC=/embassy-data/package-data/volumes/bitcoind/data/main

# Block index (small, fast)
ssh start9@your-start9-ip "sudo tar cf - -C $SRC/blocks/index ." | \
  tar xf - -C /path/to/your/datadir/blocks/index/

# Chainstate (~11 GB, takes ~25 min over gigabit)
ssh start9@your-start9-ip "sudo tar cf - -C $SRC/chainstate ." | \
  tar xf - -C /path/to/your/datadir/chainstate/

Don't forget to restart Start9's Bitcoin service after copying.

XOR Obfuscation (xor.dat)

Since Bitcoin Knots v28+ (and Bitcoin Core), block files are obfuscated with an 8-byte XOR key stored in blocks/xor.dat. This key is randomly generated during initial sync — each Start9 instance has its own unique key.

This means the blk*.dat and rev*.dat files are not stored in plaintext. Every byte is XOR'd with the 8-byte key. This doesn't protect against targeted access (the key is right next to the data), but it prevents antivirus software and backup tools from flagging Bitcoin transactions as suspicious data.

Why this matters for our setup: The block index stores file positions that reference these obfuscated files. As long as your target node reads the same block files (via NFS), the XOR key is read from xor.dat automatically and everything works. You don't need to copy xor.dat separately — it's already in the blocks directory.

Don't mix block files from different syncs. Each independent sync writes blocks in a different order and generates its own XOR key. A block index from Sync A won't work with block files from Sync B — neither the file positions nor the obfuscation key will match.

NFS vs SSHFS: Why It Matters

Bitcoin's block validation hammers the storage with millions of small random reads. The protocol overhead per operation makes a huge difference:

Protocol Sequential Read Bitcoin Random I/O ───────── ────────────── ────────────────── Local SSD 500+ MB/s 100,000+ IOPS NFS 6-7 MB/s ~3 MB/s effective SSHFS 5-6 MB/s ~0.5 MB/s effective

NFS is 6x faster than SSHFS for Bitcoin's access pattern because it doesn't have SSH's per-operation encryption round-trip. For read-heavy workloads like block serving, NFS is the clear winner.

The Result

After copying ~11 GB of index data (~25 minutes) and configuring the NFS mount, your second node starts with a fully validated blockchain. No reindex. No days of waiting. The blocks are served over the network from Start9, and the local chainstate handles UTXO lookups at full speed.

            Total setup time: ~50 minutes

            Data copied: ~11 GB (not 800 GB)

            Re-sync required: None

Making It Persistent

Add the NFS mount to /etc/fstab on your target machine so it survives reboots:

# /etc/fstab
your-start9-ip:/export/blocks  /mnt/bitcoin-blocks  nfs  ro,soft,timeo=300,_netdev  0  0

On Start9, the NFS container restarts automatically if you set it up properly. You can also create a small script to ensure the kernel modules are loaded and the container is running after a reboot.

Security Notes

The NFS export is read-only and restricted to your local subnet
Block data is public information — there's no privacy risk in serving it locally
The chainstate copy contains no private keys or wallet data
Start9's LUKS encryption still protects the data at rest when powered off

Running Bitcoin on Unusual Hardware?

I help people set up Bitcoin nodes on everything from Banana Pis to distributed multi-machine setups. Let's talk.

Get in Touch