Open Source und Vertrauen

Würdest du dein gesamtes Vermögen einer Software anvertrauen, deren Quellcode du nicht einsehen kannst? Einer Firma, die dir sagt: “Vertrau uns, alles sicher”? In jedem anderen Bereich wäre die Antwort offensichtlich. Bei Geld-Software ist sie es auch.

Warum Open Source für Geld-Software nicht optional ist

Closed-Source-Software bedeutet: Du weißt nicht, was die Software tut. Du weißt nicht, ob sie deine Schlüssel an einen Server sendet. Du weißt nicht, ob eine Hintertür eingebaut ist. Du weißt nicht, ob ein Fehler dein Geld gefährdet.

Du hast nur ein Versprechen. Und Versprechen sind, wie wir gesehen haben, keine zuverlässige Grundlage.

Das Argument in drei Sätzen

1. Geld-Software verwaltet Schlüssel, die direkten Zugriff auf Vermögen geben
2. Jeder Fehler — absichtlich oder versehentlich — kann zu Totalverlust führen
3. Nur offener Quellcode erlaubt unabhängige Überprüfung, ob die Software tut, was sie verspricht

Das ist kein Idealismus. Das ist Risikomanagement.

Geschlossene Systeme und ihre Kosten

Die Geschichte ist voll von Fällen, in denen Closed-Source-Software genau das getan hat, was sie nicht tun sollte:

• Ledger Live (2023): Ledger kündigte “Recover” an — einen Dienst, der die Seed Phrase in drei verschlüsselte Fragmente aufteilt und an Drittanbieter sendet. Die Hardware-Wallet-Community war entsetzt. Nicht weil der Dienst existierte, sondern weil die Firmware-Updates auf der Hardware-Wallet Closed Source waren. Nutzer mussten vertrauen, dass Ledger ihre Schlüssel nicht ohne Einwilligung extrahiert. Ein offener Quellcode hätte diese Debatte überflüssig gemacht.
• Wasabi Wallet 2.0 (2022): Nach dem Rewrite wurde entdeckt, dass der CoinJoin-Koordinator Transaktionen zensieren konnte. Weil der Code offen war, wurde das Problem schnell identifiziert und öffentlich diskutiert. Stell dir vor, derselbe Code wäre geschlossen gewesen.

Das “Viele Augen”-Prinzip

Linus Torvalds — Erfinder von Linux — formulierte es so: “Given enough eyeballs, all bugs are shallow.” Je mehr Menschen einen Quellcode lesen, desto schneller werden Fehler gefunden.

Wie das in der Praxis funktioniert

Open Source bedeutet nicht, dass jeder den Code liest. Es bedeutet, dass jeder es kann — und dass genug Menschen es tun:

• Sicherheitsforscher suchen gezielt nach Schwachstellen — manchmal für Bug Bounties, manchmal aus wissenschaftlichem Interesse
• Entwickler anderer Projekte prüfen den Code, weil sie darauf aufbauen
• Paranoide Nutzer (und das ist keine Beleidigung) lesen Code, bevor sie ihm ihre Schlüssel anvertrauen
• Wettbewerber suchen nach Schwächen, um ihre eigenen Lösungen als überlegen zu positionieren

Dieses System ist nicht perfekt. Bugs können jahrelang übersehen werden — die Heartbleed-Lücke in OpenSSL existierte zwei Jahre, bevor sie entdeckt wurde. Aber sie wurde entdeckt. In einem geschlossenen System hätte sie möglicherweise Jahrzehnte bestanden — oder würde noch bestehen.

Die Asymmetrie

Einen Bug zu verstecken ist bei Open Source exponentiell schwieriger als bei Closed Source. Ein Entwickler, der absichtlich eine Hintertür einbauen will, muss sie so subtil gestalten, dass hunderte erfahrene Reviewer sie übersehen. Bei Closed Source muss er gar nichts verstecken — niemand kann nachschauen.

Bitcoin Core: Wie Code-Review funktioniert

Bitcoin Core ist das am intensivsten überprüfte Open-Source-Projekt in der Geschichte der Finanzsoftware. Und der Review-Prozess ist absichtlich langsam, konservativ und streng.

Der Weg einer Code-Änderung

1. Pull Request (PR): Ein Entwickler schlägt eine Änderung vor. Der gesamte Code-Diff ist öffentlich einsehbar.
2. Concept ACK: Andere Entwickler bewerten zunächst, ob die Änderung grundsätzlich sinnvoll ist.
3. Code Review: Mindestens mehrere erfahrene Entwickler prüfen den Code Zeile für Zeile. Sie suchen nach Bugs, Sicherheitslücken, unbeabsichtigten Nebeneffekten, Inkonsistenzen.
4. Testing: Automatisierte Tests laufen. Reviewer testen manuell auf verschiedenen Systemen.
5. NACK: Jeder kann ein NACK (Not Acknowledged) aussprechen und begründen, warum die Änderung nicht gemergt werden sollte.
6. Merge: Erst wenn genügend erfahrene Reviewer zustimmen und kein begründetes NACK vorliegt, wird der Code übernommen.

Dieser Prozess dauert oft Wochen oder Monate — für eine einzige Änderung. Das ist Absicht. Bei Software, die Milliarden an Wert sichert, ist Geschwindigkeit keine Tugend.

Die Zahlen

Bitcoin Core hat über 900 Contributors. Jeder Pull Request wird durchschnittlich von 4-8 Reviewern geprüft. Kritische Änderungen werden von Dutzenden Entwicklern begutachtet. Der Code hat über 22.000 Commits und eine der strengsten Review-Kulturen in der Open-Source-Welt.

Reproducible Builds: Dem Compiler nicht vertrauen müssen

Open Source allein reicht theoretisch nicht aus. Denn zwischen dem Quellcode, den du auf GitHub liest, und dem Programm, das du herunterlädst, liegt ein Schritt: die Kompilierung. Ein manipulierter Compiler könnte Schadcode einschleusen, der im Quellcode nicht sichtbar ist.

Ken Thompson beschrieb dieses Problem 1984 in seinem legendären Vortrag “Reflections on Trusting Trust”: Selbst wenn der Quellcode sauber ist, könnte der Compiler kompromittiert sein.

Was Reproducible Builds lösen

Reproducible Builds garantieren, dass jeder, der den Quellcode mit denselben Parametern kompiliert, byte-identisch dasselbe Ergebnis erhält. Wenn du den offiziellen Bitcoin Core Build herunterlädst und ich denselben Code selbst kompiliere, müssen beide Dateien identisch sein. Wenn sie es nicht sind, wurde etwas manipuliert.

Wie du das prüfst

1. Lade die offizielle Release-Datei herunter
2. Lade die SHA256-Checksummen herunter
3. Verifiziere die GPG-Signatur der Checksummen
4. Vergleiche den Hash deiner heruntergeladenen Datei mit dem signierten Hash
5. Optional: Kompiliere den Quellcode selbst und vergleiche

Jeder dieser Schritte ist dokumentiert und für jeden durchführbar. Kein Vertrauen nötig — nur Verifizierung.

GPG-Signaturen: Wer hat was veröffentlicht?

Wie weißt du, dass der Bitcoin Core Download tatsächlich von den Bitcoin Core Entwicklern stammt und nicht von einem Angreifer, der die Website kompromittiert hat?

GPG-Signaturen lösen dieses Problem. Jeder Release wird von mehreren bekannten Entwicklern kryptographisch signiert. Du überprüfst die Signatur mit dem öffentlichen Schlüssel des Entwicklers. Wenn die Signatur gültig ist, stammt die Datei nachweislich von dieser Person und wurde nicht verändert.

Das ist dasselbe Prinzip wie bei Bitcoin-Transaktionen: Private Key signiert, Public Key verifiziert. Die Mathematik ist dieselbe.

Warnzeichen: Wann du misstrauisch sein solltest

Nicht jede Software, die sich “Open Source” nennt, verdient dein Vertrauen. Und nicht jede Closed-Source-Software ist automatisch unsicher. Aber es gibt klare Warnsignale:

Rote Flaggen bei Wallets

• Geschlossener Quellcode — Warum? Was gibt es zu verbergen?
• Kein unabhängiges Audit — Behauptungen ohne Überprüfung sind wertlos
• Eigene Kryptographie — seriöse Projekte nutzen etablierte Bibliotheken, keine selbstgeschriebene Krypto
• Zentralisierte Schlüsselgenerierung — wenn die App den Seed auf einem Server erzeugt, kontrollierst du nichts
• Fehlende Reproducible Builds — Open Source ohne reproduzierbare Kompilate lässt eine Lücke in der Vertrauenskette
• Übertriebenes Marketing — je lauter die Versprechen, desto kritischer solltest du sein

Grüne Flaggen

• Langjähriger Track Record — Software, die seit Jahren im Einsatz ist und regelmäßig aktualisiert wird
• Aktive Review-Kultur — sichtbare Code-Reviews, öffentliche Diskussionen über Sicherheitsentscheidungen
• Mehrere unabhängige Implementierungen — wenn verschiedene Teams denselben Standard implementieren, reduziert das Einzelpunktrisiken
• Transparente Sicherheitsmeldungen — Projekte, die gefundene Bugs öffentlich dokumentieren, sind vertrauenswürdiger als solche, die behaupten, nie welche zu haben

Open Source als Kulturfrage

Open Source bei Bitcoin ist mehr als eine technische Entscheidung. Es ist eine Frage der Werte. Ein Geldsystem, das “Don’t Trust, Verify” predigt, aber auf geschlossener Software läuft, wäre ein Widerspruch in sich.

Die Stärke von Open Source liegt nicht nur darin, dass Bugs gefunden werden. Sie liegt darin, dass die Möglichkeit der Überprüfung das Verhalten aller Beteiligten verändert. Entwickler schreiben besseren Code, wenn sie wissen, dass jeder mitlesen kann. Unternehmen treffen bessere Entscheidungen, wenn sie wissen, dass ihre Software öffentlich geprüft wird. Nutzer treffen informiertere Entscheidungen, wenn sie Zugang zu den Fakten haben.

Open Source ersetzt Vertrauen nicht durch Misstrauen — es ersetzt Vertrauen durch Transparenz.

Weiterführend

• Verifizierung und Open Source — Schritt-für-Schritt: GPG-Signaturen prüfen und Bitcoin Core verifizieren
• Don’t Trust, Verify — Das Prinzip, dem Open Source dient
• PGP: Kryptographie für alle — Die Mathematik hinter GPG-Signaturen
• Adressen und Schlüssel — Dieselbe Kryptographie: Private Key signiert, Public Key verifiziert

Zurück zur Übersicht: Cypherpunk