Mein eigener Bitcoin-Node – selbst kompiliert, full, ohne Kompromisse

Bitcoin ist kein "Cloud"-Ding. Es ist ein Netzwerk, und du bist entweder Teil davon oder nicht. Ein eigener Node bedeutet: Du vertraust keiner Fremd-API, keinem Drittanbieter, keiner "Lightweight"-Wallet, die sich mit einem zufälligen Server verbindet. Aber einen Node betreuen heißt auch: Ein paar Hundert Gigabyte Festplatte, eine Nacht Kompilierzeit und die Frage, ob du prunen darfst oder nicht.

Warum ich aus Source kompiliere

Die meisten betreiben Bitcoin Core per apt install bitcoind oder ziehen das Binary von bitcoincore.org. Das ist bequem, aber mein Node verwaltet meine Transaktionen. Ich will wissen, was darauf läuft.

# Source holen und verifizieren
git clone https://github.com/bitcoin/bitcoin.git
cd bitcoin
git checkout v28.4            # Release von April 2026
git tag -v v28.4             # GPG-Signatur prüfen!

Ich prüfe den Tag gegen den Release-Key von Bitcoin Core. Dann wird kompiliert – ohne vorgefertigtes Binary, ohne Paketmanager, ohne dass irgendjemand zwischen mir und dem Code steht.

./autogen.sh
./configure --without-gui --disable-wallet --enable-hardening
make -j$(nproc)
sudo make install

Ja, das dauert. Auf einem Mini-PC mit vier Kernen gerne zwei Stunden. Aber ich mache das nicht jeden Tag. Einmal pro Release, und ich weiß, dass auf meinem Node genau der Code läuft, den ich gelesen habe.

Bei mir läuft der Node übrigens in einem Incus-System-Container – sauber isoliert vom Host, snapshotbar und bei Bedarf migrierbar. Die Blockchain liegt dabei auf einem separaten Storage-Device, damit sie ein Neuaufsetzen des Containers überlebt. Ein LXC reicht hier völlig, eine VM wäre nur Overhead – Bitcoin Core ist am Ende ein Linux-Prozess, der Platte und CPU will.

Aspekt	Binary von bitcoin.org	Selbst kompiliert
Vertrauen	Release-Signer + Infrastruktur	Nur der eigene Code-Check
Aufwand	2 Minuten	2 Stunden (einmalig)
Reproduzierbarkeit	Gegeben	Gegeben (deterministic build)
Optimierung	Generisch	CPU-spezifisch (-march=native)

Full Node vs. Pruned Node – der Speicher-Konflikt

Bitcoin Core hat einen Parameter, der alles verändert:

# Full Node: ~700 GB und wachsend
prune=0

# Pruned Node: maximal 10 GB Blockchain-Daten
prune=10000

Full Node

Du lädst die gesamte Blockchain herunter und behältst sie. Jeder Block, jede Transaktion seit 2009 – vollständig auf deiner Platte. Das kostet aktuell etwa 700 GB und wächst um ~100 GB pro Jahr.

Vorteil: Du kannst jeden historischen Block validieren, jeden UTXO-Set-Zustand nachvollziehen, und – das ist der wichtige Punkt – **einen Electrum-Server darauf setzen**.

Pruned Node

Du behältst nur die letzten 10 GB (oder wie viel du konfigurierst). Die Blöcke werden validiert und dann weggeworfen. Das spart massiv Platz:

# ~700 GB → ~10 GB
# bitcoin.conf
prune=10000
txindex=0

Aber: Ein Pruned Node kann keine historischen Blöcke mehr nachreichen. Und ein Electrum-Server braucht genau das: einen vollständigen Index aller Transaktionen.

Kriterium	Full Node	Pruned Node
Speicher	~700 GB + Wachstum	~10 GB
Electrum-Server	Möglich	Nicht möglich
Historische Blöcke	Alle vorhanden	Nur die letzten
Erst-Sync	2–3 Tage	2–3 Tage (danach schrumpft es)
Sinn für Light-Wallets	Ja (als Backend)	Nein

Warum ein persönlicher Electrum-Server sinnvoll ist

Die meisten Bitcoin-Wallets verbinden sich zu öffentlichen Electrum-Servern oder – noch schlimmer – raten per DNS, welcher Server gerade erreichbar ist. Du fragst im Prinzip einen Fremden: "Hey, wie viele Bitcoins habe ich?"

Ein eigener Electrum-Server ändert das:

# Eigener Server: lokale Verbindung
ELECTRUM_SERVER=127.0.0.1:50002

Deine Wallet fragt deinen Node, dein Node fragt das Netzwerk. Kein Dritter sieht deine Addressen, deine Salden, deine Transaktionshistorie.

Electrum kann mehr als nur Abfragen

• Private Transaktionshistorie – kein Server lernt deine Coins
• Offline-Signing – kalte Wallet + Electrum + eigener Server
• PSBTs – teilweise signierte Transaktionen (Multisig, Hardware-Wallet)
• Channel-Operationen – Lightning-Verbindungen prüfen

Der Haken

Der bekannteste Electrum-Server (electrs) braucht einen **vollständigen Blockchain-Index**. Das bedeutet:

# Zusätzlich zum Full Node: ~100 GB Index-Datenbank
# Gesamt: ~800 GB für Node + Electrum-Server

Du kommst mit einem Full Node allein nicht aus. Electrum-Server baut einen eigenen UTXO- und History-Index auf. Der steht zusätzlich auf der Platte.

# electrs installieren
git clone https://github.com/romanz/electrs.git
cd electrs
cargo build --release
# ~30 Minuten Compile-Zeit (Rust)

Betreiben lässt sich das als einfaches Systemd-Service-Paar:

# /etc/systemd/system/electrs.service
[Unit]
Description=Electrum Server
After=bitcoind.service

[Service]
ExecStart=/usr/local/bin/electrs --db-dir /var/lib/electrs/db \
  --daemon-dir /var/lib/bitcoind --electrum-rpc-addr 127.0.0.1:50001
User=electrs
Restart=always

[Install]
WantedBy=multi-user.target

Mein Setup

Ich fahre beide Dienste im selben Incus-LXC auf einem Server mit 1 TB NVMe:

Incus-LXC "bitcoin"
├── Bitcoin Core (Full, selbst kompiliert, v28.4)
└── electrs (Rust, selbst kompiliert)
    └── Electrum-Wallet (Laptop, verbindet per LAN)

Platzverbrauch:

Datentyp	Größe
Blockchain (Blöcke)	~700 GB
Electrum-Index (electrs)	~100 GB
Sonstiges (Debug, Logs)	~20 GB
Gesamt	~820 GB

Ja, das ist viel. Eine 1-TB-SSD kostet ~80 €. Einmalig. Dafür habe ich keine einzige Vertrauensbeziehung zu einem externen Server mehr.

Fazit

Einen Bitcoin-Node aus Source zu kompilieren ist Overkill. Für die meisten. Aber wenn es um Geld geht, finde ich Overkill angemessen.

Prunen spart Platz, aber es sperrt dich aus – Electrum-Server geht dann nicht, und du bist wieder auf fremde Server angewiesen. Wer seinen Node ernst nimmt, lässt prune aus, investiert in eine große Platte und stellt einen Electrum-Server daneben.

Die 800 GB sind kein Fehler. Sie sind die Eintrittskarte in ein Netzwerk, in dem du niemandem vertrauen musst. Nicht Bitcoin Core, nicht dem Paketmanager, nicht dem Electrum-Server von jemand anderem.

Und für das Gefühl, beim ersten bitcoin-cli getblockchaininfo zu sehen, dass der eigene, selbst kompilierte Node auf Block 876.543 ist – dafür lohnt sich die Nacht Kompilierzeit dann doch.