Bitcoin Cash Fork: Läuft, aber mit Turbulenzen

Gestern war wieder Hardfork-Tag bei Bitcoin Cash. Wie es aussieht, ist die Fork in trockenen Tüchern. Aber ganz glatt lief es nicht: Ein Angreifer hat die Miner vorübergehend gezwungen, leere Blöcke zu produzieren.

Alle sechs Monate veranstaltet Bitcoin Cash (BCH) eine Hardfork. Dabei ändern die Entwickler das Protokoll, um neue Features einzuführen oder bestehende Eigenschaften zu ändern. Daher wird die Hardfork auch “Protokoll-Upgrade” genannt. Dies ändert aber nichts an der Tatsache, dass das Upgrade “hart” ist: Es ändert die Konsensregeln, was bedeutet, dass alle Knoten im Netzwerk upgraden müssen – oder nicht mehr auf derselben Blockchain sind.

Gestern fand nun eine dieser planmäßigen Hardforks statt. Die Entwickler haben unter anderem mit Schorr einen neuen Algorithmus für Signaturen eingeführt und es wieder ermöglicht, Bitcoin Cashs, die versehenlich an eine SegWit-Adresse gesendet wurden, zu bergen. Anders als die Hardfork im vergangenen November hatte dieses Upgrade den Konsens aller beteiligten Entwickler und Firmen, weshalb keine starken Turbulenzen zu erwarten waren.

Es wurde dann aber doch ein wenig wild. Am späte Nachmittag setzte die Hardfork mit Block #582680 ein. In diesem Moment spaltete sich die Blockchain in eine alte und eine neue Chain. Es gab zwar einige Nodes – und eventuell auch Miner – die die Hardfork nicht mitgemacht haben, doch es entstand bisher kein neuer Block auf Basis der alten Chain. Damit gibt es schon mal keinen dauerhaften Chainsplit; das Ökosystem folgt der Hardfork einstimmig.

Kurz nach der Fork trat aber ein Bug bzw. ein Angriff auf: Ab Block #582687, also etwa eine Stunde nach der Fork, waren alle Blöcke leer, während sich die Transaktionen im Mempool stauten. Dies sorgte natürlich für Verwirrung, zum Teil auch Panik. War etwas mit der Hardfork schiefgegangen? Hatten die Entwickler einen Bug eingeführt?

Knapp zwei Stunden – oder zehn Blöcke – später, war der Spuk vorbei. Die Blöcke füllten sich wieder mit Transaktionen. Die Szene konnte aufatmen. Aber was genau ist da passiert? Die Erklärung ist recht technisch, aber wir versuchen, sie so verständlich wie möglich rüberzubringen:

Der Bug

Der Bug, der die leeren Blöcke verursachte, hatte an sich wohl nichts mit dieser Hardfork zu tun – aber sehr viel mit der letzten. Der Angreifer hat wohl in dieser Hardfork einen guten Zeitpunkt gesehen, ihn auszunutzen.

Also: Jede Transaktion enthält sogenannte “SigOps”, was die Abkürzung für “Signatur-Operationen” ist. Solche Operationen bedeuten, dass eine Signatur geprüft wird. Dies ist der rechenintensivste Bestandteil der Arbeit, die sowohl Nodes als auch Miner mit Blöcken bzw. Transaktionen haben. Daher gibt es bei Bitcoin Cash ein Limit für Signatur-Operationen je Block, um zu verhindern, dass ein Angreifer das Netzwerk mit einem Monster-Block lahmlegt, der so viele SigOps hat, dass alle Knoten Stunden brauchen, um sie durchzurechnen. So ein Limit kann nur greifen, wenn die Knoten zuvor die Anzahl der SigOps je Transaktion und Block gezählt haben. Klar.

Nun gab es einen Fehler in der Software von ABC, der führenden Node-Software für Bitcoin Cash. BCH hat in der letzten Hardfork, im November, einen neuen Skriptbefehl eingeführt, CDS (OP_Checkdatasig). CDS umfasst auch Signaturen, allerdings in anderer Weise. Um es den Nodes einfacher zu machen, dies zu erkennen, enthalten CDS-Transaktionen eine sogenannte “Flagge”, das ist eine Art Anhängsel, das Infos mit gibt. Die Flagge sagt, dass die Transaktion SigOps enthält, woraufhin die Software beginnt, die SigOps zu zählen. Ein ABC-Node prüft die Flagge bei jedem Schritt – außer bei der Aufnahme von Transaktionen in den MemPool. Das haben die Entwickler wohl schlichtweg vergessen.

Im MemPool (Memory-Pool) speichern die Knoten Transaktionen, die noch nicht bestätigt sind. Im Falle von CDS nehmen die Knoten die Transaktionen nun auf, als hätten sie keine SigOps. Wenn die Mining-Knoten nun beginnen, Transaktionen im MemPool zu nehmen, um daraus einen Block zu bilden, gibt es ein Problem: Sie denken, es gäbe keine SigOps für die CDS-Transaktionen, aber wenn sie dann später, beim Mining selbst, den Block nochmal prüfen, merken sie, dass es viel mehr SigOps gibt als gedacht. Etwas stimmt nicht.

Kurz nach der Hardfork hat ein Angreifer eine riesige Menge an sehr seltsamen Transaktionen gebildet, die diesen Bug ausnutzten, um die Miner zu verwirren. Nachdem diese über Probleme bei der Produktion von Blöcken stießen, wussten sie sich nicht anders zu helfen, als einfach leere Blöcke zu bilden, die lediglich die Coinbase-Transaktion enthielten, mit denen sie sich ihre Block-Belohnung auszahlten.

Weitere Ereignisse

Der ganze Spuk war dementsprechend nicht so katastrophal, wie manch einer gefürchtet hatte. Das Netzwerk lief weiter, konnte aber keine Transaktionen prozessieren. Bitcoin-Unlimited-Nodes waren von dem Bug nicht betroffen; die ABC-Entwickler haben ihn rasch gefunden, gefixt und die Miner informiert. Ab Block #582697 war dann wieder alles in Ordnung, der MemPool begann, sich zu leeren, und die Miner wagten sich wieder an größere Blöcke heran.

Kurze Zeit später gab es aber noch weitere Ereignisse, die einigermaßen aufregend waren: Zunächst wurden die Blöcke 582698 und 582699 verwaist. Es gab eine “Reorg” über zwei Blöcke – der erste Block wurde gemined und der zweite auf diesem gebildet – und dann wurde die Kette von einer anderen Kette überholt. Der Grund hierfür lag eventuell in einem weiteren Angriff: Jemand hatte wohl die Option, Coins zu bergen, die an SegWit-Adressen geschickt wurden, ausgenutzt, um die Coins zu stehlen.

Der Hintergrund dieses Angriffs ist, dass es immer wieder User gibt, die versehentlich Bitcoin Cash an Adressen schicken, die für Bitcoin (BTC) und mit SegWit gebildet wurden. Das hat zur Folge, dass jeder die Coins ausgeben kann, aber nur, wenn er eine “Nicht-Standard-Transaktion” bildet, was in der Regel nur die Miner können. Ein Bug in der letzten Hardfork hatte die Coins dauerhaft eingefroren, was in der Hardfork gestern wieder rückgängig gemacht wurde. Nun hat ein Miner also die Chance beim Schopf gepackt, um die ihm bekannten SegWit-Adressen auf Bitcoin-Cash auszuräumen.

Der Pool BTC.top hat wohl dafür gesorgt, dass dieser Diebstahl nicht funktioniert hat, indem er eine alternative Kette gemined hat, die diese Transaktionen nicht enthielt. Damit hat BTC.top in gewisser Weise die Rolle der Polizei übernommen und im Kleinen das durchgeführt, was im Zusammenhang mit dem Binance-Hack im Großen diskutiert wurde. Reorgs sind derzeit wohl im Trend, und Bitcoin Cash hat gestern vorgeführt, dass sie ein probates Mittel für Miner sind, gewisse soziale Regeln auf der Blockchain auch dann durchzusetzen, wenn diese nicht technisch gedeckt sind.

Heute schließlich bildete sich erneut ein Stau auf der Blockchain. Der Grund dafür war aber nicht ein Angriff, sondern, ganz im Gegenteil: Ein Bitcoin-Cash-Entwickler hat die Transaktionen des Hackers, die die Blockchain für zehn Blöcke lahm gelegt hatten, selbst gehackt. Denn die Transaktionen hatten ein leicht zu erratendes Signatur-Skript und keine Signatur, was, wenn man sie nur gut genug untersucht hatte, möglich machte, sie auszugeben. Insgesamt waren es aber wohl nur etwas mehr als 500 Dollar in Bitcoin Cash.

Schnorr

Nun, einen Tag nach der Hardfork, scheint die Sache rund gelaufen zu sein. Bitcoin Cash hat ein Protokoll-Upgrade durchgeführt. Damit wird Bitcoin Cash zur ersten Bitcoin-artigen Blockchain, die Schnorr-Signaturen einsetzt. Schorr ist eine Alternative zu den üblichen ECDSA-Transaktionen; bei Bitcoin selbst (BTC) wird schon recht lange daran gearbeitet, sie einzuführen.

Schnorr hat einige schlagende Vorteile: Erstens sind die Transaktionen ein Stückchen kleiner als herkömmliche Transaktionen (nur ein paar Byte), und benötigen weniger Rechenleistung zur Verarbeitung. Zweitens sind sie nativ multisig-fähig, was bedeutet, dass man Multisig-Transaktionen bilden kann, ohne dafür wie bei Bitcoin ein spezielles Adress-Format zu verwenden. Das hilft aus verschiedenen Gründen der Privatsphäre der User. Drittens erlaubt es Schnorr – zumindest theoretisch – die Signaturen von Inputs zu verschmelzen, womit eine Transaktion sehr viel kleiner und auch sehr viel privater wird.

Die Implementierung von Schnorr ist wohl relativ undisruptiv. Weil der Algorithmus sehr ähnlich zu ECDSA ist, kann man denselben privaten Schlüssel und dieselbe Adresse verwenden. Lediglich unterhalb dieser Oberfläche passiert etwas anderes. Damit muss man seine Coins nicht auf eine neue Adresse überweisen, wenn man Schnorr verwenden will, sondern kann sich einfach ein Update der Wallet herunterladen, wenn es dieses gibt, um dann mit Schnorr zu signieren. Zumindest habe ich es so verstanden. Es kann durchaus sein, dass ich an der Stelle etwas durcheinanderbringe.

Es wird auf jeden Fall interessant sein, zu sehen, wie sich Schnorr in der Praxis macht, auch – und für viele vor allem – in Hinblick darauf, dass der neue Signatur-Algorithmus in absehbarer Zukunft auch bei Bitcoin aufschlagen wird.