Bitcoin begreifen

Angenommen du willst ein neues “Feature” zu Bitcoin Cores Netzwerkcode hinzufügen. Du willst eine Netzwerkmessage einführen namens kill, die ein Bitcoin Node einem anderen Bitcoin Node schicken kann. Der Empfängernode dieser Nachricht wird sich augenblicklich selbst herunterfahren. Nur NEU Nodes werden wissen, wie man mit einer einkommenden kill Message umgeht. ALT Nodes werden die–für sie–unbekannte Message ignorieren (Abbildung 2).

Die meisten Leute betrachten deine Änderung als riesiges Sicherheitsrisiko. Sie wollen nicht, dass sich ihr Node wegen irgendeinem unbekannten Fremden im Internet abschaltet. Du wirst es schwer haben Leute zu überzeugen, Bitcoin NEU zu benutzen. Du kannst niemanden zwingen; die Leute müssen es aktiv wollen und installieren, damit Bitcoin NEU netzwerkweit angenommen wird.

Dumme Änderungen wie die kill Nachricht schaffen es nicht in der Welt von Open Source.

Wie in Abschnitt 11.1 beschrieben ist eine Hard Fork eine Softwareänderung, die die Konsensregeln lockert. NEU Blocks, die durch NEU Nodes erzeugt wurden, könnten von ALT Nodes abgelehnt werden. Im Beispiel des vegetarischen Restaurants wäre es eine Hard Fork, wenn das Restaurant anfinge, Fleisch zu servieren.

Stell dir vor du willst eine Fork erzeugen, der das maximal erlaubte Blockgewicht–diskutiert in [increasing-the-block-size-limit]—von 4.000.000 WU auf 8.000.000 WU anhebt. Das würde es erlauben, noch mehr Transaktionen in einen Block zu stopfen. Andererseits könnte ein höheres Limit einige Nodes im Bitcoin Netzwerk beeinträchtigen, wie wir in [ch10] besprochen haben.

Jedenfalls ziehst du diese Änderung durch und beginnst, sie im Bitcoin Netzwerk zu benutzen. Wenn dein Node einen Block von einem Bitcoin ALT Node bekommt, dann akzeptierst du ihn, weil der Block definitiv ≤ 8.000.000 WU ist; der ALT Node würde ja keine Blocks erzeugen oder weiterleiten, die grösser als 4.000.000 WU sind.

Angenommen, du bist ein Miner, der Bitcoin NEU betreibt. Du hast das Glück, einen gültigen Proof of Work zu finden, und veröffentlichst deinen Block. Dieser Block wird definitiv ≤ 8.000.000 WU sein, muss aber nicht ≤ 4.000.000 WU sein. Wenn er ≤ 4.000.000 WU ist, dann wird er von den ALT Nodes akzeptiert. Aber wenn nicht, dann werden ALT Nodes deinen Block ablehnen. Deine Blockchain wird von der Bitcoin ALT Blockchain abweichen. Du hast einen Blockchain Split erzeugt (Abbildung 5).

Wenn dein NEU Node einen neuen Block erzeugt, kann dieser von den ALT Nodes abgelehnt werden, je nachdem, ob er ≤ 4.000.000 WU ist. Für die Blocks, die abgelehnt werden, wirst du eine Menge Energie und Zeit für das Mining von Blocks verschwendet haben, die es nicht in die Haupt Chain schaffen.

Aber nimm an, einer Mehrheit der Hashrate gefällt dein Bitcoin NEU Programm, und sie beginnt, es anstelle von Bitcoin ALT zu benutzen. Was passiert dann? Schauen wir mal, wie es ausgeht (Abbildung 6).

Wenn ein NEU Node einen grossen Block erzeugt, werden alle NEU Nodes versuchen, die Chain auf Basis dieses Blocks zu erweitern, aber alle ALT Nodes werden versuchen, auf Basis des letzten für sie gültigen Blocks–gemäss ALT Regeln–weiterzumachen.

NEU Nodes gewinnen im Laufe der Zeit mehr Blocks als ALT Nodes, weil sie zusammengenommen mehr Hashrate haben als die ALT Nodes. Es scheint, als würde der NEU Zweig intakt bleiben, weil er eine beruhigende Führung im gesammelten Proof of Work aufbaut.

NEU Nodes haben anscheinend einen dauerhaften Chain Split erzeugt. Aber wenn ein paar Miner sich entschliessen, zu Bitcoin ALT zurückzugehen, oder wenn zusätzliche Miner dem Rennen mit ALT Nodes beitreten, sodass ALT die Mehrheit der Hashrate wiederbekommt, dann könnte die NEU Chain Probleme bekommen, wie Abbildung 7 zeigt.

Wenn ALT Nodes die Mehrheit der Hashrate haben, werden sie schneller als die NEU Nodes sein und irgendwann aufholen und die NEU Nodes überholen. NEU Nodes erkennen diese Tatsache an und schwenken zurück zum Minen auf der ALT Chain. Wir sagen, dass der Zweig, den die NEU Nodes gebaut haben, durch eine Chain Reorganisation–üblicherweise als Reorg bezeichnet–ausgelöscht wurde, ein Wipeout.

Wir haben Soft Fork in diesem Buch mehrfach diskutiert. Eine Soft Fork ist eine Änderung an den Konsensregeln, bei der NEU Blocks von den ALT Nodes akzeptiert werden. Die Konsensregeln werden gestrafft. Im Falle des vegetarischen Restaurants wäre es eine Soft Fork, wenn das Restaurant sein Essen auf Vegan umstellte.

SegWit ist ein Beispiel für eine Soft Fork. Die Änderung wurde sorgfältig geplant, sodass ALT Nodes beim Verifizieren von Blocks, die SegWit Transaktionen enthalten, nie scheitern. Alle ALT Nodes akzeptieren jeden gültigen NEU Block und bauen ihn in die Blockchain ein.

Auf der anderen Seite könnte ein ALT Node einen Block generieren, der gemäss Bitcoin NEU ungültig ist. Zum Beispiel könnte ein nicht-SegWit Miner in seinen Block eine Transaktion einbauen, die einen SegWit Output ausgibt, als wäre es ein anyone-can-spend Output (Abbildung 9).

Angenommen, es gibt nur einen einzigen Miner mit einer geringen Hashrate, der Bitcoin NEU betreibt. Nimm weiterhin an, dass die ALT Miner einen Block produzieren, der gemäss der NEU Regeln ungültig wäre, wie in dem früheren Beispiel mit der nicht-SegWit Transaktion. Das Ergebnis wäre, dass die ALT Nodes einen Block bauen, der von dem NEU Miner nicht akzeptiert würde. Der NEU Miner würde den für ihn ungültigen ALT Block ablehnen. Dies ist der Punkt, an dem die Blockchain sich in zwei Chains aufspaltet (Abbildung 10).

In dieser Situation riskiert die ALT Chain, per Wipeout durch einen Reorg ausgelöscht zu werden. Nimm an, mehr Miner entschliessen sich, zu Bitcoin NEU zu upgraden, wodurch eine Mehrheit der Hashrate Bitcoin NEU unterstützt. Nach einer Weile würden wir wahrscheinlich einen Reorg sehen (Abbildung 11).

Der Bitcoin NEU Zweig wird der stärkere Zweig, sodass die verbleibenden ALT Miner deren Zweig verlassen und anfangen werden, an demselben Zweig wie die NEU Nodes zu arbeiten. Aber sobald ein ALT Node einen Block produziert, der auf den NEU Nodes ungültig ist, verliert er seinen Block Reward, weil der Block nicht auf dem NEU Zweig akzeptiert wird.

Schauen wir noch einmal, was Soft Forks von Hard Forks unterscheidet, als allgemeine Regel:

Das ist eine einfache, aber wahre, Unterscheidung. Wir können die Effekte eines Chain Splits durch Soft Fork oder Hard Fork wie folgt zusammenfassen:

Um Benutzer während eines Chain Splits vor Replay wegen einer Hard Forks zu schützen, kann das Transaktionsformat auf der NEU Chain so geändert werden, dass die Transaktion höchstens auf einem der Zweige gültig ist.

Als Bitcoin Cash seinen Chain Split durchgeführt hat, wurde sichergestellt, dass ALT Transaktionen nicht auf NEU Nodes gültig waren und NEU Transaktionen nicht auf ALT Nodes (Abbildung 15).

Um das zu erreichen, muss eine Transaktion auf dem NEU Zweig einen neuen SIGHASH Typ, FORKID, in den Transaktionssignaturen verwenden. Dieser Typ tut zwar aktiv überhaupt nichts, macht aber die Transaktion im ALT Zweig ungültig und im NEU Zweig gültig. Wenn eine Transaktion FORKID nicht benutzt, ist sie auf dem ALT Zweig gültig und auf dem NEU Zweig ungültig.

Einen neuen SIGHASH Typ für Signaturen zu benutzen ist natürlich nicht die einzige Methode, Replay Protection zu erreichen. Jede Änderung, die Transaktionen auf dem einen Zweig gültig und auf dem anderen ungültig macht, ist erlaubt. Man könnte zum Beispiel auch verlangen, dass NEU Transaktionen jeweils 1 von der txid der Inputs abziehen. Angenommen die UTXO, die du ausgeben willst, hat diese txid:

Wenn du die UTXO auf dem ALT Zweig ausgeben willst, benutzt du diesen Hash im Input deiner Transaktion. Wenn du die UTXO auf dem NEU Zweig ausgeben willst, benutzt du stattdessen das hier:

Beachte, dass dies nur ein albernes Beispiel ist, kein vollwertiger Vorschlag.

Als p2sh 2012 eingeführt wurde, hatte die Bitcoin Gemeinde keine Erfahrung mit Upgrades. Sie musste sich etwas einfallen lassen, um einen Blockchain Split zu vermeiden. Die Gemeinde implementierte Soft Fork Signalisierung, oder Signaling, mittels der Coinbase. NEU Miner signalisierten Unterstützung für p2sh, indem sie den String /P2SH/ in die Coinbase der von ihnen produzierten Blocks schrieben (Abbildung 16).

An einem bestimmten Tag schauten die Bitcoin Entwickler nach, ob mindestens 550 der letzten 1.000 Blocks /P2SH/ enthielten. Das war der Fall, und so stellten die Entwickler am 1. April 2012 eine neue Software Release zur Verfügung, die die p2sh Regeln verlangt. Dieser Tag wurde als “Flag Day” bezeichnet, als Signaltag.

Das funktionierte gut; Miner übernahmen schnell die Soft Fork und das gesamte Netzwerk installierte innerhalb einer vernünftigen Zeit das Upgrade. Es geschah kein Split, weil mindestens 50% der Hashrate vor dem Signaltag den Upgrade installiert hatte.

Ich habe nicht viel darüber gesprochen, aber der Block Header hat eine eigene Versionsnummer (Abbildung 17). Diese Version wird in den ersten 4 Byte vor dem eigentlichen Block Hash codiert.

Die Version ist das einzige, was bei unseren früheren Block Headern fehlt. Dies ist der eigentliche 80 Byte Bitcoin Block Header.

Die Blockversion kann verwendet werden, um Unterstützung für gewisse neue Features zu signalisieren.

Das erste Soft Fork Deployment mittels Blockversions-Signalisierung geschah 2013. Diese Soft Fork fügte eine Regeln hinzu, dass alle neuen Blocks die Block Height in ihrer Coinbase Transaktion enthalten müssen (Abbildung 18).

Die Aktivierung der Soft Forks geschah schrittweise durch Signalisierung mittels Blockversionsnummern, um einen Split der Blockchain zu verhindern:

Im Laufe von Schritt 1 hat sich nichts geändert. Es gelten nur die Bitcoin ALT Regeln. Aber wenn 750 der letzten 1.000 Blocks Version 2 haben, betreten wir die nächste Stufe. Hier sorgen die Nodes, auf denen die Soft Fork Software läuft, dafür, dass alle Version 2 Blocks die Block Height in der Coinbase haben. Ansonsten wird der Block fallengelassen. Ein Grund dafür ist, dass Nodes vielleicht absichtlich oder versehentlich aus anderen Gründen als für diese Fork Blockversion 2 signalisieren. Die 75% Regel entfernt solche Fehltreffer, bevor sie die 95% Regel auswertet.

Ab diesem Punkt könnten einige ALT Miner eine Chain Split erzeugen, indem sie einen Block mit Version 2 erzeugen, der die “Height in Coinbase” Regel verletzt (Abbildung 20).

Die ALT Miner würden auf Basis dieses Blocks weiterbauen, während die NEU Miner auf dem vorigen Block aufbauen würden. Aber die NEU Miner haben wahrscheinlich–abhängig von der Menge an falscher Signalisierung für Version 2–mehr Hashrate und werden die ALT Miner abhängen und den Bitcoin ALT Zweig auslöschen.

Wenn ein grösserer Anteil der Blocks–95% der letzten 1.000–mit Version 2 Blocks Unterstützung signalisiert, gehen wird den letzten Schritt, Schritt 5. Von diesem Punkt an werden alle Blocks mit Version < 2 fallengelassen.

Warum sind wir durch diese Phasen gegangen? Es ist nicht völlig klar, weshalb die 75% Regel benutzt wurde, aber es entfernt False Positives, also Fehltreffer, wie beschrieben. Das Deployment hätte auch nur mit der 95% Regel funktionieren können. Wir werden den Gedankengang hinter der 75% Regel nicht ergründen–akzeptieren wir, dass es für dieses und ein paar andere Deployments benutzt wurde. Tabelle 2 listet Soft Forks auf, die mit diesem Mechanismus eingeführt wurden.

Dieser Upgrademechanismus heisst Miner-aktivierte Soft Fork. Die Miner beginnen mit der Durchsetzung der neuen Regeln, und alle oder die meisten Full Nodes werden dem folgen, weil die NEU Blocks von sowohl NEU als auch ALT Nodes akzeptiert werden.

Die Bitcoin Entwickler haben in früheren Soft Forks eine Menge Erfahrung gesammelt. Ein paar Probleme müssen adressiert werden:

Das lästigste Problem ist, dass man nicht mehrere Soft Forks auf einmal ausrollen kann. Das liegt daran, dass frühere Deployment Mechanismen, wie das für BIP34 verwendete, geprüft haben, ob eine Blockversion grösser oder gleich einer bestimmten Zahl war, zum Beispiel 2.

Angenommen, du möchtest sowohl BIP34 als auch BIP66 gleichzeitig ausrollen. BIP34 würde Blockversion 2 benutzen und BIP66 Blockversion 3. Das würde bedeuten, dass man nicht selektiv Unterstützung nur für BIP66 signalisieren könnte; man müsste auch Unterstützung für BIP34 signalisieren, weil die Blockversion 3 grösser oder gleich 2 ist.

Die Entwickler liessen sich ein Bitcoin Improvement Proposal, BIP9, einfallen, das einen Prozess beschreibt, wie man mehrere Soft Forks gleichzeitig ausrollen kann.

Der Prozess benutzt ebenfalls die Blockversion, aber auf eine andere Weise. Die Entwickler entschieden, die Interpretation der Blockversions-Bytes zu verändern. Blockversionen, die die obersten 3 Bit genau auf 001 gesetzt haben, werden anders behandelt.

Zunächst sind alle solchen Blockversionen grösser als 4, weil die kleinste solche Blockversion 20000000 ist, also erheblich grösser als 00000004. Also werden Blocks, die BIP9 benutzen, immer die bereits ausgerollten BIP34, 66 und 65 unterstützen. Gut.

Als nächstes können die 29 Bits rechts von den ganz links stehenden 001 Bits benutzt werden, um Unterstützung für höchstens 29 gleichzeitige Soft Forks zu signalisieren. Jedes der 29 rechten Bits kann verwendet werden, um unabhängig ein einzelnes Feature oder eine Gruppe von Features auszurollen (Abbildung 21). Wenn ein Bit auf 1 steht, dann unterstützt der Miner, der den Block produziert hat, das Feature, das von diesem Bit repräsentiert wird.

Mehrere Parameter müssen für jedes ausrollbare Feature definiert werden:

Das Deployment durchläuft eine Anzahl Zustände (siehe Abbildung 22). Der Status wird nach jeder Retarget Period aktualisiert.

Wenn der Ausrollvorgang ACTIVE oder FAILED ist, wird das Bit, das Support signalisiert, auf 0 zurückgesetzt werden, damit es für spätere Ausrollvorgänge wiederverwendet werden kann.

Schauen wir uns ein Beispiel dafür an, wie ein Deployment mittels Versionsbits ablaufen kann. Wir betrachten, wie relative Lock Time ausgerollt wurde. Die Entwickler dieses neuen Features hatten die folgenden BIP9 Parameter definiert:

Der Timeout lag ein Jahr hinter der Startzeit, was den Minern etwa ein Jahr Zeit gab, auf die Soft Fork umzustellen, die das Feature implementiert.

Abbildung 23 zeigt die Zustandsübergänge, die geschahen.

Dieses Deployment lief schnell und glatt durch. Es brauchte nur drei Retarget Perioden, bis 95% der Miner auf die neue Software umgestellt hatten.

Unglücklicherweise gingen nicht alle Deployments so glatt.

SegWit, beschrieben in [ch10], verwendete auch BIP9 für sein Deployment, aber die Dinge liefen nicht wie vorgesehen. Es begann zunächst genau wie mit dem csv Deployment. Die Parameter für dieses Deployment waren:

Eine neue Version von Bitcoin Core wurde mit diesen SegWit Deployment Parametern freigegeben. Benutzer übernahmen diese Version ziemlich zügig, aber aus irgendwelchen Gründen blieben die Miner zögerlich. Das Signaling flachte bei ungefähr 30% ab und der Deployment Prozess blieb im STARTED Zustand stecken, wie Abbildung 24 zeigt.

Dem SegWit Deployment drohte ein Scheitern–der Übergang in den FAILED Zustand nach dem Timeout. In diesem Fall müsste ein ganzer neuer Deployment Zyklus eingerichtet und ausgeführt werden, was ein weiteres Jahr dauern könnte.

Um die Wichtigkeit der wirtschaftlichen Mehrheit (du, ich und alle anderen Bitcoin Benutzer) zu unterstreichen und um zu vermeiden, dass Miner gegen Vorschläge, die von der wirtschaftlichen Mehrheit verlangt werden, Veto einlegen dachten die Leute eingehender über User Activated Soft Forks nach.

Schauen wir uns ein fiktives Beispiel für eine User Activated Soft Fork an.

Angenommen, 99% der Bitcoin Benutzer (Endbenutzer, Exchanges, Händler und so weiter) wünschen eine Regeländerung–zum Beispiel kleinere Blocks–, dann wäre dies eine Soft Fork. Nimm weiter an, dass kein Miner kleinere Blocks will, also weigern sie sich alle, mitzumachen. Und nimm ausserdem an, dass 99% der nicht-minenden Full Nodes ihre Software so ändern, dass diese ab einer bestimmten Block Height grosse Blöcke ablehnt.

Was wird passieren, wenn ein Block diese Height passiert? Miner, die grosse Blocks produzieren, bauen dann eine Blockchain, die Benutzer als ungültig erachten (Abbildung 27).

Der Wert der Block Rewards in der “Miner” Chain wäre unbekannt, weil die Exchanges nicht mit der Miner Chain handeln. Miner werden nicht in der Lage sein, ihre Block Rewards zu verkaufen, um ihre Stromrechnungen zu bezahlen. Selbst wenn der Stromlieferant Bitcoin akzeptiert, können die Miner dennoch nicht mit ihren Block Rewards bezahlen, weil der Stromlieferant die Blocks der Miner nicht als gültig anerkennt. Denke daran, dass der Stromlieferant auch ein Bitcoin Benutzer ist.

Aber wenn ein einziger Miner sich entschliesst, auf die Forderungen der Benutzer einzugehen, dann werden seine Blocks die einzigen sein, die die Benutzer schlussendlich akzeptieren (Abbildung 28).

Dieser einzelne Miner wird für den Block, den er erzeugt, belohnt, weil die wirtschaftliche Mehrheit seinen Block akzeptiert. Die Blocks auf der Miner (grosse Blocks) Chain sind immer noch ziemlich wertlos, weil kein User sie akzeptiert. Darüberhinaus kann der einzelne klein-Block Miner mehr Gebühren verlangen, weil die Gesamtmenge an Blockplatz geringer ist–sowohl weil das maximale Blockgewicht kleiner ist, als auch weil die gesamte Anzahl Blocks geringer ausfällt.

Einige weitere gross-Block Miner werden vermutlich merken, dass ihnen schnell das Geld ausgeht, und beschliessen, zu dem User-akzeptierten Zweig hinüber zu schwenken (Abbildung 29).

Wenn mehr Miner zum User-Zweig wechseln, wird dieser Zweig irgendwann stärker als die gross-Block Chain. Wenn das passiert, wird die gross-Block Chain ausgelöscht (Abbildung 30) und die verbleibenden Miner werden automatisch auf den klein-Block Zweig umschalten, weil die Änderung eine Soft Fork ist

Die Benutzer gewinnen.

Eine der ersten Soft Forks in Bitcoin, das Deployment von BIP16 (p2sh), war eine User Activated Soft Fork. Das Deployment war insofern manuell, als die Entwickler an einem bestimmten Tag manuell die Anzahl Blocks zählen mussten, welche Unterstützung signalisierten und sich dann auf einen Signaltag, einen Flag Day einigen mussten, um ihn in das nächste Release der Bitcoin Software einzubauen. Nach diesem Datum wurden alle Blocks, die sich nicht an die neuen Regeln hielten, von den Nodes mit dieser Software abgelehnt.

Um die Einsichten aus dem kürzlichen Deployment von SegWit zu benutzen, ist ein neuer Deployment Mechanismus in Arbeit. Er wird allgemein als User Activated Soft Fork bezeichnet. Die Idee ist, mit einem BIP9-artigen Deployment anzufangen, aber mit der Ausnahme, dass wenn das Deployment nicht lange vor dem Timeout in den Zustand LOCKED_IN übergeht, solche Blocks abgelehnt werden, die nicht die Fork signalisieren. Das wird im Effekt für 100% Unterstützung sorgen, weil nicht konforme Blocks nicht mehr zählen werden und das Deployment dann schnell zu LOCKED_IN wird.