Jede Behauptung über Bitcoin, die mit "das lässt sich nicht ändern" beginnt, sollte eine einfache Nachfrage aushalten: Wo genau im Code steht das, und warum sollte sich das nicht ändern lassen? In diesem Beitrag beantworten wir das für die wichtigsten Konsensregeln, also die Regeln, die festlegen, was einen Bitcoin-Block überhaupt gültig macht. Wir haben dafür direkt in den offiziellen Quellcode von Bitcoin Core geschaut (Version 31.1) und zeigen dir die konkreten Stellen.
Was "Konsensregel" überhaupt bedeutet
Eine Konsensregel ist eine Regel, die JEDER vollständige Bitcoin-Node im Netzwerk unabhängig voneinander prüft, und zwar exakt gleich. Hält sich ein Block nicht an alle diese Regeln, verwirft ihn jeder korrekt arbeitende Node automatisch, egal wie viel Rechenleistung dahintersteckte oder wer ihn erstellt hat. Das unterscheidet Konsensregeln von bloßen "Hausregeln" einzelner Node-Betreiber (dazu mehr in Teil 4 dieser Serie): Eine Konsensregel zu brechen bedeutet nicht "mein Node mag das nicht", sondern "das gesamte Netzwerk lehnt das ab".
Warum sich nicht einmal die mächtigsten Miner über diese Regeln hinwegsetzen können
An dieser Stelle drängt sich eine naheliegende Frage auf, die eng mit dem Konzept der 51%-Attacke zusammenhängt: Ein einzelnes großes Mining-Unternehmen investiert Millionen in Hardware und Strom. Warum sollte es sich nicht einfach über eine Regel hinwegsetzen, die ihm gerade nicht passt, wenn es doch so viel Rechenleistung hat? Die Antwort liegt in einer bewussten Arbeitsteilung, die im Bitcoin-Design von Anfang an angelegt ist: Rechenleistung entscheidet nur darüber, WER als Erster einen neuen Block vorschlagen darf, nicht darüber, OB dieser Block überhaupt gültig ist. Diese zweite Frage beantwortet ausschließlich die Software jedes einzelnen, auch des kleinsten Nodes, komplett unabhängig von jeder Rechenleistung.
Würde ein Miner also versuchen, z.B. sich selbst mehr als die erlaubten 50 (mittlerweile deutlich weniger) Bitcoin Blockbelohnung zuzuweisen oder eine der weiter unten beschriebenen Prüfungen zu umgehen, prüft jeder einzelne Node weltweit diesen Block gegen exakt dieselbe Codezeile und lehnt ihn bei einem Regelverstoß automatisch ab, komplett unabhängig davon, wie viel Rechenleistung investiert wurde, um ihn zu finden. Der Miner hätte in diesem Fall enorme Kosten (Strom, Hardware-Abnutzung) für einen Block investiert, den am Ende niemand als gültig anerkennt und der ihm schlicht keinen einzigen Bitcoin einbringt. Genau diese Kombination (Rechenleistung entscheidet nur über die Reihenfolge, Software-Regeln entscheiden über die Gültigkeit) ist der eigentliche Grund, warum sich Regelverstöße für niemanden lohnen, egal wie viel Marktmacht er auf den ersten Blick zu haben scheint.
Als "alternative Software" allein nicht reichte: drei gescheiterte Hard Forks
Wie ernst es Bitcoin damit meint, dass eine Regeländerung echte, freiwillige Mehrheitszustimmung braucht, zeigen drei reale Beispiele aus der Bitcoin-Geschichte: Zwischen 2015 und 2017 entstanden mit Bitcoin XT, Bitcoin Classic und Bitcoin Unlimited gleich drei eigenständige Software-Varianten, die jeweils eine unvereinbare Regeländerung (u.a. eine größere Blockgröße) durchsetzen wollten. Jede dieser Varianten war technisch fertig programmierter, lauffähiger Code, und trotzdem kam es in keinem einzigen Fall tatsächlich zu dem beabsichtigten Hard Fork. Der Grund: Eine alternative Software zu schreiben ist nur die notwendige, bei Weitem aber nicht die hinreichende Bedingung für eine echte Regeländerung. Es fehlte in allen drei Fällen an einer ausreichend breiten, gleichzeitigen Zustimmung von Minern, Node-Betreibern und wirtschaftlich relevanten Nutzern. Ohne diese bleibt selbst fertiger, funktionierender Code wirkungslos. Ein eindrucksvoller Gegenbeweis zu der verbreiteten Annahme, jemand mit genug Entwicklerressourcen könnte Bitcoins Regeln im Alleingang verändern.
Wie ein Soft Fork tatsächlich aktiviert wird: Miner-Signalisierung
Die weiter oben beschriebenen Zeitschloss-Befehle sind ein Beispiel für Soft Forks. Aber wie einigt sich das Netzwerk eigentlich konkret auf den Zeitpunkt, ab dem eine neue Regel gilt? Dafür hat Bitcoin ein eigenes Signalisierungsverfahren über das Blockversions-Feld entwickelt, das ebenfalls zweimal weiterentwickelt wurde. Das ältere Verfahren (BIP-34, u.a. für die Einführung der weiter oben erwähnten coinbase-Blockhöhen-Regel genutzt) behandelte die Versionsnummer schlicht als Zahl und verlangte eine Zustimmung von 75 bzw. später 95 Prozent der letzten 1.000 Blöcke.
Das seit 2016 genutzte, verfeinerte Verfahren (BIP-9) macht daraus ein 29-Bit-Bitfeld: Jedes einzelne Bit kann eine eigene, unabhängige Regeländerung repräsentieren, sodass bis zu 29 verschiedene Vorschläge gleichzeitig, unabhängig voneinander signalisiert werden können, statt sich gegenseitig zu blockieren. Jeder Vorschlag durchläuft dabei einen klar definierten Zustandsautomaten: Er beginnt als DEFINED (definiert, aber noch nicht aktiv), wechselt zu einem festgelegten Zeitpunkt zu STARTED (Miner können jetzt aktiv Zustimmung signalisieren), erreicht bei mindestens 95 % Zustimmung innerhalb eines 2016-Block-Zeitraums den Status LOCKED_IN (die Aktivierung ist jetzt technisch beschlossen, aber noch nicht wirksam) und wird schließlich ACTIVE. Wird die 95-Prozent-Schwelle innerhalb einer festgelegten Frist nicht erreicht, verfällt der Vorschlag als FAILED, ohne dass irgendjemand gezwungen würde, ihn zu übernehmen. Dieser gestufte Prozess mit eingebauter Frist ist der eigentliche technische Mechanismus dahinter, dass sich Bitcoin überhaupt kontrolliert weiterentwickeln kann, ohne dass eine einzelne Instanz "jetzt ist es soweit" verkünden müsste.
Die 21-Millionen-Grenze: kein Versprechen, sondern Mathematik
Die bekannteste Bitcoin-Zahl überhaupt ist die feste Obergrenze von 21 Millionen Bitcoin. Wie wird das im Code tatsächlich sichergestellt? Über zwei voneinander unabhängige Mechanismen, was bemerkenswert ist:
Erstens über die Emissionsformel selbst. Die Funktion GetBlockSubsidy in der Datei src/validation.cpp beginnt mit 50 Bitcoin Belohnung pro Block und halbiert diesen Betrag alle 210.000 Blöcke (bei durchschnittlich 10 Minuten pro Block rechnerisch etwa alle vier Jahre). Technisch geschieht das über eine sogenannte Bit-Shift-Operation (nSubsidy >>= halvings), ein Rechentrick, der Zahlen blitzschnell halbiert. Der versteckte Clou dabei: Nach 64 Halbierungen (rechnerisch um das Jahr 2140) ist das Ergebnis nicht "sehr klein", sondern durch diese Rechenoperation exakt null. Die Emission endet also nicht "irgendwann ungefähr", sondern zu einem mathematisch exakt bestimmten Zeitpunkt.
Zweitens, und das wird oft übersehen, existiert die 21-Millionen-Grenze zusätzlich als eigene, separat geprüfte Konstante im Code: MAX_MONEY = 21.000.000 * COIN in der Datei src/consensus/amount.h. Jede einzelne Transaktion im gesamten Netzwerk wird explizit gegen diese Grenze geprüft: Kein Output darf mehr enthalten, keine Summe darf sie überschreiten. Die Grenze ist also nicht nur eine mathematische Konsequenz aus der Halbierungsformel, sondern eine zusätzlich hart im Code verankerte Sicherheitsschranke. Zwei unabhängige Kontrollen für dieselbe Regel: Wer sie ändern wollte, müsste beide gleichzeitig antasten, und das an einer Stelle, an der es jedem einzelnen Node auf der Welt sofort auffallen würde.
Warum ein Block nicht schneller als alle zehn Minuten kommt
Die Zeit zwischen zwei Blöcken soll im Durchschnitt zehn Minuten betragen, nicht weil das technisch nicht schneller ginge, sondern weil es Sicherheit gegen Zeit abwägt (mehr dazu in Teil 3 zu den Skriptregeln). Damit das bei schwankender weltweiter Rechenleistung (die sich über die Jahre um das Millionenfache verändert hat) stabil bleibt, passt sich die "Schwierigkeit" (wie viele Rechenversuche im Schnitt nötig sind, um einen gültigen Block zu finden) automatisch an.
Die Funktion GetNextWorkRequired in src/pow.cpp tut das aber nicht bei jedem einzelnen Block, sondern nur alle 2016 Blöcke (das entspricht bei zehn Minuten pro Block ziemlich genau zwei Wochen). Dazwischen bleibt die Schwierigkeit exakt gleich. Zur Berechnung vergleicht der Code die tatsächlich für die letzten 2016 Blöcke benötigte Zeit mit der Soll-Zeit von zwei Wochen und passt die Schwierigkeit proportional an. Ein cleverer Schutzmechanismus verhindert dabei Manipulation: Die gemessene Zeitspanne wird vor der Berechnung künstlich auf minimal ein Viertel und maximal das Vierfache der Soll-Zeit begrenzt. Selbst wenn ein einzelner Miner versuchen würde, mit einem falschen Zeitstempel zu tricksen, kann die Schwierigkeit dadurch pro Anpassung höchstens um Faktor vier nach oben oder unten springen, nie mehr.
"Die längste Kette gewinnt": fast richtig, aber nicht ganz
Diesen Satz hast du wahrscheinlich schon einmal gehört, und er ist eine der am häufigsten leicht ungenau wiedergegebenen Bitcoin-Aussagen. Tatsächlich gewinnt nicht zwangsläufig die Kette mit den meisten Blöcken, sondern die mit der insgesamt größten nachgewiesenen Rechenarbeit (im Code als nChainWork mitgeführt, verglichen über CBlockIndexWorkComparator in src/chain.h). In der Praxis ist das fast immer dasselbe, weil die Schwierigkeit sich ja gerade so anpasst, dass im Schnitt jeder Block ungefähr gleich viel Arbeit kostet. Bei einer sehr kurzfristigen, extremen Schwierigkeitsänderung könnte eine Kette mit weniger, aber "schwereren" Blöcken jedoch theoretisch eine längere, aber "leichtere" Kette schlagen. Das Whitepaper selbst spricht übrigens schon korrekt von der Kette mit dem größten nachgewiesenen Rechenaufwand. Die Vereinfachung "längste Kette" kam erst später in der allgemeinen Kommunikation dazu.
Wo Regeln aufhören, hart zu sein: Konsens versus Node-Policy
Ein Detail aus dem Code, das viele Missverständnisse in Diskussionen um Bitcoin auflösen kann: Bitcoin Core unterscheidet im Code explizit zwei Ebenen von Regeln. MANDATORY_SCRIPT_VERIFY_FLAGS sind Regeln, deren Verletzung einen Block ungültig macht, das absolute Minimum. STANDARD_SCRIPT_VERIFY_FLAGS sind zusätzliche, strengere Regeln, die ein Node standardmäßig anwendet, um zu entscheiden, was er selbst in seinen eigenen Wartebereich (Mempool) aufnimmt oder selbst mininen würde; ein Verstoß dagegen macht einen bereits fertig geminten Block trotzdem nicht ungültig.
Das erklärt, warum unterschiedliche Node-Software oder unterschiedlich konfigurierte Nodes durchaus leicht unterschiedliche Regeln für den eigenen Mempool anwenden können, ohne dass das Netzwerk deshalb in zwei Ketten zerfällt: Uneinigkeit auf der Policy-Ebene ist normal und harmlos, Uneinigkeit auf der Konsens-Ebene wäre ein Hard Fork. Teil 4 dieser Serie geht genau auf diese Policy-Ebene ein.
Ein technisches Detail mit echter Geschichte: warum bestimmte Prüfungen existieren
Zwei kleine, aber lehrreiche Codestellen zeigen, dass Bitcoins Regeln nicht am Reißbrett entstanden sind, sondern teilweise aus echten, überstandenen Vorfällen: Die Prüfung, dass kein Transaktions-Output einen negativen Wert haben darf, referenziert im Quellcode direkt eine reale, längst behobene Schwachstelle aus der Frühzeit von Bitcoin (öffentlich dokumentiert als CVE-2010-5139), ein Fehler, der es theoretisch erlaubt hätte, Beträge durch einen Zahlenüberlauf zu manipulieren. Ebenso referenziert die Prüfung auf doppelte Eingaben innerhalb derselben Transaktion einen späteren, ebenfalls längst geschlossenen Bug (CVE-2018-17144). Das ist letztlich der beste Beweis für die eingangs erwähnte Idee dieser Serie: Bitcoins Sicherheit basiert nicht auf der Annahme, dass nie etwas schiefgehen kann, sondern auf einem Prozess, bei dem Schwachstellen öffentlich dokumentiert, behoben und für alle Zeit im Code als Erinnerung sichtbar bleiben.
Was noch dazugehört: frisches Geld braucht Reifezeit
Ein letztes, kleines, aber wichtiges Detail: Frisch von einem Miner erzeugte Bitcoin (die Blockbelohnung) können erst nach 100 weiteren Blöcken tatsächlich ausgegeben werden (COINBASE_MATURITY = 100). Der Grund: Sollte es kurzzeitig zu konkurrierenden Ketten kommen und sich am Ende eine andere als die eigene durchsetzen, könnten frisch verdiente, aber sofort weiterverwendete Coins sonst rückwirkend "verschwinden"; mit dieser Wartezeit ist das praktisch ausgeschlossen.
Als die Theorie kurz auf die Praxis traf: die Kettenspaltung von 2013
Wie ernst Bitcoin diese Regeln nimmt, zeigt ein reales, gut dokumentiertes Ereignis aus der Frühzeit: Im März 2013 stellte sich heraus, dass zwei zu diesem Zeitpunkt gleichzeitig im Umlauf befindliche Software-Versionen (0.7 und die kurz zuvor veröffentlichte 0.8) durch eine technische Eigenheit der jeweils verwendeten Datenbank einen bestimmten, ansonsten völlig regelkonformen Block unterschiedlich bewerteten: Die neuere Version akzeptierte ihn, die ältere lehnte ihn ab. Für gut eine Stunde existierten dadurch tatsächlich zwei parallele, jeweils in sich konsistente Versionen der Bitcoin-Blockchain gleichzeitig.
Aufgelöst wurde die Situation nicht durch einen zentralen Eingriff (den es ja gar nicht geben kann), sondern durch genau die Dynamik, die diese Serie beschreibt: Die großen Mining-Pools und Entwickler kommunizierten öffentlich miteinander, einigten sich darauf, vorübergehend zur älteren, kompatibleren Softwareversion zurückzukehren, und die kurze Sekundärkette wurde vom Netzwerk verworfen, sobald die Mehrheit der Rechenleistung wieder auf der ursprünglichen, längeren Kette weiterarbeitete. Niemand verlor dabei bereits bestätigte, ältere Zahlungen, nur die Handvoll Transaktionen aus der kurzen Sekundärkette mussten erneut bestätigt werden. Der Vorfall führte im Nachgang zu strengeren Testverfahren für neue Versionen und ist bis heute ein Lehrbeispiel dafür, wie das Netzwerk auch ganz ohne zentrale Instanz robust auf echte Meinungsverschiedenheiten zwischen Software-Versionen reagieren kann.
Fazit: Regeln, die niemand heimlich verschieben kann
Die 21-Millionen-Grenze, die Schwierigkeitsanpassung, die Kettenwahl-Regel: All das sind keine Marketingversprechen, sondern konkrete, für jeden einsehbare Zeilen in einer öffentlichen Codebasis, die von tausenden unabhängigen Nodes weltweit gleichzeitig geprüft wird. Eine Änderung würde nicht nur bedeuten, den Code anzupassen, sondern auch, dass die überwältigende Mehrheit aller Node-Betreiber und Miner weltweit sich freiwillig entscheidet, genau diese veränderte Version zu übernehmen, gegen alle wirtschaftlichen Anreize, die für das Gegenteil sprechen.
Weiter geht's mit Teil 3: Von Skripten zu Taproot: Wie eine Bitcoin-Transaktion technisch wirklich funktioniert.
