Verifizierung und Open Source

“Don’t trust, verify” gilt nicht nur für die Timechain — es gilt auch für die Software, die du installierst. Wenn du einem Bitcoin-Node oder einer Wallet vertraust, ohne die Herkunft zu prüfen, ist die gesamte Verifikationskette gebrochen. Ein kompromittiertes Binary kann deine Keys stehlen, Transaktionen umleiten oder falsche Daten anzeigen. Egal wie sicher dein Node konfiguriert ist.

Warum Open Source bei Geld-Software Pflicht ist

Stell dir vor, du nutzt eine Wallet, deren Quellcode geheim ist. Der Entwickler verspricht: “Deine Keys sind sicher.” Du glaubst ihm. Aber du kannst es nicht prüfen. Vielleicht schickt die Software deinen Seed an einen Server. Vielleicht hat der Entwickler eine Hintertür eingebaut. Vielleicht wird er erpresst und liefert ein Update mit Malware aus.

Bei Open-Source-Software kann jeder den Code lesen, prüfen und Alarm schlagen. Das bedeutet nicht, dass jeder den Code liest — aber es bedeutet, dass es möglich ist. Und bei Bitcoin tun es viele. Bitcoin Core hat hunderte von Reviewern. Jede Änderung wird öffentlich diskutiert, geprüft und getestet.

Die drei Säulen der Softwareverifizierung

Alle drei zusammen ergeben ein System, dem du nicht vertrauen musst — weil du es prüfen kannst.

GPG-Signaturen verstehen

GPG (GNU Privacy Guard) ist ein Werkzeug für asymmetrische Kryptographie. Das Prinzip ist dasselbe wie bei Bitcoin: Es gibt einen privaten Schlüssel (zum Signieren) und einen öffentlichen Schlüssel (zum Verifizieren).

graph LR
    D["Entwickler"] -->|"signiert mit\nprivatem Schlüssel"| S["SHA256SUMS.asc\n(Signatur)"]
    S --> V["Du"]
    P["Öffentlicher Schlüssel\n(auf Key-Server)"] --> V
    V -->|"verifiziert"| OK["✓ Good signature"]

    style D stroke:#98971a,stroke-width:2px,color:#98971a
    style V stroke:#fe8019,stroke-width:2px,color:#fe8019

Wenn ein Bitcoin-Core-Entwickler ein Release signiert:

1. Er berechnet die SHA-256-Prüfsummen aller Dateien → SHA256SUMS
2. Er signiert SHA256SUMS mit seinem privaten GPG-Schlüssel → SHA256SUMS.asc
3. Du lädst beides herunter
4. Du prüfst die Signatur mit seinem öffentlichen Schlüssel
5. Wenn die Signatur gültig ist, weißt du: Die Prüfsummen stammen vom Entwickler und wurden nicht verändert
6. Dann prüfst du die Prüfsumme deiner heruntergeladenen Datei gegen SHA256SUMS

Warum reicht die Prüfsumme allein nicht?

Eine Prüfsumme beweist nur, dass die Datei nicht verändert wurde — nicht, dass sie vom richtigen Absender stammt. Wenn ein Angreifer die Website kompromittiert, kann er sowohl die Software als auch die Prüfsummen austauschen. Die GPG-Signatur ist der Beweis, dass die Prüfsummen von jemandem erstellt wurden, der den privaten Schlüssel besitzt.

Praktisch: Bitcoin Core Release verifizieren

Hier ist der vollständige Prozess, Schritt für Schritt. Du brauchst: gpg, sha256sum (Linux/macOS) oder die PowerShell-Äquivalente (Windows).

1. Dateien herunterladen

Lade von https://bitcoincore.org/en/download/ herunter:

• Das Installationspaket (z. B. bitcoin-28.0-x86_64-linux-gnu.tar.gz)
• SHA256SUMS
• SHA256SUMS.asc

2. Entwickler-Schlüssel importieren

Bitcoin Core Releases werden von mehreren Entwicklern signiert. Die Schlüssel-Fingerprints sind auf der Download-Seite und im Repository dokumentiert.

# Schlüssel vom Keyserver importieren
gpg --keyserver hkps://keys.openpgp.org --recv-keys \
  152812300785C96444D3334D17565732E08E5E41

# Alternativ: Aus dem Bitcoin Core Repository
git clone https://github.com/bitcoin-core/guix.sigs
gpg --import guix.sigs/builder-keys/*.gpg

3. Signatur prüfen

gpg --verify SHA256SUMS.asc SHA256SUMS

Erwartete Ausgabe:

gpg: Signature made Mon 01 Oct 2025 12:00:00 UTC
gpg: using RSA key 152812300785C96444D3334D17565732E08E5E41
gpg: Good signature from "Andrew Chow <andrew@achow101.com>"
gpg: WARNING: This key is not certified with a trusted signature!

“Good signature” ist das Entscheidende. Die Warnung “not certified with a trusted signature” bedeutet nur, dass du den Schlüssel nicht persönlich in deinem GPG-Keyring als vertrauenswürdig markiert hast. Das ist normal und kein Problem — solange du den Fingerprint unabhängig verifiziert hast.

Wenn die Ausgabe “BAD signature” zeigt: Die Datei wurde manipuliert. Nicht installieren. Alles löschen und von vorn beginnen.

4. Prüfsumme verifizieren

sha256sum --check SHA256SUMS 2>/dev/null | grep bitcoin-28

Erwartete Ausgabe:

bitcoin-28.0-x86_64-linux-gnu.tar.gz: OK

Wenn hier “FAILED” steht: Die heruntergeladene Datei stimmt nicht mit der signierten Prüfsumme überein. Löschen und neu herunterladen.

Reproduzierbare Builds: Die letzte Lücke schließen

Open Source und GPG-Signaturen lösen zwei Probleme: Du kannst den Code lesen, und du weißt, wer das Binary signiert hat. Aber es bleibt eine Lücke: Wurde das Binary tatsächlich aus genau diesem Quellcode gebaut?

Theoretisch könnte ein Entwickler den Quellcode sauber veröffentlichen, aber ein modifiziertes Binary signieren — mit einer Hintertür, die im Quellcode nicht existiert.

Die Lösung: Deterministische Builds

Ein reproduzierbarer Build bedeutet: Jeder, der denselben Quellcode mit denselben Build-Werkzeugen kompiliert, erhält exakt das gleiche Binary — Bit für Bit identisch.

Bitcoin Core nutzt dafür Guix (GNU Guix), ein Build-System, das die gesamte Build-Umgebung exakt spezifiziert: Compiler-Version, Bibliotheken, Betriebssystem-Konfiguration. Das Ergebnis ist reproduzierbar.

graph TD
    SC["Quellcode\n(GitHub)"] --> B1["Builder 1"]
    SC --> B2["Builder 2"]
    SC --> B3["Builder 3"]

    B1 -->|"Guix Build"| H1["Hash: a1b2c3..."]
    B2 -->|"Guix Build"| H2["Hash: a1b2c3..."]
    B3 -->|"Guix Build"| H3["Hash: a1b2c3..."]

    H1 --> V["Vergleich"]
    H2 --> V
    H3 --> V
    V -->|"Alle identisch"| OK["Binary ist vertrauenswürdig"]

    style OK stroke:#98971a,stroke-width:2px,color:#98971a

Wie das in der Praxis funktioniert

Beim Bitcoin Core Release-Prozess:

1. Mehrere unabhängige Entwickler bauen das Release aus dem Quellcode mit Guix
2. Jeder veröffentlicht den Hash seines Ergebnisses im guix.sigs-Repository
3. Wenn alle Hashes übereinstimmen, ist bewiesen: Das Binary stammt aus dem veröffentlichten Code
4. Erst dann signieren die Maintainer das Release

Du kannst das selbst nachprüfen:

# guix.sigs Repository klonen
git clone https://github.com/bitcoin-core/guix.sigs

# Die Attestierungen verschiedener Builder vergleichen
ls guix.sigs/28.0/

# Jeder Ordner enthält die Hashes eines Builders
# Wenn alle übereinstimmen: Der Build ist reproduzierbar

Web of Trust: Wem vertraust du?

GPG arbeitet mit einem Web of Trust — einem dezentralen Vertrauensmodell. Statt einer zentralen Zertifizierungsstelle (wie bei HTTPS) bestätigen sich GPG-Nutzer gegenseitig:

• Alice signiert Bobs Schlüssel (“Ich habe verifiziert, dass dieser Schlüssel Bob gehört”)
• Bob signiert Carols Schlüssel
• Wenn du Alice vertraust, vertraust du indirekt auch Bobs und Carols Schlüssel

Für Bitcoin Core musst du kein komplexes Web of Trust aufbauen. Es reicht:

1. Lade die Schlüssel der bekannten Maintainer von mehreren unabhängigen Quellen
2. Vergleiche die Fingerprints
3. Prüfe, ob die Signaturen gültig sind

Fingerprints vergleichen: Woher nehmen?

Je mehr Quellen denselben Fingerprint zeigen, desto sicherer bist du. Das ist dasselbe Prinzip wie bei Bitcoin: Vertrauen durch unabhängige Bestätigung, nicht durch eine zentrale Autorität.

Nicht nur Bitcoin Core

Alles, was in dieser Anleitung für Bitcoin Core beschrieben wird, gilt auch für andere Geld-Software:

• Electrs/Fulcrum: Prüfe die GPG-Signaturen oder zumindest die Git-Commit-Signaturen
• LND/Core Lightning: Releases werden signiert — verifiziere sie
• Sparrow Wallet: Bietet signierte Releases und reproduzierbare Builds
• Hardware-Wallet-Firmware: Trezor und BitBox02 bieten reproduzierbare Builds; Ledger nicht

Die Vertrauenskette zusammengefasst

Vom Quellcode bis zu deinem laufenden Node:

1. Quellcode — Open Source, von hunderten Augen geprüft
2. Build — Reproduzierbar via Guix, von mehreren unabhängigen Buildern bestätigt
3. Signatur — GPG-signiert von bekannten Maintainern
4. Download — Prüfsumme und Signatur lokal verifiziert
5. Installation — Du führst genau das aus, was geprüft wurde
6. Betrieb — Dein Node verifiziert die Timechain selbstständig

Kein Schritt erfordert blindes Vertrauen. Jeder ist prüfbar. Das ist “don’t trust, verify” — zu Ende gedacht.

Weiterführend

• Bitcoin Core einrichten — Die praktische Anleitung, in der du die Verifizierung anwendest
• Warum eine eigene Node? — Warum Verifizierung das Fundament der Souveränität ist
• Hashing und der Lawinen-Effekt — SHA-256: Die kryptographische Basis von Prüfsummen
• Adressen und Schlüssel — Asymmetrische Kryptographie, die auch hinter GPG steckt