Der Sovereign Stack: Leitfaden für Bitcoin Core Full Nodes

Erstellt: 06.11.2026 · Zuletzt aktualisiert: 06.11.2026 · Nejat Hakan

Vorwort – Der letzte Schritt zur monetären Souveränität: Sie haben die ökonomischen Eigenschaften von Bitcoin studiert und Ihre ersten Satoshis erworben. Doch solange Sie sich auf Börsen, Drittanbieter, öffentliche Block-Explorer oder fremde Wallet-Backends verlassen, um Ihren Kontostand abzufragen oder Transaktionen zu versenden, sind Sie nur Gast im System eines anderen – Sie legen Ihre IP-Adresse offen, verknüpfen Ihre UTXOs und vertrauen darauf, dass fremde Server die Konsensregeln ehrlich prüfen. Dieser technische Leitfaden ist Ihre Blaupause, um mit einer kompromisslosen Dual-Citadel-Hardwarearchitektur zu einem vollwertigen, souveränen Netzwerkteilnehmer zu werden.

100% Autonome Validierung

Verifizieren Sie jeden einzelnen Block, jede Skriptsignatur und jede Konsensregel vom Genesis-Block 2009 bis zur aktuellen Chain-Spitze (bitcoind mit txindex=1) auf eigener Hardware.
Dual-Citadel Air-Gap-Isolation

Trennen Sie Ihren dauerhaft vernetzten Node Server physisch von einer permanent offline betriebenen Client Citadel, die ausschließlich zur Prüfung und Signatur von PSBTs dient.
Tor-Only Netzwerk-Privatsphäre

Verbergen Sie Ihre private Wohnort-IP und ISP-Metadaten, indem Sie das Peer-Gossip und Fernzugriffe von Watch-Only-Wallets über Tor v3 Onion Services kapseln.
Kryptografische Supply-Chain-Prüfung

Führen Sie niemals unüberprüfte Binärdateien aus. Authentifizieren Sie sowohl Bitcoin Core (SHA256SUMS.asc) als auch Sparrow Wallet vor der Installation gegen offizielle PGP-Entwicklerschlüssel.

Teil 1: Fundamente & Dual-Citadel-Architektur

1.1 Die drei Kernaufgaben eines Full Nodes

Ein Bitcoin Core Full Node (bitcoind) schürft keine neuen Blöcke; er erzwingt die Regeln des Netzwerks gegenüber Minern und Peers:

Der Wächter (Konsensvalidierung): Prüft mathematisch unabhängig, dass kein Block mehr Coins erzeugt als durch den Halving-Algorithmus vorgegeben, kein UTXO doppelt ausgegeben wird und jede ECDSA/Schnorr-Signatur (secp256k1) uneingeschränkt gültig ist.
Der Historiker (Privates Ledger & Mempool): Hält eine lokale, voll indexierte Kopie der gesamten Blockchain (~700 GB+) sowie des unbestätigten Transaktions-Mempools vor. Sie müssen nie wieder fremde Block-Explorer abfragen.
Der souveräne Sender (Peer-Propagation): Speist Ihre signierten Transaktionen direkt in das dezentrale Peer-to-Peer-Gossip-Netzwerk über Tor ein – ohne Zwischeninstanzen oder Drittanbieter-Filter.

1.2 Das Dual-Citadel-Sicherheitsmodell

Alltags-Notebooks und Smartphones sind permanent Browser-Exploits, unsicheren Abhängigkeiten (npm/pip) und Telemetrie-Diensten ausgesetzt. Echte operative Sicherheit erfordert eine strikte physische Funktionstrennung über dedizierte Single-Purpose-Geräte:

%%{init: {'flowchart': {'wrappingWidth': 350, 'subGraphTitleMargin': {'top': 15, 'bottom': 15}}}}%%
flowchart TB
    subgraph OnlineZone["Online-Netzwerk (Tor)"]
        TOR["🧅 Bitcoin P2P (Tor v3)"]
        NODE["🛡️ Node-Server (Pi 5)<br/>bitcoind + 2TB SSD"]
        DAILY["💻 Daily Driver PC<br/>Watch-Only Wallet"]
        TOR <--> NODE
        NODE <--> DAILY
    end

    SNEAK["💾 Sneakernet microSD<br/>(Air-Gapped PSBT)"]

    subgraph AirGapZone["Air-Gapped Tresor"]
        CITADEL["🏰 Cold Citadel (Pi 5)<br/>Offline / Funk aus"]
        HWW["🔑 Hardware Wallet<br/>(Coldcard / BitBox02)"]
        CITADEL <--> HWW
    end

    DAILY ==>|"1. PSBT exportieren"| SNEAK
    SNEAK ==>|"2. Offline signieren"| CITADEL
    CITADEL ==>|"3. Signiert zurück"| SNEAK
    SNEAK ==>|"4. Broadcasten"| NODE

1.3 Hardware-Stückliste (Bill of Materials)

Komponente	Maschine 1: Der Node Server (24/7 Headless)	Maschine 2: Die Client Citadel (Air-Gapped Signer)	Technische Begründung
Compute Board	Raspberry Pi 5 (`8 GB RAM`)	Raspberry Pi 4 (`4 GB`) oder Pi 5 (`4 GB/8 GB`)	Pi 5 bietet ARMv8.2 Crypto Extensions (Hardware-SHA256/AES), was den Initial Block Download (IBD) um mehr als das Dreifache beschleunigt.
Netzteil	Offizielles `27W` USB-C PD (`5.1V / 5A`)	Offizielles USB-C-Netzteil	Verhindert Unterspannungsfehler während intensiver LevelDB-Chainstate-Kompaktierungen.
OS-Bootmedium	`32 GB` High-Endurance microSD	`32 GB` High-Endurance microSD	Trennt das Debian-Betriebssystem physisch vom schreibintensiven Blockchain-Datenträger.
Hauptspeicher	2 TB NVMe SSD (PCIe HAT) oder SATA SSD	8 GB – 16 GB Sneakernet microSD + USB-Leser	Speichern Sie die Blockchain niemals auf microSD-Karten; `2 TB` bieten jahrelangen Puffer für `blocks/` und `txindex`.
Netzwerkstatus	Gigabit-Ethernet (`eth0`) + Tor	100% Offline (`rfkill` + `dtoverlay=disable-wifi`)	Eliminiert jegliche Remote-Exfiltrationsvektoren auf dem Signiergerät.

Teil 2: Aufbau von Maschine 1 — Gehärteter Node Server

2.1 Basis-OS & Speicher-Vorbereitung

Flashen Sie Raspberry Pi OS Lite (64-Bit / Debian 12 Bookworm) auf die microSD-Karte des Node Servers, schließen Sie die 2 TB SSD sowie das Ethernet-Kabel an und verbinden Sie sich per SSH.

# Datei: /opt/bitcoin-ops/01_prepare_node_server.sh
#!/usr/bin/env bash
set -euo pipefail

# 1. Debian-Pakete aktualisieren und Security-, Tor- und Verifizierungs-Tools installieren
sudo apt update && sudo apt full-upgrade -y
sudo apt install -y ufw fail2ban tor gpg curl jq wget libevent-dev

# 2. UFW-Firewall absichern (Nur LAN-SSH erlauben; alles andere blockieren)
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow from 192.168.1.0/24 to any port 22 proto tcp comment 'LAN SSH'
sudo ufw allow from 192.168.1.0/24 to any port 8332 proto tcp comment 'LAN Sparrow RPC'
sudo ufw --force enable

# 3. Dedizierten System-Benutzer 'bitcoin' anlegen (ohne Login-Shell)
if ! id -u bitcoin >/dev/null 2>&1; then
    sudo useradd --system --home-dir /var/lib/bitcoin --create-home --shell /usr/sbin/nologin bitcoin
fi

Formatieren Sie die 2-TB-SSD (/dev/nvme0n1 oder /dev/sda) mit ext4. Setzen Sie den reservierten Root-Block-Anteil auf 1% statt 5%, um ca. 80 GB Speicherplatz freizugeben, und nutzen Sie noatime, um unnötige Schreibzyklen zu verhindern:

# Datei: /opt/bitcoin-ops/02_mount_blockchain_ssd.sh
# ACHTUNG: Vor dem Formatieren Blockgerät mit 'lsblk' verifizieren!
SSD_PART="/dev/nvme0n1p1"
sudo mkfs.ext4 -m 1 -L "bitcoin-data" "$SSD_PART"

# Dauerhaft via UUID unter /var/lib/bitcoin mounten
SSD_UUID=$(sudo blkid -s UUID -o value "$SSD_PART")
echo "UUID=${SSD_UUID} /var/lib/bitcoin ext4 defaults,noatime,nodiratime,nofail 0 2" | sudo tee -a /etc/fstab
sudo mount -a
sudo chown -R bitcoin:bitcoin /var/lib/bitcoin
sudo chmod 0750 /var/lib/bitcoin

2.2 Kryptografische Verifikation & Installation von Bitcoin Core

Installieren Sie bitcoind niemals aus Drittanbieter-Repositories. Laden Sie das offizielle aarch64-linux-gnu-Release-Tarball, SHA256SUMS und SHA256SUMS.asc herunter und prüfen Sie diese gegen die Bitcoin Core Guix Builder PGP-Schlüssel:

%%{init: {'flowchart': {'wrappingWidth': 350}}}%%
flowchart TB
    TAR["📦 bitcoin-28.0<br/>Release-Archiv"]
    ASC["✍️ SHA256SUMS.asc<br/>Guix Builder PGP-Signaturen"]
    SUM["📄 SHA256SUMS<br/>Verifizierte Prüfsummen"]
    INSTALL["✅ /usr/local/bin/<br/>bitcoind & CLI"]

    TAR -->|"sha256sum"| SUM
    ASC -->|"gpg --verify"| SUM
    SUM -->|"Verifiziert OK"| INSTALL

# Datei: /opt/bitcoin-ops/03_verify_install_bitcoin_core.sh
#!/usr/bin/env bash
set -euo pipefail

VERSION="28.0"
ARCH="aarch64-linux-gnu"
mkdir -p /tmp/bitcoin-verify && cd /tmp/bitcoin-verify

# 1. Offizielles Binärarchiv, Prüfsummen und Multi-Builder-PGP-Signaturen laden
curl -fLO "https://bitcoincore.org/bin/bitcoin-core-${VERSION}/bitcoin-${VERSION}-${ARCH}.tar.gz"
curl -fLO "https://bitcoincore.org/bin/bitcoin-core-${VERSION}/SHA256SUMS"
curl -fLO "https://bitcoincore.org/bin/bitcoin-core-${VERSION}/SHA256SUMS.asc"

# 2. SHA-256 Prüfsumme des Archivs validieren (Muss 'OK' ausgeben)
sha256sum --ignore-missing --check SHA256SUMS

# 3. Offizielle Bitcoin Core Guix Builder Keys importieren und Signatur verifizieren
git clone --depth 1 https://github.com/bitcoin-core/guix.sigs.git
gpg --import guix.sigs/builder-keys/*
gpg --verify SHA256SUMS.asc SHA256SUMS

# 4. Verifizierte Binaries mit Rechten root:root 0755 nach /usr/local/bin installieren
tar -xzf "bitcoin-${VERSION}-${ARCH}.tar.gz"
sudo install -m 0755 -o root -g root -t /usr/local/bin "bitcoin-${VERSION}/bin/"*
bitcoind --version

2.3 Produktions-Konfiguration `bitcoin.conf` & Gehärteter `systemd`-Service

Konfigurieren Sie bitcoind mit vollständigem Transaktionsindex (txindex=1), optimiertem Speicherpuffer (dbcache=2048 für 8 GB RAM), deaktiviertem Server-Wallet (disablewallet=1) und nativer Tor-SOCKS5-Anbindung.

1. /etc/bitcoin/bitcoin.conf2. /etc/systemd/system/bitcoind.service (Sandboxed)3. Tor Hidden Service (/etc/tor/torrc)

# Datei: /etc/bitcoin/bitcoin.conf
# --- Server & Indexierung ---
server=1
daemon=0
txindex=1
blockfilterindex=1
peerblockfilters=1
disablewallet=1

# --- Speicher- & Performance-Tuning (8 GB RAM Pi 5) ---
dbcache=2048
maxmempool=300
maxconnections=40

# --- Tor-Privatsphäre & Netzwerk-Isolation ---
proxy=127.0.0.1:9050
listen=1
bind=127.0.0.1
onlynet=onion
onlynet=cjdns

# --- Lokale RPC-Schnittstelle für Sparrow Watch-Only-Wallet ---
rpcbind=127.0.0.1
rpcbind=192.168.1.50
rpcallowip=127.0.0.1
rpcallowip=192.168.1.0/24

# Datei: /etc/systemd/system/bitcoind.service
[Unit]
Description=Bitcoin Core Full Node Daemon
After=network-online.target tor.service
Wants=network-online.target

[Service]
ExecStart=/usr/local/bin/bitcoind -conf=/etc/bitcoin/bitcoin.conf -datadir=/var/lib/bitcoin -pid=/run/bitcoind/bitcoind.pid
ExecStop=/usr/local/bin/bitcoin-cli -conf=/etc/bitcoin/bitcoin.conf -datadir=/var/lib/bitcoin stop

User=bitcoin
Group=bitcoin
Type=simple
Restart=on-failure
TimeoutStartSec=infinity
TimeoutStopSec=600

RuntimeDirectory=bitcoind
RuntimeDirectoryMode=0710

# --- Obligatorisches systemd Sicherheits-Hardening ---
PrivateTmp=true
ProtectSystem=full
ProtectHome=true
NoNewPrivileges=true
PrivateDevices=true
MemoryDenyWriteExecute=true

[Install]
WantedBy=multi-user.target

# Datei: /etc/tor/torrc (Am Ende anfügen)
ControlPort 9051
CookieAuthentication 1
CookieAuthFileGroupReadable 1

# Bitcoin RPC geschützt über Tor v3 für entfernte Watch-Only-Wallets bereitstellen
HiddenServiceDir /var/lib/tor/bitcoin-rpc/
HiddenServiceVersion 3
HiddenServicePort 8332 127.0.0.1:8332

Aktivieren Sie den Dienst und erlauben Sie dem Benutzer bitcoin, das Authentifizierungs-Cookie von Tor zu lesen:

# Datei: /opt/bitcoin-ops/04_enable_bitcoind.sh
sudo usermod -aG debian-tor bitcoin
sudo systemctl restart tor
sudo systemctl daemon-reload
sudo systemctl enable --now bitcoind

# Synchronisationsfortschritt in Echtzeit prüfen:
sudo -u bitcoin bitcoin-cli -datadir=/var/lib/bitcoin getblockchaininfo

Teil 3: Aufbau von Maschine 2 — Die Air-Gapped Client Citadel

Die Client Citadel ist Ihr Offline-Signierterminal. Sie läuft auf Raspberry Pi OS mit Desktop (64-Bit) und Sparrow Wallet, um Transaktions-Inputs und -Outputs zu analysieren, Wechselgeldadressen zu verifizieren und Signaturen von Hardware-Wallets zu koordinieren.

3.1 Permanente Funkmodul-Deaktivierung (`/boot/firmware/config.txt`)

Bevor die Client Citadel in ihren dauerhaften Offline-Betrieb übergeht, deaktivieren Sie WLAN und Bluetooth direkt auf Hardware-Ebene (Device Tree):

# Datei: /boot/firmware/config.txt (Auf Maschine 2: Client Citadel)
dtoverlay=disable-wifi
dtoverlay=disable-bt

3.2 Kontrollierte Erstinstallation & Verifikation von Sparrow Wallet

Schließen Sie während der Ersteinrichtung kurzzeitig ein Ethernet-Kabel an, um die Debian-Pakete zu aktualisieren und das Sparrow Wallet ARM64 .deb-Paket gegen den PGP-Schlüssel von Entwickler Craig Raw zu verifizieren:

# Datei: /opt/citadel-ops/install_sparrow_verified.sh
#!/usr/bin/env bash
set -euo pipefail

SPARROW_VER="2.0.0"
mkdir -p ~/sparrow-verify && cd ~/sparrow-verify

# 1. Systempakete aktualisieren
sudo apt update && sudo apt full-upgrade -y
sudo apt install -y gpg curl

# 2. Craig Raws öffentlichen PGP-Schlüssel importieren und Sparrow ARM64 Release + Manifest laden
curl -fLO https://keybase.io/craigraw/pgp_keys.asc
gpg --import pgp_keys.asc

curl -fLO "https://github.com/sparrowwallet/sparrow/releases/download/${SPARROW_VER}/sparrow_${SPARROW_VER}-1_arm64.deb"
curl -fLO "https://github.com/sparrowwallet/sparrow/releases/download/${SPARROW_VER}/sparrow-${SPARROW_VER}-manifest.txt"
curl -fLO "https://github.com/sparrowwallet/sparrow/releases/download/${SPARROW_VER}/sparrow-${SPARROW_VER}-manifest.txt.asc"

# 3. PGP-Signatur auf dem Manifest und SHA-256 Prüfsumme des .deb-Pakets verifizieren
gpg --verify "sparrow-${SPARROW_VER}-manifest.txt.asc" "sparrow-${SPARROW_VER}-manifest.txt"
sha256sum --ignore-missing --check "sparrow-${SPARROW_VER}-manifest.txt"

# 4. Verifiziertes Paket installieren, danach herunterfahren und Netzwerk physisch trennen!
sudo apt install -y "./sparrow_${SPARROW_VER}-1_arm64.deb"
echo "Verifikation & Installation erfolgreich. System wird heruntergefahren..."

Erzwingen des Air-Gaps

Sobald sparrow installiert ist, führen Sie sudo poweroff aus, ziehen das Ethernet-Kabel physisch ab und starten die Client Citadel wieder. Von diesem Moment an verbleibt das Gerät vollständig und dauerhaft offline.

Teil 4: Souveräner Betrieb — Der Air-Gapped PSBT-Workflow

In diesem Stack verbleiben die privaten Schlüssel sicher im Hardware Wallet, die Transaktionsprüfung findet auf der Offline-Client Citadel statt und die Indexierung sowie das Senden übernimmt der Node Server.

Schritt	Verwendetes Gerät	Ausgeführte Aktion	Sicherheitsgarantie
1. Watch-Only Einrichtung	Daily Driver PC + Node Server	Importieren Sie ausschließlich den `xpub` (Extended Public Key) in Sparrow auf Ihrem Alltags-PC, angebunden via RPC an Ihren Node Server Pi.	Der Alltags-PC sieht Salden und UTXOs geschützt über den eigenen Node, kann aber keinen einzigen Satoshi ausgeben.
2. Unsignierte PSBT erstellen	Daily Driver PC	UTXOs wählen, Empfängeradresse und Gebührensatz (`sat/vB`) festlegen und auf Save Transaction klicken → `tx_unsigned.psbt` auf die Sneakernet-microSD speichern.	Auf dem vernetzten PC existieren zu keinem Zeitpunkt private Schlüssel.
3. Offline-Audit & Signatur	Air-Gapped Client Citadel + Hardware Wallet	Stecken Sie die microSD in die Offline-Citadel. Öffnen Sie `tx_unsigned.psbt` in Sparrow, verifizieren Sie Empfänger, Wechselgeld und Gebühren sowohl in Sparrow als auch auf dem Display des Hardware Wallets und signieren Sie → `tx_signed.psbt`.	Selbst bei kompromittiertem Alltags-PC (z. B. Clipboard-Malware) decken die Offline-Citadel und der Bildschirm des Hardware Wallets manipulierte Adressen auf.
4. Privater Broadcast	Daily Driver PC → Node Server → Tor	Stecken Sie die microSD zurück in den Alltags-PC, laden Sie `tx_signed.psbt` und klicken Sie auf Broadcast Transaction. Ihr Node Server leitet sie über Tor ins Netzwerk weiter.	Kein externer Block-Explorer oder Webserver erfährt jemals Ihre IP-Adresse oder Ihren UTXO-Graphen.

Teil 5: Lebenszyklus-Wartung & Das sichere Update-Ritual

5.1 Eigene Blockchain über `bitcoin-cli` auditieren

Ersetzen Sie öffentliche Explorer (mempool.space, blockstream.info) durch direkte CLI-Abfragen auf Ihrem Node Server:

# Datei: /opt/bitcoin-ops/node_explorer_cli.sh
# 1. Synchronisationshöhe, Speicherverbrauch und aktive Soft-Forks prüfen
sudo -u bitcoin bitcoin-cli getblockchaininfo

# 2. Tor-Onion-Peerverbindungen und lokale Onion-Adresse abfragen
sudo -u bitcoin bitcoin-cli getnetworkinfo
sudo -u bitcoin bitcoin-cli getpeerinfo | jq '.[] | {addr, subver, network, synced_headers}'

# 3. Aktuelle Mempool-Größe und Mindest-Relay-Gebühr kontrollieren
sudo -u bitcoin bitcoin-cli getmempoolinfo

# 4. Beliebige Transaktion der gesamten Historie abrufen (durch txindex=1 ermöglicht)
# sudo -u bitcoin bitcoin-cli getrawtransaction "<txid>" true

5.2 Das ritualisierte Offline-Update-Protokoll (alle 3–6 Monate)

Wie patcht man ein luftspaltisoliertes System, ohne den Sicherheitsstatus zu gefährden? Durch ein diszipliniertes kontrolliertes Update-Ritual:

Alle Signiermedien entfernen: Stellen Sie sicher, dass Hardware Wallet und Sneakernet-microSD physisch abgezogen und sicher verstaut sind, bevor das System gestartet wird.
Befehle offline vorbereiten: Starten Sie die Client Citadel, öffnen Sie das Terminal und bereiten Sie die Update-Befehle vor (sudo apt update && sudo apt full-upgrade -y).
Kurzes, kontrolliertes Online-Fenster: Stecken Sie das Ethernet-Kabel ein, führen Sie die GPG-verifizierten Paketupdates zügig aus und öffnen Sie niemals einen Webbrowser zum allgemeinen Surfen.
Trennen & Neustarten: Führen Sie sudo poweroff aus, ziehen Sie das Ethernet-Kabel ab, warten Sie 10 Sekunden und booten Sie das Gerät wieder in den reinen Air-Gap-Betrieb.

5.3 Was gesichert werden muss (und was niemals)

Datenbestand	Backup-Strategie	Begründung
24-Wörter Seed-Phrase + Passphrase	Ausschließlich physisches Metall-/Papier-Backup (in räumlich getrennten Tresoren; NIEMALS digital abtippen oder fotografieren).	Ihre Seed-Phrase ist Ihr Guthaben. Sämtliche Hardware ist ersetzbar.
Wallet-Deskriptor / Output-Datei	Öffentlichen Deskriptor (`xpub` + Ableitungspfad, essenziell für Multisig) verschlüsselt auf Backup-USB/microSD sichern.	Wird neben den Seed-Wörtern zwingend benötigt, um Multisig-Skripte (`wsh(sortedmulti(...))`) zu rekonstruieren.
Node-Konfiguration (`bitcoin.conf`, `torrc`)	Im privaten Infrastruktur-Git-Repository versionieren.	Ermöglicht bei Hardwareausfall einen Neuaufbau des Nodes in unter 15 Minuten.
Blockchain-Rohdaten (`/var/lib/bitcoin/blocks`)	NIEMALS SICHERN.	Die über 700 GB große Blockchain besteht aus öffentlichen Daten, die Ihr Node jederzeit selbstständig von Peers neu validieren kann.

Weiterführende Themen

Vertiefen Sie die kryptografischen Grundlagen von Bitcoin sowie die zugrundeliegende Linux-Hardware und Systemsicherheit:

Bitcoin-Architektur & Ökonomie

Detaillierte Analyse des UTXO-Modells, SHA-256 Proof-of-Work, der geldpolitischen Halving-Mechanik und technischer Gegenargumente zu gängigen Vorbehalten.

Bitcoin Einführung
Raspberry Pi Hardware-Engineering

Beherrschen Sie ARM64 NVMe-Boot, vcgencmd-Spannungs- und Temperaturdiagnosen sowie Maßnahmen zur Haltbarkeit von Speichermedien.

Raspberry Pi Masterclass
Linux Sicherheit & Härtung

Härten Sie SSH, ufw, AppArmor und Kernel-sysctl-Parameter auf Ihren Debian-Linux-Servern ab.

Linux Härtung