"Don't trust, verify" ist einer der meistzitierten Sätze der Bitcoin-Szene, aber was heißt das eigentlich konkret? Die ehrliche Antwort: Es heißt, dass jeder, der es wirklich wissen will, den Quellcode selbst lesen kann, der Bitcoin am Laufen hält. Keine Blackbox, keine Bank, die "vertrau uns einfach" sagt, sondern öffentlicher, von tausenden Augen geprüfter Code. Das ist eine steile Behauptung, und diese Beitragsreihe ist der Versuch, sie einzulösen: Wir öffnen gemeinsam die Motorhaube und schauen uns an, was darunter tatsächlich passiert. Ohne Informatikstudium, aber auch ohne Vereinfachung bis zur Unkenntlichkeit.

Dieser erste Beitrag ist die Landkarte für die gesamte Serie. Er erklärt, woher der Bitcoin-Code eigentlich kommt, wer ihn geschrieben hat und wer ihn heute weiterentwickelt, wie groß er tatsächlich ist, und er gibt dir einen kompletten, verständlichen Überblick darüber, wie Bitcoin technisch funktioniert, bevor wir in den folgenden sieben Beiträgen tief in einzelne Bausteine eintauchen.

Woher kommt der Bitcoin-Code eigentlich?

Am 31. Oktober 2008 veröffentlichte eine Person (oder Gruppe) unter dem Pseudonym Satoshi Nakamoto ein neunseitiges technisches Dokument mit dem Titel "Bitcoin: A Peer-to-Peer Electronic Cash System" auf einer Kryptografie-Mailingliste. Dieses Whitepaper beschreibt die Idee auf konzeptioneller Ebene: ein elektronisches Zahlungssystem, das ohne Bank oder sonstige vertrauenswürdige dritte Partei auskommt. Das Original-Whitepaper kannst du dir hier direkt anschauen: bitcoin.org/bitcoin.pdf. Es lohnt sich, es einmal gelesen zu haben, allein schon, weil fast jede spätere technische Entscheidung in Bitcoin letztlich darauf zurückgeht.

Auf die Idee folgte drei Monate später der Beweis, dass sie funktioniert: Am 3. Januar 2009 minte Satoshi Nakamoto den allerersten Bitcoin-Block, den sogenannten Genesis-Block, mit seiner eigenen, selbst geschriebenen Software, Version 0.1 der Bitcoin-Client-Software. Das ist der eigentliche Ursprung des heutigen Codes: Kein Konzern hat Bitcoin "gegründet", kein Startup hat Investorengeld genommen und einen Programmierer beauftragt. Eine einzelne Person hat eine Idee direkt selbst in funktionierenden Code gegossen und veröffentlicht.

Satoshi Nakamoto blieb bis etwa Ende 2010 aktiv an der Weiterentwicklung beteiligt, übergab die Verantwortung dann schrittweise an andere frühe Mitstreiter, allen voran den Softwareentwickler Gavin Andresen, und verschwand danach komplett aus der Öffentlichkeit. Bis heute ist die wahre Identität hinter dem Pseudonym nicht zweifelsfrei geklärt. Das ist kein Makel, sondern beinahe folgerichtig: Ein System, das gerade davon lebt, dass niemand eine Sonderstellung hat, kann es sich schlecht leisten, an einer einzelnen, unersetzlichen Gründerfigur zu hängen. Nach Satoshis Rückzug übernahm eine wachsende Gemeinschaft unabhängiger Entwickler die Weiterentwicklung, aus der ursprünglichen "Bitcoin"-Software wurde 2014 offiziell das Projekt, das wir heute als Bitcoin Core kennen: die mit Abstand am weitesten verbreitete Implementierung der Bitcoin-Regeln, gepflegt von einer offenen, weltweiten Gemeinschaft von Freiwilligen und einigen wenigen bezahlten Entwicklern (finanziert u.a. über Stiftungen und Unternehmen aus dem Bitcoin-Umfeld, nicht über eine zentrale Firma, die das Projekt besitzt).

Wo der Code liegt und wie er verändert wird

Der komplette Quellcode von Bitcoin Core liegt öffentlich einsehbar auf GitHub unter github.com/bitcoin/bitcoin, für jeden, jederzeit, kostenlos herunterladbar, unter der sehr freizügigen MIT-Lizenz. Das bedeutet konkret: Jeder darf den Code lesen, kopieren, verändern und sogar eine eigene, abgewandelte Version davon veröffentlichen. Es gibt keinen Passwortschutz, keine "Enterprise-Version", keine Geheimhaltung.

Wie entsteht daraus aber die tatsächlich laufende Software, der Millionen Nutzer weltweit ihr Geld anvertrauen? Über einen erstaunlich unspektakulären, aber wirkungsvollen Prozess:

  1. Vorschlag. Jeder, buchstäblich jeder mit einem GitHub-Account, kann eine Änderung vorschlagen ("Pull Request"). Das reicht von der Behebung eines Tippfehlers in der Dokumentation bis zu tiefgreifenden Optimierungen an der Kernlogik.
  2. Offene Diskussion und Code-Review. Andere Entwickler aus aller Welt, oft Dutzende bei wichtigeren Änderungen, lesen den vorgeschlagenen Code, kommentieren, finden Fehler, schlagen Alternativen vor. Diese Diskussionen sind komplett öffentlich einsehbar.
  3. Für tiefgreifende Regeländerungen: das BIP-Verfahren. Größere, grundsätzliche Vorschläge werden zusätzlich als "Bitcoin Improvement Proposal" (BIP) formal dokumentiert und öffentlich diskutiert, bevor überhaupt Code dafür geschrieben wird, vergleichbar mit einem Gesetzesentwurf, der erst debattiert wird, bevor er in Kraft tritt.
  4. Zusammenführung durch Maintainer. Eine kleine Gruppe erfahrener, langjähriger Mitwirkender (aktuell mehrere Personen, keine Einzelperson) darf akzeptierte Änderungen offiziell in den Hauptcode übernehmen ("mergen"), aber nur nach ausreichender Prüfung durch andere.
  5. Der entscheidende letzte Schritt: freiwillige Übernahme. Und hier liegt der eigentliche Clou, der Bitcoin fundamental von jeder Software unterscheidet, die eine Firma kontrolliert: Selbst wenn eine Änderung in den offiziellen Bitcoin-Core-Code aufgenommen wird, passiert erst einmal: nichts. Jeder Node-Betreiber und jeder Miner weltweit muss die neue Software-Version freiwillig selbst herunterladen und installieren, damit die Änderung überhaupt wirksam wird. Niemand kann eine Regeländerung "von oben" durchsetzen. Genau darum geht es im übernächsten Beitrag dieser Serie im Detail: um die Konsensregeln, die genau deshalb so unbestechlich sind, weil niemand sie einseitig verändern kann.

Diese Struktur ist der eigentliche Kern des Vertrauens, um das es in dieser Serie geht: Du musst niemandem persönlich vertrauen, weder Satoshi Nakamoto noch den heutigen Maintainern, weil jede Behauptung über die Funktionsweise am Ende im offen einsehbaren Code überprüfbar ist, und weil niemand eine Änderung erzwingen kann, die die Mehrheit der Netzwerkteilnehmer nicht mitträgt.

Der Code in Zahlen: qualitativ und quantitativ

Wie groß ist dieses Projekt eigentlich tatsächlich? Für diese Beitragsreihe haben wir den offiziellen Code (Version 31.1, Stand September 2026) selbst heruntergeladen und ausgezählt, statt nur Behauptungen zu übernehmen:

Kernlogik (C++)
≈ 224.000
Zeilen Code
Automatisierte Tests
≈ 174.000
Zeilen (Unit + Funktionstests)
Dateien im Projekt
≈ 2.900
Quellcode, Doku, Build-Skripte

Die vielleicht aufschlussreichste Zahl ist dabei nicht die Größe der eigentlichen Kernlogik (rund 224.000 Zeilen C++, der Sprache, die für performance-kritische Systemsoftware wie Betriebssysteme oder eben Finanzinfrastruktur seit Jahrzehnten Standard ist), sondern das Verhältnis zu den Tests: Es existieren fast ebenso viele Zeilen automatisierter Testcode wie eigentlicher Programmcode, etwa 92.000 Zeilen klassische Unit- und Performance-Tests (in derselben Sprache C++) sowie noch einmal rund 81.000 Zeilen sogenannter Funktionstests, geschrieben in der Sprache Python, die das Zusammenspiel mehrerer kompletter, simulierter Bitcoin-Nodes im Zusammenspiel prüfen. Anders gesagt: Für jede Zeile, die tatsächlich etwas mit echtem Geld anstellt, existiert eine fast gleich lange Zeile, deren einziger Job es ist, zu beweisen, dass die erste Zeile sich korrekt verhält. Bei Software, die kein Backup-Team, keinen Kundenservice und keine Möglichkeit hat, eine fehlerhafte Transaktion nachträglich rückgängig zu machen, ist das kein Luxus, sondern die Grundvoraussetzung, damit überhaupt jemand sein Geld darauf verwahren sollte.

Veröffentlicht wird jede neue Version öffentlich über GitHub sowie über bitcoincore.org, zusammen mit digitalen Signaturen mehrerer unabhängiger Entwickler, mit denen jeder selbst nachprüfen kann, dass die heruntergeladene Datei tatsächlich unverändert dem geprüften, öffentlichen Quellcode entspricht.

Wie Bitcoin technisch grundsätzlich funktioniert: Der große Überblick

Bevor wir in den nächsten sieben Beiträgen tief in einzelne Bausteine eintauchen, hier der Gesamtzusammenhang in einem Durchgang: die Reise, die eine einzelne Bitcoin-Zahlung technisch durchläuft:

  1. Du erstellst eine Transaktion. Deine Wallet-Software wählt passende, dir gehörende, noch nicht ausgegebene Bitcoin-Beträge aus (technisch: UTXOs, "Unspent Transaction Outputs") und signiert digital, dass du sie an eine bestimmte Adresse überweisen möchtest.
  2. Deine Wallet verschickt die Transaktion ins Netzwerk. Über das Peer-to-Peer-Netzwerk, ohne zentralen Server, wird sie an benachbarte Nodes weitergereicht, die sie wiederum an ihre eigenen Nachbarn weiterleiten, bis praktisch jeder aktive Node weltweit sie kennt.
  3. Jeder Node prüft sie eigenständig. Bevor eine Transaktion überhaupt akzeptiert und weitergeleitet wird, prüft jeder einzelne Node unabhängig von allen anderen: Sind die Signaturen gültig? Wurden die verwendeten Beträge nicht bereits anderweitig ausgegeben? Hält sich die Transaktion an alle festen Regeln? Erst danach landet sie im "Wartezimmer" jedes Nodes, dem sogenannten Mempool.
  4. Miner bündeln wartende Transaktionen zu einem Block. Weltweit verteilte Miner wählen Transaktionen aus dem Mempool aus (meist die mit den höchsten Gebühren zuerst) und versuchen, für einen neuen Block einen extrem seltenen digitalen "Beweis" zu finden, Proof of Work genannt, der enorme Rechenleistung erfordert, aber von jedem anderen in Sekundenbruchteilen überprüft werden kann.
  5. Der neue Block wird im Netzwerk verteilt und erneut von allen geprüft. Findet ein Miner diesen Beweis, verschickt er den fertigen Block, auch hier prüft wieder jeder einzelne Node unabhängig, ob wirklich alle enthaltenen Regeln eingehalten wurden, bevor der Block akzeptiert wird.
  6. Die Kette mit der meisten nachgewiesenen Arbeit gewinnt. Sollten kurzzeitig zwei konkurrierende Versionen der Blockchain existieren (z.B. weil zwei Miner fast gleichzeitig einen gültigen Block gefunden haben), einigt sich das Netzwerk automatisch auf die Version, in die insgesamt am meisten nachweisbare Rechenarbeit geflossen ist.
  7. Deine Wallet erkennt die Bestätigung und aktualisiert deinen Kontostand. Sobald deine Transaktion Teil eines akzeptierten Blocks ist, gilt sie als bestätigt, mit jedem weiteren Block, der obendrauf gebaut wird, wird eine Rückabwicklung praktisch unmöglicher.

Jeder einzelne dieser sieben Schritte hat seine eigene, faszinierende technische Geschichte, und genau dorthin führt dich diese Serie.

Was dich in dieser Serie erwartet

Der rote Faden durch alle acht Beiträge bleibt derselbe: Nichts davon musst du irgendjemandem glauben. Jede hier beschriebene Regel steht wortwörtlich im öffentlichen Quellcode, den jeder selbst nachlesen kann, wir verlinken bei jedem technischen Detail auf die genaue Stelle im Code. Das ist der Unterschied zwischen einem Zahlungssystem, dem man vertrauen soll, und einem, das man selbst überprüfen kann.

Weiter geht's mit Teil 2: Die unbestechlichen Regeln, Bitcoins Konsensmechanismus erklärt.