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: vier gescheiterte Versuche
Wie ernst es Bitcoin damit meint, dass eine Regeländerung echte, freiwillige Mehrheitszustimmung braucht, zeigen vier reale Beispiele aus der Bitcoin-Geschichte, jedes mit einem eigenen Ziel:
- Bitcoin XT (2015, initiiert von Mike Hearn und später von Gavin Andresen mitgetragen) wollte über BIP 101 die maximale Blockgröße von 1 MB auf 8 MB anheben, mit einer geplanten Verdopplung alle zwei Jahre danach.
- Bitcoin Classic (2016) wollte denselben Engpass moderater lösen: eine einmalige Anhebung auf 2 MB statt XTs deutlich aggressiverem Wachstumspfad.
- Bitcoin Unlimited (2016) wollte die feste Blockgrößen-Obergrenze komplett abschaffen und stattdessen jedem Miner beziehungsweise Node erlauben, sein eigenes Limit selbst zu konfigurieren ("Emergent Consensus").
- Bitcoin Satoshi Vision (BSV, November 2018) wollte massiv größere Blöcke (zunächst 128 MB, später noch deutlich mehr) sowie ursprüngliche, früh deaktivierte Skript-Befehle wiederherstellen.
Jede dieser vier Varianten war technisch fertig programmierter, lauffähiger Code. Bei den ersten drei kam es trotzdem in keinem einzigen Fall tatsächlich zu dem beabsichtigten Hard Fork: Es fehlte an einer ausreichend breiten, gleichzeitigen Zustimmung von Minern, Node-Betreibern und wirtschaftlich relevanten Nutzern. Ohne diese bleibt selbst fertiger, funktionierender Code wirkungslos. BSV liegt dabei etwas anders: Es spaltete sich im November 2018 tatsächlich erfolgreich ab, allerdings nicht von Bitcoin selbst, sondern von Bitcoin Cash (das seinerseits schon 2017 von Bitcoin abgespalten war). Auch das zeigt am Ende denselben Punkt: Ein Hard Fork erzeugt bestenfalls einen neuen, eigenständigen Coin, den der Markt als etwas anderes behandelt. Bitcoins eigene Konsensregeln selbst ändert er dadurch nicht. 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
Ein gutes Beispiel für einen Soft Fork sind die beiden Zeitschloss-Befehle OP_CHECKLOCKTIMEVERIFY (CLTV, aktiviert am 14.12.2015 bei Block 388.381) und OP_CHECKSEQUENCEVERIFY (CSV, aktiviert am 04.07.2016 bei Block 419.328), mit denen sich ein Betrag erst ab einem bestimmten Zeitpunkt oder nach einer bestimmten Wartezeit ausgeben lässt, eine wichtige Grundlage unter anderem für Lightning-Zahlungskanäle. Beide wurden nachträglich per Soft Fork ergänzt, ohne dass ältere Nodes die neue Regel überhaupt verstehen mussten: Für sie sahen die neuen Skript-Befehle einfach wie ein wirkungsloser Platzhalter aus. Aber wie einigt sich das Netzwerk eigentlich konkret auf den Zeitpunkt, ab dem eine neue Regel wie diese gilt? Dafür hat Bitcoin ein eigenes Signalisierungsverfahren über das Blockversions-Feld entwickelt, das im Lauf der Zeit selbst zweimal weiterentwickelt wurde. CLTV aktivierte noch über das ältere Verfahren (BIP-34, das damit erstmals eingeführt wurde und seitdem auch die Regel durchsetzt, dass jede Coinbase-Transaktion die aktuelle Blockhöhe voranstellen muss, geprüft in src/validation.cpp), das die Versionsnummer schlicht als Zahl behandelte und eine Zustimmung von 75 bzw. später 95 Prozent der letzten 1.000 Blöcke verlangte. CSV wiederum war die allererste Regel, die über das neue, verfeinerte Verfahren aktiviert wurde:
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.
Nachvollziehen lässt sich die 21-Millionen-Grenze mit einfacher Schulmathematik. Jeder der 210.000 Blöcke einer Halbierungsperiode zahlt denselben Betrag: Die erste Periode zahlt insgesamt 210.000 × 50 = 10.500.000 Bitcoin, die zweite nur noch die Hälfte davon, also 210.000 × 25 = 5.250.000 Bitcoin, und so weiter. Zählt man alle Perioden dieser geometrischen Reihe zusammen, ergibt sich 210.000 × 50 × (1 + 1/2 + 1/4 + 1/8 + …) = 210.000 × 50 × 2 = 21.000.000 Bitcoin: genau die bekannte Obergrenze. Im Code selbst steckt dahinter allerdings kein Grenzwert, sondern reine Ganzzahl-Arithmetik: nSubsidy beginnt bei 5.000.000.000 Satoshi (50 Bitcoin), eine Zahl, die binär 33 Bit benötigt, weshalb sie bereits nach der 33. Halbierung exakt null ist (rechnerisch bei Blockhöhe 33 × 210.000 = 6.930.000, also etwa im Jahr 2140). Die im Code sichtbare Grenze von 64 Halbierungen (if (halvings >= 64) return 0;) ist dabei kein weiterer Meilenstein, sondern nur eine Sicherheitsschranke gegen einen technisch undefinierten Bit-Shift um 64 oder mehr Stellen: Der eigentliche Nullpunkt liegt schon gut 30 Halbierungen früher. 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 = 21000000 * 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 in src/chain.h mitgeführt, verglichen über CBlockIndexWorkComparator in src/node/blockstorage.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 (in src/policy/policy.h) 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, Prüfung in src/consensus/tx_check.cpp), 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, das oft missverstanden wird: Diese Wartezeit betrifft ausschließlich die Blockbelohnung selbst, also die Bitcoin, die ein Miner als Lohn fürs erfolgreiche Mining eines neuen Blocks direkt zugewiesen bekommt (die sogenannte Coinbase-Transaktion). Gewöhnliche Bitcoin, die du auf normalem Weg per Überweisung von jemand anderem erhältst, sind davon nicht betroffen. Die kannst du üblicherweise schon nach der ersten Bestätigung, also im Schnitt nach rund 10 Minuten, wieder weitersenden.
Nur die Blockbelohnung selbst muss erst COINBASE_MATURITY = 100 weitere Blöcke reifen, bevor der Miner sie ausgeben darf, bei durchschnittlich 10 Minuten pro Block also rund 1.000 Minuten beziehungsweise etwas mehr als 16,5 Stunden. Der Grund für genau diesen einen Sonderfall: Sollte es kurzzeitig zu konkurrierenden Ketten kommen und sich am Ende eine andere als die eigene durchsetzen, verliert der Miner seinen gesamten Block, einschließlich der eigenen Blockbelohnung, ersatzlos. Bei einer ganz gewöhnlichen, bereits bestätigten Überweisung an dich als Empfänger besteht dieses Risiko dagegen nicht in derselben Form: Verlöre dein Miner die Wettbewerbskette, würde deine Transaktion in aller Regel einfach im nächsten, nun führenden Block erneut bestätigt, das Geld selbst bliebe erhalten. Bei der Blockbelohnung gibt es dagegen keinen "nächsten Block", der sie rettet, sie existiert ja nur, weil genau dieser eine Block gewonnen hat. Die 100 Blöcke Wartezeit verhindern, dass ein Miner eine Belohnung sofort weiterverwendet, die sich rückwirkend als nie entstanden herausstellen könnte.
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.
