Der BitcoinCash Hardfork am 15. November – technische Hintergründe und Diskussionen zwischen den verschiedenen Lagern

Seit einigen Wochen spaltet sich die Community um die Altcoin Bitcoin-Cash in drei Lager: in Bitcoin ABC, Bitcoin SV und Bitcoin Unlimited. Der Versuch eines objektiven Überblicks über die Diskussion.

Logo von BitcoinCash

Etwa alle 6 Monate führt Bitcoin Cash geplante Hardforks, sogenannte Protokoll Upgrades, durch, also Weiterentwicklungen der Open Source Software, bei denen Änderungen ausgerollt werden, die zu älteren Versionen inkompatibel sind. Bislang stießen die Hardforks bei der Community durchwegs auf Akzeptanz; so wurde beispielsweise die Erhöhung der Blockgröße und damit der Transaktionskapazität von Bitcoin Cash von 8 auf 32 MB im Rahmen des letzten Hardforks vom Großteil als sinnvoll erachtet. Diesmal stößt das geplante Upgrade doch auf Unstimmigkeiten: Bitcoin ABC, Bitcoin SV und Bitcoin Unlimited sind drei verschiedene Teams, die alle verschiedene (aber bisher zueinander kompatible) Implementierungen der Bitcoin-Cash-Software veröffentlichen. Die Einigkeit steht nun jedoch auf dem Prüfstand, wobei sich in der aktuellen Diskussion vor allem Bitcoin ABC und Bitcoin SV in vielen Punkten uneinig sind.

Streitpunkt #1: OP_CHECKDATASIGVERIFY

Der meistverbreitete Full-Node ist Bitcoin ABC. Das „ABC“ im Namen steht dabei für „Adjustable Blocksize Cap”, dem Hauptgrund für die im August 2017 erfolgte Abspaltung von der Bitcoin-Blockchain. Bitcoin ABC will im Rahmen des nächsten Protokoll Upgrades ein neues Kommando (OP-Code „OP_CHECKDATASIGVERIFY“, oft auch mit „DSV“ abgekürzt) für die Script-Sprache von Transaktionen aktivieren, das es ermöglichen wird, die Signatur beliebiger Daten in einer Transaktion zu prüfen. Bisher kann nur die Signatur der Transaktion selbst geprüft werden. So könnten künftig beispielsweise Daten von externen (und trusted) Orakeln, die für die Beteiligten der Transaktion vertrauenswürdig sind, in die Transaktion einfließen.

Die Vertreter von Bitcoin SV (das „SV” im Namen steht für „Satoshi’s Vision”) weigern sich beharrlich, diesen neuen OP-Code einzubauen. Craig Wright, einer der Hauptprotagonisten von Bitcoin SV, begründet dies damit, dass dadurch auch illegale Glücksspiele zu einem integralen Bestandteil von Bitcoin Cash werden können. Denn durch OP_CHECKDATASIGVERIFY ist es möglich, mit Bitcoin Cash zu wetten. Ein fiktives Beispiel: Beträgt die Temperatur am 1. Dezember 2018 mehr als 25 Grad, wechselt eine gewisse Anzahl an Bitcoin Cash den Besitzer. Nachgewiesen wird die tatsächliche Temperatur zum vereinbarten Datum dann durch die Signatur eines externen Wetterdienstes, dem beide Wett-Teilnehmer vertrauen müssen. Zum Einlösen der Transaktion müsste man dann eine Nachricht, die mit dem Schlüssel von eben diesem externen Wetteranbieter signiert ist, in die Transaktion schreiben. Der neue OP-Code DSV ermöglicht genau das Verifizieren solcher Signaturen externer Anbieter.

Craig Wrights Befürchtungen sind allerdings auch aus dem Blickwinkel zu betrachten, dass die meisten Smart-Contract-Plattformen ebenfalls externe Daten in den Transaktionen verifizieren können. Würde man diese Argumentation also konsequent weiterdenken, so müsste man das Argument auch auf Ethereum und Co. anwenden.

Streitpunkt #2: Canonical Transaction Ordering/Blockgröße

Bereits bei den vergangenen Hardforks war die Canonical Transaction Ordering ein kontroverses Thema. Dabei geht es darum, die Reihenfolge der Transaktionen in einem Block vorzuschreiben. Bislang gibt es – mit Ausnahme von Parent-Transaktionen – keine festgelegte Reihenfolge. Bitcoin ABC spricht sich stark für die Implementierung der Canonical Transaction Ordering (auch CTOR genannt) aus, um in Zukunft bei größeren Blöcken eine bessere parallele Verarbeitung der Transaktionen zu ermöglichen (bisher werden bei Bitcoin Cash alle Transaktionen in einem Block seriell, eine nach der anderen, validiert – dies heißt, dass selbst auf einem aktuellen PC mit vielen CPU-Kernen immer nur ein einziger CPU-Kern die Validierung vornehmen kann). CTOR bedeutet einfach, dass alle Transaktionen innerhalb eines Blocks aufsteigend nach Transaction ID sortiert sein müssen. Dadurch lässt sich diese Aufgabe leichter in Teilaufgaben und somit auf mehrere CPUs aufteilen.

Bitcoin SV würde diesen Schritt dagegen lieber überspringen und sofort die Blockgröße auf 128 MB statt der bisherigen 32 MB erhöhen. Bitcoin ABC hält hier als Argument dagegen, dass bislang aufgrund der Tatsache, dass die meisten Blöcke nicht einmal 1 MB benötigen, noch kein Bedarf dafür besteht – und dass zuvor die Implementierung der Canonical Transaction Ordering als Voraussetzung für die Erhöhung der Blockgröße unerlässlich ist.

Streitpunkt #3: Remove OP Code Limit + Aktivierung deaktivierter OP-Codes

Bislang ist die Anzahl der OP-Codes (Kommandos) im Script einer Bitcoin-Cash-Transaktion limitiert. Dieses Limit soll, wenn es nach Bitcoin SV ginge, deutlich erhöht werden. Auch dieser Vorschlag wird aber von Bitcoin ABC abgelehnt, solange es dazu nicht weitere Tests gibt. Zudem hat Bitcoin SV einige OP-Codes reaktiviert, die vor langer Zeit in der Bitcoin-Software (von der sich Bitcoin Cash ableitet) deaktiviert wurden (OP_MUL, OP_LSHIFT, OP_RSHIFT, OP_INVERT), da man sich nicht ganz sicher war, ob man sie wirklich braucht und ob sie nicht unter bestimmten Umständen ein Risiko darstellen könnten.

Die Rolle von Bitcoin Unlimited

Der Dritte im Bunde, Bitcoin Unlimited, versucht, zwischen Bitcoin SV und Bitcoin ABC zu vermitteln. Der eigene Full-Node von Bitcoin Unlimited unterstützt die Hard-Fork-Änderungen beider Parteien, allerdings kann man auch den Status quo wählen. Somit kann der Miner/Full-Node-Betreiber via Parameter selbst entscheiden, welchen Fork er unterstützen möchte.

Die Folgen der Diskussion

Auch bei den vorangegangenen Hardforks gab es immer wieder Unstimmigkeiten zwischen den Lagern, die jedoch meist rasch beseitigt wurden, da keines der Lager einen Chain-Split riskieren wollte, bei dem die Miner letztendlich unterschiedlichen Chains folgen würden. Dieses Mal sieht die Lage jedoch ernster aus, da man sich bis zuletzt auf keinen gemeinsamen Kompromiss einigen konnte.

Somit gibt es nun für 15. November drei verschiedene, zueinander inkompatible Versionen der Bitcoin-Cash-Software und die Miner müssen sich entscheiden, welche Software sie einsetzen wollen (Bitcoin ABC, Bitcoin SV oder Status quo und keine Änderungen).

Sollte es tatsächlich zu einem Split kommen, kann es ab 15. November bis zu drei verschiedene Bitcoin-Cash-Coins geben. Das wird zu heftigen Diskussionen führen, welche Version sich als das „echte“ Bitcoin Cash bezeichnen darf (und auch das Kürzel „BCH“ weiterführen darf).

Bitcoin SV ist ohnehin bereits davon überzeugt, das „echte“ Bitcoin Cash zu sein („Satoshi’s Vision“). Deswegen hat sich dieser Teil der Community geweigert, eine Replay Protection einzubauen. Das heißt: Führt ein User nach dem Hardfork am 15. November eine Transaktion auf der Bitcoin ABC Chain durch, kann jeder diese Transaktion von der öffentlichen Blockchain nehmen und die gleiche Transaktion auf der anderen Chain (mit den anderen Coins) ausführen. Dies wurde in der Vergangenheit (zum Beispiel beim Fork von Ethereum und Ethereum Classic) schon oft von Scammern ausgenutzt und kann zur Folge haben, dass unbedarfte Nutzer ihre Coins verlieren.

Welche Implementierungen sich am 15. November durchsetzen werden, wird aber letztendlich vor allem die Rechenleistung der Miner, die sogenannte Hashrate, entscheiden.

Coinfinity empfiehlt, am 15. November und auch an den Tagen danach keine Bitcoin-Cash-Transaktionen vorzunehmen, bis sich die Lage etwas geklärt hat.

Weiters sollte man Bitcoin Cash während dieser Zeit unbedingt auf Wallets verwahren, bei denen man selbst den privaten Schlüssel besitzt (z. B. Ledger, Trezor, Copay …), und keinesfalls auf Exchanges. Andernfalls nimmt man in Kauf, dass man im Fall eines dauerhaften Forks nicht auf beide Coins Zugriff hat.

Der Hardfork-Zeitpunkt ist in allen 3 Implementierungen mit Donnerstag, 15. November 2018 um 17:40 (MEZ) fest einprogrammiert. Mit dem ersten Block, der einen Zeitstempel nach diesem Zeitpunkt trägt, aktivieren die 3 verschiedenen Clients ihre jeweiligen neuen Funktionen. D. h., ab diesem Zeitpunkt kann ein Split eintreten.

Sollten Sie Fragen haben, welche Auswirkungen eine möglicher Hardfork am 15. November auf Ihre Coins haben wird, stehen wir Ihnen gerne zur Verfügung.