Bitcoin Core Tests prüfen jede Änderung an der Referenzsoftware. Doch wer prüft die Tests selbst? Mutationstests bauen absichtlich Fehler ein und zeigen so, wo die Prüfung Lücken hat.

Bitcoin Core Tests als Sicherheitsnetz

Bitcoin Core Tests sollen sicherstellen, dass keine Änderung an der Referenzsoftware das Netzwerk beschädigt. Doch ein Test ist selbst nur Code und kann Fehler übersehen. Dem Bitcoin-Entwickler Greg Maxwell wird dazu ein zugespitzter Gedanke zugeschrieben: Die Software prüft den Test, und wer den Test prüfen will, muss die Software absichtlich kaputt machen.

Bitcoin Core arbeitet mit mehreren Prüfebenen. Unit-Tests kontrollieren einzelne Funktionen isoliert. Funktionale Tests starten echte Knoten und sprechen sie über RPC- und P2P-Schnittstellen an. Sie prüfen, ob mehrere Knoten untereinander korrekt Blöcke und Transaktionen austauschen.

Hinzu kommt Fuzzing, bei dem Programme mit zufällig erzeugten Eingaben beschossen werden. Diese Schichten fangen viele Fehler ab, bevor Code in eine Version gelangt. Ob sie wirklich alles Wichtige abdecken, lässt sich aus ihnen selbst aber nicht ablesen.

Mutationstests prüfen die Prüfer

Genau hier setzt der Test des Tests an. Beim Mutationstest werden gezielt kleine Fehler in den Quellcode eingebaut, etwa ein vertauschtes Vergleichszeichen oder eine gelöschte Bedingung. Schlagen die Tests danach fehl, haben sie den sogenannten Mutanten erkannt. Laufen sie trotzdem fehlerfrei durch, ist eine Lücke gefunden.

Eine Studie aus dem Jahr 2023 hat dieses Verfahren auf Bitcoin Core angewendet. Ergebnis: Fuzzing und funktionale Tests ersetzen einander nicht, sie decken unterschiedliche Schwachstellen auf. Gerade die Kombination mehrerer Verfahren macht die Prüfung belastbarer. Inzwischen veröffentlicht das Projekt eigene Berichte dazu, wie gut Bitcoin Core Tests eingebaute Mutanten erkennen.

Bitcoin Core Tests und dezentrale Kontrolle

Für die Frage, ob Bitcoin Core dezentral ist, sind die Tests mehr als Technik. Der gesamte Code und alle Bitcoin Core Tests sind öffentlich. Jeder kann sie ausführen, Mutanten einbauen und Schwächen melden, ohne um Erlaubnis zu fragen. Kein Unternehmen und keine Behörde entscheidet, welche Prüfung als ausreichend gilt.

Ein Test ist nur so gut wie seine Fähigkeit, Fehler tatsächlich zu erkennen, und das lässt sich nur durch bewusstes Zerstören prüfen. Dahinter steht ein Gedanke, den Friedrich August von Hayek für Märkte beschrieben hat. Wissen ist verstreut, und keine zentrale Stelle kann alle Fehler vorhersehen. Offene Prüfverfahren nutzen dieses verstreute Wissen, weil viele unabhängige Entwickler unterschiedliche Schwachstellen finden.

Für Bitcoin ist das zentral. Ein Geld mit einem fixen Angebot von 21 Mio. BTC und Proof-of-Work verdient nur Vertrauen, wenn die Regeln im Code verlässlich durchgesetzt werden. Harte Geldregeln brauchen deshalb harte Prüfungen, die jeder nachvollziehen kann.

Einschränkend gilt: Öffentlicher Code bedeutet nicht, dass ihn tatsächlich viele prüfen. In der Praxis trägt eine kleine Gruppe erfahrener Entwickler einen Großteil der Prüfarbeit. Auch Mutationstests beweisen nicht, dass Software fehlerfrei ist, sie zeigen nur, wo Tests schwach sind. Offenheit ist daher eine Voraussetzung für Dezentralität, keine Garantie.

Im vorherigen Bildungsartikel berichteten wir über Bitcoin Code Integration: Jeder Knoten entscheidet selbst.

Die Bitcoin Code Integration folgt keinem zentralen Plan. Bitcoin Core hat keine automatische Aktualisierung, deshalb entscheidet jeder Knotenbetreiber selbst über neuen Code.

Bitcoin Code Integration ohne zentrale Instanz

Die Bitcoin Code Integration beginnt erst, wenn die Qualitäts- und Integrationsprüfung eines neuen Codes abgeschlossen ist. Damit ist der Code aber noch nicht im Netzwerk aktiv. Es gibt keine Organisation, die ihn zentral ausrollt. Jeder Knotenbetreiber entscheidet selbst, ob er die neue Version installiert.

Bei Banksoftware oder Betriebssystemen ist das anders. Dort bestimmt ein Anbieter, wann eine neue Version gilt, und die Nutzer übernehmen sie. Bei Bitcoin liegt diese Entscheidung bei Tausenden unabhängigen Knoten. Jeder Knoten prüft Transaktionen und Blöcke selbst nach den Regeln seiner installierten Software.

Entwickler können Code schreiben, prüfen und veröffentlichen. Sie können aber niemanden zwingen, ihn auszuführen. Die Freigabe einer Version ist ein Angebot, keine Anweisung.

Software ohne Aktualisierungsfunktion

Bitcoin Core besitzt bewusst keine automatische Aktualisierungsfunktion. Das Projekt begründet dies damit, dass die Teilnahme an jeder Regeländerung freiwillig bleiben soll. Wie ein vollständiger Knoten dabei arbeitet, erklärt das Bitcoin Wiki ausführlich. Eine eingebaute Update-Funktion wäre zudem ein zentraler Angriffspunkt, über den fremder Code auf viele Rechner gelangen könnte.

In der Praxis laufen daher stets mehrere Versionen parallel im Netz. Wer eine Änderung ablehnt, bleibt bei der alten Version oder wechselt zu einer anderen Implementierung wie Bitcoin Knots. Neue Konsensregeln setzen sich nur durch, wenn ausreichend viele Knoten sie freiwillig übernehmen.

Freiwillige Zustimmung als Ordnungsprinzip

Die Bitcoin Code Integration zeigt, dass das dezentrale Netzwerk selbst über neuen Code entscheidet. Prüfung und Veröffentlichung sind Aufgaben der Entwickler, die Übernahme bleibt Sache der Knotenbetreiber. So entsteht ein Gleichgewicht, in dem keine Gruppe allein die Regeln ändern kann.

Ökonomisch lässt sich das mit der spontanen Ordnung nach Friedrich August von Hayek beschreiben. Ordnung entsteht hier nicht durch Planung von oben, sondern aus vielen einzelnen Entscheidungen. Jeder Knotenbetreiber wägt nach seinem subjektiven Urteil ab, ob eine Änderung ihm nützt. Der Konsens ist das Ergebnis dieser Abwägungen und kein Beschluss einer Behörde.

Für Bitcoin als hartes Geld ist das wesentlich. Die Obergrenze von 21 Mio. BTC und die Regeln von Proof-of-Work sind nur so fest, wie die Knoten sie durchsetzen. Weil kein Akteur ein Update erzwingen kann, ist eine stille Ausweitung der Geldmenge erheblich erschwert. Darin liegt der Unterschied zu Fiat-Geld, dessen Regeln eine Zentralbank ändern kann.

Einschränkend gilt: Die Theorie der freien Wahl stößt in der Praxis auf Grenzen. Viele Betreiber übernehmen Updates ohne eigene Prüfung, und Miner, Börsen sowie große Dienstleister haben mehr Einfluss als ein einzelner Heimknoten. Wie stark die Macht im Netzwerk tatsächlich verteilt ist, bleibt Gegenstand der Debatte.

Im vorherigen Bildungsartikel berichteten wir über Reproduzierbare Builds: Wie Bitcoin Core Manipulation verhindert.

Reproduzierbare Builds sorgen dafür, dass mehrere Entwickler unabhängig voneinander identische Binärdateien von Bitcoin Core erzeugen. Erst wenn alle Ergebnisse übereinstimmen, wird signiert und veröffentlicht.

Reproduzierbare Builds als Prüfverfahren

Reproduzierbare Builds sind das Verfahren, mit dem Bitcoin Core aus offenem Quellcode ein überprüfbares Programm macht. Mehrere Entwickler erstellen unabhängig voneinander dieselbe Binärdatei. Weichen ihre Ergebnisse voneinander ab, wird nichts veröffentlicht.

Quellcode ist für Menschen lesbar, die Binärdatei dagegen nicht. Wer Bitcoin Core herunterlädt, startet in der Regel eine fertig übersetzte Datei. Ohne Kontrolle könnte genau an dieser Stelle manipulierter Code eingeschleust werden, etwa durch einen kompromittierten Rechner oder einen veränderten Compiler.

Das Build-System setzt deshalb auf Determinismus. Aus demselben Quellcode und derselben Toolkette muss Bit für Bit dieselbe Datei entstehen. Seit Version 22.0 aus dem Jahr 2021 nutzt Bitcoin Core dafür das Werkzeug GNU Guix, das den älteren Gitian-Prozess abgelöst hat.

Signaturen statt Vertrauen in Einzelne

Mehrere Entwickler bauen die Software auf eigenen Systemen und vergleichen die kryptografischen Prüfsummen der Ergebnisse. Erst wenn alle Prüfsummen übereinstimmen, signieren sie das Ergebnis mit ihrem Schlüssel.

Diese Signatur bestätigt drei Dinge: Die Binärdatei ist nicht manipuliert, die Toolkette ist unverändert, und alle haben denselben Quellcode verwendet. Die Signaturen werden öffentlich in einem eigenen Verzeichnis gesammelt. Wie Guix die Entwicklung vertrauensloser macht, zeigt eine technische Analyse ausführlich. Jeder kann den Build selbst wiederholen und eine eigene Signatur beitragen.

Reproduzierbare Builds und dezentrale Ordnung

Das Build-System beseitigt einzelne Fehlerpunkte im Erstellungs- und Verteilungsprozess. Kein einzelner Entwickler, kein Server und kein Compiler muss blind vertrauenswürdig sein. Abweichungen werden sichtbar, bevor eine Version Nutzer erreicht.

Reproduzierbare Builds übertragen damit das Kernprinzip von Bitcoin auf die Software selbst. Nicht Autorität erzeugt Vertrauen, sondern unabhängige Überprüfung. Friedrich August von Hayek beschrieb, wie Ordnung aus dem Zusammenspiel vieler Einzelner entsteht, ohne dass eine zentrale Instanz sie plant. Das Build-System funktioniert ähnlich: Sicherheit entsteht aus vielen Prüfern, die sich gegenseitig kontrollieren.

Für Bitcoin ist das folgerichtig. Ein Geld mit fixem Angebot von 21 Mio. BTC und Proof-of-Work verliert seinen Wert, wenn die Software, die diese Regeln durchsetzt, heimlich verändert werden kann. Hartes Geld braucht deshalb auch eine harte, überprüfbare Lieferkette.

Grenzen gibt es trotzdem. In der Praxis prüfen nur wenige Nutzer selbst nach und verlassen sich auf die Signaturen anderer. Reproduzierbare Builds schützen zudem nicht vor Fehlern, die bereits im geprüften Quellcode stecken. Sie sichern den Weg vom Code zur Datei, nicht die Qualität des Codes.

Im vorherigen Bildungsartikel berichteten wir über Pull Request: Wie neuer Code in Bitcoin Core gelangt.

Ein Pull Request ist der offene Vorschlag, mit dem neuer Code in Bitcoin Core gelangt. Erst nach Peer Review und ohne begründete Einwände führen die Maintainer die Code-Integration durch.

Der Pull Request als offener Vorschlag

Ein Pull Request ist der Weg, auf dem neuer Code in Bitcoin Core gelangt, die meistgenutzte Software im Bitcoin-Netzwerk. Jeder Entwickler kann einen solchen Vorschlag einreichen, ohne Anmeldung bei einer Behörde und ohne Firmenzugehörigkeit. Entscheidend ist nicht, wer den Code schreibt, sondern ob er der Prüfung standhält.

Technisch funktioniert das so: Ein Entwickler kopiert das öffentliche Code-Archiv, ändert einzelne Stellen und bittet anschließend darum, diese Änderung in den Hauptzweig zu übernehmen. Diese Bitte ist der Pull Request. Sie enthält den geänderten Code, eine Begründung und oft Tests. Ab diesem Moment ist der Vorschlag für alle sichtbar und kommentierbar.

Prüfung durch Gutachter und Maintainer

Nach dem Einreichen beginnt das Peer Review. Andere Entwickler lesen den Code, testen ihn und geben Rückmeldungen. Zustimmung wird mit „ACK“ signalisiert, Ablehnung mit „NACK“. Ein NACK muss technisch begründet sein, sonst kann er unberücksichtigt bleiben. Gesucht wird vor allem nach Fehlern, Sicherheitslücken und schädlichem Code.

Die Regeln dafür sind öffentlich dokumentiert, ein Überblick findet sich auf der Entwicklerseite von bitcoin.org. Die Maintainer werten die Rückmeldungen aus. Gibt es keine vernünftigen Einwände mehr, führen sie die Code-Integration durch, den sogenannten Merge. Sie entscheiden damit nicht nach eigenem Geschmack, sondern stellen fest, ob ein grober Konsens besteht.

Grober Konsens statt Abstimmung

Dieser grobe Konsens ist keine Mehrheitswahl. Ein gut begründeter Einwand kann mehr Gewicht haben als viele beiläufige Zustimmungen. Deshalb bleiben manche Vorschläge monatelang offen, während kleine Korrekturen schnell übernommen werden. Kritiker bemängeln, dass Merge-Entscheidungen nicht immer begründet werden.

Kurz gesagt: Ein Pull Request ist ein öffentlicher Vorschlag, der erst nach offener Prüfung und ohne begründete Einwände Teil von Bitcoin Core wird. Niemand verfügt über ein Recht zur Durchsetzung, jeder hat ein Recht zur Prüfung. Friedrich August von Hayek beschrieb solche Strukturen als spontane Ordnung: Regeln entstehen aus dem Zusammenspiel vieler Akteure, nicht aus zentraler Planung. Wissen ist verteilt, und kein Einzelner kann es vollständig bündeln.

Zu Bitcoin passt dieses Verfahren. Ein Geld mit fixem Angebot von 21 Mio. BTC und Proof-of-Work verliert seinen Wert als hartes Geld, wenn eine kleine Gruppe die Regeln beliebig ändern könnte. Die offene Code-Integration erschwert genau das. Zudem entscheidet jeder Knotenbetreiber selbst, welche Software er ausführt. Ein Merge in Bitcoin Core ist daher noch keine Regeländerung des Netzwerks.

Es gibt aber eine Einschränkung: Die Theorie der offenen Teilnahme trifft in der Praxis auf wenige erfahrene Gutachter und begrenzte Zeit. Wie dezentral die Entwicklung tatsächlich ist, bleibt umstritten. Der Mechanismus senkt das Risiko willkürlicher Eingriffe, garantiert aber keine perfekte Entscheidung.

Im vorherigen Bildungsartikel berichteten wir über Bitcoin Core Maintainer: Hausmeister statt Herrscher.

Bitcoin Core Maintainer führen geprüften Code zusammen und signieren jeden Merge-Commit mit ihrem Schlüssel. Ihre Rolle gleicht eher einer Hausmeistertätigkeit als einer Machtposition, auch wenn der öffentliche Druck hoch ist.

Die Aufgabe der Bitcoin Core Maintainer

Bitcoin Core Maintainer sind die wenigen Entwickler, die Änderungen in das Hauptrepository von Bitcoin Core übernehmen dürfen. Ihre Rolle wird oft missverstanden. Von außen gelten sie als mächtige Torwächter, tatsächlich sind sie eher Verwalter eines offenen Prozesses.

Jeder kann Code vorschlagen, prüfen und kommentieren, eine Mitgliedschaft oder Erlaubnis braucht es dafür nicht. Die Maintainer führen einen Vorschlag erst zusammen, wenn er ausreichend begutachtet wurde und unter den Mitwirkenden ein grober Konsens besteht. Bitcoin Core beschreibt diese Tätigkeit selbst als Hausmeisteraufgabe und ausdrücklich nicht als Privileg.

Zum Alltag gehört, das Protokoll zu prüfen, Schwachstellen früh zu erkennen und die Kompatibilität mit anderen Implementierungen zu sichern. Ihre Arbeit ist unauffällig, für die Stabilität des Netzwerks aber zentral.

Mehrschichtige Sicherheit im Entwicklungsprozess

Jeder Merge-Commit wird von einem Bitcoin Core Maintainer mit seinem persönlichen PGP-Schlüssel signiert. Welche Schlüssel dafür zugelassen sind, steht in einer öffentlichen Datei namens trusted-keys im Repository. Ein automatisches Prüfskript kontrolliert, ob jede Zusammenführung tatsächlich von einem dieser Schlüssel stammt. Eine Übersicht über Aufbau und Geschichte des Projekts bietet das Bitcoin Wiki.

Das Ergebnis ist mehrschichtige Sicherheit. Autoren, Reviewer und Maintainer sind verschiedene Personen, und jede Schicht muss ein Angreifer einzeln überwinden. Hohes Vertrauen in einzelne Personen entsteht dadurch nicht. Ein kompromittierter Schlüssel fiele womöglich erst auf, wenn sein Besitzer die anderen Maintainer warnt.

Bitcoin Core Maintainer zwischen Pflicht und Macht

Trotz begrenzter Befugnisse stehen die Maintainer unter hohem öffentlichem Druck. Kritiker sprechen von einer Technokratie, in der wenige Experten über ein globales Geldsystem entscheiden. Doch jeder Knotenbetreiber wählt selbst, welche Software er ausführt. Ein Update, das die Mehrheit der Nutzer ablehnt, bleibt wirkungslos.

Ein Bitcoin Core Maintainer kann Code zusammenführen, aber niemanden zwingen, ihn zu installieren. Signaturen, Reviews und offene Prüfskripte verteilen die Verantwortung auf viele Schultern. Kein einzelner Akteur kann so unbemerkt Schadcode einschleusen.

Friedrich August von Hayek beschrieb solche Strukturen als spontane Ordnung, die aus freiwilliger Mitwirkung entsteht statt aus zentraler Anordnung. Bitcoin überträgt dieses Prinzip auf Geld. Das feste Angebot von 21 Mio. BTC und der Proof-of-Work lassen sich nicht per Merge ändern, solange die Knoten im Netzwerk nicht zustimmen.

Die These der machtlosen Maintainer bleibt allerdings Theorie. In der Praxis beeinflussen sie, welche Vorschläge Aufmerksamkeit bekommen und wie schnell sie vorankommen. Wie groß dieser informelle Einfluss ist, wird weiter debattiert.

Im vorherigen Bildungsartikel berichteten wir über Signierte Merge-Commits: Wie Bitcoin Core GitHub misstraut.

Signierte Merge-Commits stellen sicher, dass bei Bitcoin Core nur Code übernommen wird, den freiwillige Maintainer mit ihrem Schlüssel freigegeben haben. Der Artikel erklärt, warum das Projekt GitHub als Plattform bewusst nicht vertraut.

Signierte Merge-Commits im Bitcoin Core Ablauf

Signierte Merge-Commits sind der Punkt, an dem bei Bitcoin Core aus einem Vorschlag tatsächlicher Code wird. Nur wenige freiwillige Entwickler, die Maintainer, dürfen geprüfte Änderungen in das Hauptprojekt übernehmen. Jede dieser Freigaben versehen sie mit einer kryptografischen Signatur. So lässt sich später nachweisen, wer eine Änderung genehmigt hat.

Der Ablauf beginnt mit einem Pull Request, den jeder einreichen kann. Andere Entwickler prüfen den Code öffentlich, testen ihn und kommentieren ihn. Erst bei ausreichender Zustimmung führt ein Maintainer den Merge durch. Die Rolle ist also eher Verwaltung als Befehlsgewalt.

Warum GitHub kein Vertrauensanker ist

Bitcoin Core liegt auf GitHub, doch die Plattform gilt im Projekt nicht als vertrauenswürdig. Eine beliebige Anzahl an GitHub-Mitarbeitern verfügt über administrative Rechte und könnte diese theoretisch ausnutzen. Ein Angreifer bei GitHub könnte zudem versuchen, Zugangsschlüssel eines Bitcoin Core Entwicklers zu stehlen. Ein gekapertes Konto allein darf deshalb nie reichen, um Code einzuschleusen.

Die Antwort sind PGP-Schlüssel, die außerhalb von GitHub liegen. Eine öffentliche Liste vertrauenswürdiger Schlüssel und ein Prüfskript im Repository erlauben jedem, die Signatur jedes Merge-Commits nachzurechnen. Die Projektbeschreibung von Bitcoin Core zeigt, wie offen die Entwicklung organisiert ist. Vollständigen Schutz bietet das nicht: Ein gestohlener PGP-Schlüssel fällt womöglich erst auf, wenn sein Besitzer den Diebstahl meldet.

Signierte Merge-Commits als Prinzip

Signierte Merge-Commits verlagern Vertrauen von einer Firma auf überprüfbare Mathematik. Nicht GitHub entscheidet, welcher Code gültig ist, sondern die Signatur eines bekannten Schlüssels. Wer zweifelt, prüft selbst, statt einer Plattform zu glauben.

Damit sichern signierte Merge-Commits die Schnittstelle zwischen offener Diskussion und tatsächlich übernommenem Code ab. Die Österreichische Schule liefert dafür eine passende Deutung: Macht konzentriert sich dort, wo Kontrolle unüberprüfbar bleibt. Gute Ordnungen begrenzen diese Macht durch Regeln, die jeder Beteiligte selbst kontrollieren kann. Saifedean Ammous beschreibt Bitcoin als Geld, dessen Regeln sich nicht durch eine zentrale Autorität verändern lassen.

Bitcoin überträgt diesen Gedanken auf mehrere Ebenen. Proof-of-Work sichert das Kassenbuch, die Obergrenze von 21 Mio. BTC sichert das Angebot, und signierte Freigaben sichern den Code der Referenzsoftware. Entscheidend bleibt, dass kein Maintainer die Konsensregeln allein ändern kann, denn jeder Knotenbetreiber wählt seine Software selbst.

Einschränkend gilt: Das Prüfskript ist laut eigener Dokumentation ein unfertiges Werkzeug, und nur wenige Nutzer verifizieren Signaturen tatsächlich. Die Sicherheit ist in der Theorie stark, in der Praxis hängt sie von der Wachsamkeit der Community ab.

Im vorherigen Bildungsartikel berichteten wir ueber Bitcoin Core Geschichte: Von SourceForge zu GitHub und transparenten Merge-Commits.