Bitcoin XT mag gut sein, um Druck auf die Kern-Entwickler auszuüben. Sollte die Drohung jedoch wahr werden, sind die Folgen für den Bitcoin katastrophal.
Es ist ein Wunder, dass die Erde noch bewohnbar ist. Während des kalten Krieges haben die USA und Russland mit Atomwaffen um die Wette gerüstet und den Feind mit nichts weniger als der Auslöschung der Menschheit bedroht. Im Nachhinein weiß man, dass es nur dem Glück zu verdanken ist, dass diese Mutter aller Drohungen nicht wahr geworden ist.
In der Bitcoin-Welt entspricht der Konflikt zwischen Core und XT dem kalten Krieg. Der von Mike Hearn geführte alternative Bitcoin Client XT hat Gavin Andresens Vorschlag zur Lösung des Scalability-Problems – BIP101 – integriert und droht der Bitcoin-Community mit einer unkontrollierten Hard Fork.
Ich habe im letzten Beitrag geschrieben, man solle XT benutzen, um Druck auf die Core-Entwickler auszuüben, endlich zu handeln. Ich bleibe dabei, dass XT ein basisdemokratisches Instrument ist. Man könnte es damit vergleichen, aus Unzufriedenheit mit der herrschenden Politik in einer Wahlumfrage für eine Partei zu stimmen, die man nicht zwingend als Regierung haben möchte.
Allerdings ist diese Perspektive einseitig. Sie vernachlässigt zum einen, dass die Core-Entwickler eine hervorragende Arbeit machen. Sie verbessern den Bitcoin-Clienten fortlaufend, beseitigen Bugs, verbessern die Performance und entwickeln neue Features wie beispielsweise das Blockchain-Pruning. Diese harte Arbeit am Detail ist die wichtigste Grundlage, um den Bitcoin skalierbar zu machen und gleichzeitig die Dezentralität der Nodes zu erhalten. Zudem haben die Kernentwickler etwa im Zuge der Malleability Transactions Welle bewiesen, dass sie durchaus fähig sind, schnell und entschieden zu handeln.
Der GAU: Die Hard Fork ohne Konsens
Zum anderen muss man fragen, was im worst case passiert. Bekanntlich reichen kleine Unfälle, Böswilligkeiten oder Zufälle aus, um eine Drohung zur Tatsache zu machen. Es könnte beispielsweise passieren, dass ein mächtiger Mining-Pool – aus welchen Gründen auch immer – kurzerhand auf XT umschwenkt und damit BIP 101 und eine Hard Fork triggert. In manchen Szenarien kann bereits ein Anteil von 10-20 Prozent der Rechenleistung des Netzwerks ausreichen, um dieses in ein unkalkulierbares Abenteuer zu stürzen.
Eine unkontrollierte Hard Fork ist mit das schlimmste, was dem Bitcoin passieren kann. Sie bedeutet, dass es plötzlich zwei Bitcoins gibt und keiner weiß, welcher der richtige ist. Diese Unsicherheit würde schwerste Schäden in der Bitcoin-Wirtschaft anrichten, da sie Börsen, Zahlungsdienstleister etc. vor gewaltige Herausforderungen stellt. Zudem ist es schwer zu überschauen, welche Kompatibilitäten es zwischen den beiden Bitcoins geben würde und welche Möglichkeiten zu Manipulation und Double Spend daraus entstehen. Eine Hardfork ohne Konsens würde weite Teile der Bitcoin-Wirtschaft verwüsten. Darum schrieb Carsten Otto, dass eine Hardfork nur mit Konsens eine Option ist.
BIP 101 ist alles andere als sicher
Aber selbst wenn sich die Fork harmonisch zugunsten von BIP 101 (also XT) ausspielen sollte, ist die Situation nicht entschärft. Denn von allen Vorschlägen zur Erhöhung der Blockgröße ist BIP 101 der radikalste und darum auch gefährlichste. BIP 101 sieht vor, die Blockgröße sofort auf 8 MB und sukzessive bis 2036 auf 8012 MB zu erhöhen. Gavin Andresen geht davon aus, dass das Moore’sche Gesetz auch in den nächsten Jahrzehnten gültig bleiben wird – obwohl sich die Fortentwicklung von Speicher und CPU bereits jetzt verlangsamt.
Die Tests und Simulationen von Kernentwicklern haben gezeigt, dass BIP 101, anders als von Andresen behauptet, keineswegs ungefährlich ist. Das in meinen Augen größte Problem ist, dass die notwendige Zeit, um Blöcke im Netzwerk zu verbreiten, exponentiell mit der Größe der Blöcke ansteigt. Dies kann die Synchronität des Netzwerkes beeinträchtigen und kleine Miner durch das vermehrte Aufkommen von verwaisten Blöcken aus dem Markt drängen. Darüber hinaus erhöhen 8 MB Blöcke die Gefährlichkeit von Spam-Transaktions-Angriffen erheblich, wodurch es möglich sein wird, dass Nodes wegen des hohen Bedarfs an Speicher oder Bandbreite in die Knie gehen.
Neben BIP101 zirkulieren noch einige weitere Vorschläge (BIP100-104 sowie NG). Prinzipiell gibt es endlos viele Möglichkeiten, Bitcoin skalierbar zu machen. Die Variablen sind die neue Größe der Blöcke, das Interwall zwischen den Blöcken sowie der Trigger von Änderungen. Jeder Vorschlag in diesem Rahmen hat seine Stärken und Schwächen, aber nur wenige sind so riskant wie BIP 101.
Das derzeitige Problem scheint zu sein, dass sich die Kernentwickler nicht auf eines dieser BIPs einigen können. Keines ist perfekt, und jedes stellt das Netzwerk vor eine Herausforderung. Notwendig ist jedoch, dass zumindest eine Auswahl an BIPs getroffen wird und diese ausgiebig getestet werden. Am Ende sollten idealerweise die User und / oder Miner durch die Wahl eines Clients darüber entscheiden, welches von den Kernentwicklern für gut befundene BIP zum Einsatz kommt.
—
Hast du einen Diskussionsbeitrag zum Scalability-Problem?
Das Bitcoinblog.de wird eingesandte Beiträge zum Scalability-Problem gerne veröffentlichen und nimmt auch gerne Anregungen an. Braucht es einen Gebührenmarkt? Ist nicht die Blockgröße, sondern weitere Konzepte wie Lightning oder Sidechains die Lösung? Wie viel Zeit bleibt noch, bis eine Hard Fork ausgerollt wird? Wird Blockchain-Pruning die Rettung sein? Ist NG der bessere Bitcoin?
Falls Ihr eine Meinung dazu habt oder etwas darüber geschrieben habt, kontaktiert mich einfach (christoph.bergmann@mailbox.org).