Warum XT und BIP101 so gefährlich sind

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).

About Christoph Bergmann (1048 Articles)
Das Bitcoinblog wird von bitcoin.de gesponsort, ist inhaltlich aber unabhängig und gibt die Meinung des Redakteurs Christoph Bergmann wieder. Wenn Ihnen das Blog gefällt, freuen wir uns über Spenden an 1BvayiASVCmGmg4WUJmyRHoNevWWo5snqC. Jeder Satoshi wird dazu verwendet, um das Blog besser zu machen. Weitere Infos, wie Sie uns unterstützen können, finden Sie HIER. Gastbeiträge sind ebenfalls willkommen. Meinen öffentlichen PGP-Schlüssel sowie den Bitmessage-Schlüssel finden Sie HIER

11 Comments on Warum XT und BIP101 so gefährlich sind

  1. KISS = Keep It Simple, Stupid // 12. November 2015 at 17:03 // Reply

    Ein sehr gelungener Artikel wie ich finde.

    Jeder Vorschlag hat Stärken und Schwächen… ja, das stimmt.

    Ich wäre ja dafür, eine statische Obergröße zu setzen, z.B. 8 MB und dann nach Bedarf evtl. wieder ein Fork zu machen irgendwann. Das ist zwar lästig, dies immer wieder ändern zu müssen, aber endgültige Lösungen wird es in der IT/Cryptowelt ohnehin nicht geben. Insofern empfinde ich BIP101 als etwas utopisch, weil dieser “Vorschlag” sich anmaßt, die Zukunft bis ins Jahr 2036 vorherzusehen.

    Können wir da nicht einfach statisch die Blockgröße nach Bedarf erhöhen, das ist technisch das einfachste.

    Statische Größen haben den Vorteil, dass sie klar definiert und einfach zu verstehen sind. Also auch weniger fehleranfällig. 8 MB kann auch fast jeder verstehen, ohne einen Doktortitel in Mathematik zu erwerben.

    Das altbekannte KISS-Prinzip. Mache es so einfach wie möglich!

  2. Momentan liegt die max. Bandbreite bei 2GBit/sek. ca. 200MB pro Sekunde. D.h. man könnte die max. Blockgröße von 8GB je Block bereits HEUTE laden bzw. hätte die Bandbreite dazu.
    Und was den Speicher angeht, da sehe ich kein Problem, weshalb man diesen nicht wird zukünftig haben, u.a. bedingt der sowieso zunehmenden Datenmenge, HDTV, usw.

  3. Die zwei Artikel von Christoph widersprechen sich?

  4. @KISS
    Das Drama um einen Hard Fork alle paar Jahre zu wiederholen halte ich für sehr gefährlich, was man auch aktuell sieht. Deswegen bin ich für eine möglichst dauerhafte Lösung, um zumindest *dieses* Problem des Bitcoin möglichst dauerhaft zu lösen…

    @Tony Ford
    Du kannst schon heute relativ günstig einen Server mit sogar 10Gbit/s Bandbreite anmieten. Allerdings nur in Europa oder Nordamerika zu bezahlbaren Konditionen und das eben in großen Rechenzentren. Kleine Miner können in Deutschland schon froh sein, wenn sie einen VDSL Anschluss mit 10Mbit/s Uplink bekommen, in abgelegenen Gegenden ist Standard-DSL mit 1Mbit/s Uplink schon Luxus. Interkontinental sind die Verbindungen sehr begrenzt, von daher *ist* Bandbreite ein Thema und (ausgefüllte) 8GB Blöcke wären heute der sichere Tod des Bitcoin.

    Von allen BIPs, die aktuell zur Debatte stehen, halte ich Jeff Garzik’s BIP100 am sinnvollsten, denn er bringt ein gewisses demokratisches Abstimmungswerkzeug in den Bitcoin. Leider ist der Vorschlag auch der komplexeste – und daher auch der potenziell fehleranfälligste bei der Implementierung. Er ist auch nicht basisdemokratisch, denn die Abstimmung über die Blocksize liegt alleine bei den aktiven Minern und damit den großen Pools. Kein Wunder also, dass es unter Minern bereits eine Mehrheit für BIP100 gibt: http://bitcoinstats.com/network/votes/

    Basisdemokratischer wäre natürlich ein Vote über die Nutzer / Wallets / Bitcoin Guthaben, allerdings ist dieser Ansatz praktisch nicht umsetzbar, da die meisten Wallets nicht ständig oder gar nicht mit dem Netzwerk verbunden sind.

    Da allen Minern aber vor allem daran liegt, dass der Bitcoin benutzt wird und damit die Nachfrage und der Preis möglichst hoch ist, halte ich diese Art von Demokratie für vertretbar, denn der Bitcoin hängt bereits jetzt an den Minern und eine potenzielle 51% Attacke halte ich für viel gefährlicher, als die “Macht” der Miner bei BIP100, das Limit rauf oder runter zusetzen, denn dies geschieht nur, wenn mindestens 80% der geminten Blöcke dafür voten. Das verhindert, dass die großen Pools die gesamte Macht übernehmen und die Block Size ins unermessliche ansteigen lassen. Falls die Block Size wirklich zum Problem für die kleinen Pools und unabhängigen Miner ist, reichen 20% der geminten Blöcke für ein Veto aus. Zusätzlich ist eine Veränderung alle 12.000 Blöcke (ca. 3 Monate) um Maximal das Doppelte bzw. die Hälfte möglich, um gefährliche Auswüchse zu vermeiden und so die kleinen Miner auszustechen.

    Der Vorschlag schließt auch andere Ansätze (wie z.B. Side Chains) nicht aus, die das Scalability Problem auf andere Art und Weise lösen wollen, denn die Block Size wird nur bei Bedarf erhöht werden.

    Die einzige potenzielle “Schwachstelle” sehe ich im beibehaltenen 32MB Limit, das BIP100 “zur Sicherheit” beibehält und einen zweiten Hard Fork vorsieht, falls sich in Zukunft wieder ein Konsens findet.

    Das ganze Paper kann sich jeder gerne hier durchlesen. Für mich klingt der Ansatz sehr schlüssig: http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf

    TL;DR
    Für mich ist *BIP100* der eindeutig beste Vorschlag, um das Block Size Problem *dauerhaft* zu lösen, denn er nimmt zukünftige Entwicklungen nicht vorweg, sondern verleiht dem Bitcoin mehr Flexibilität. Die Komplexität führt allerdings zu einem relativ großen Entwicklungsaufwand (etwa im Vergleich zu BIP101) und einem noch größeren Testumfang im testnet.

  5. Verfolge die Diskussion schon seit Anfang an. Kann mir nicht vorstellen, dass sich bei dem Problem ein Konsens einstellt und ein Hard Fork kommt.
    Meiner Ansicht nach wird die Blockgrenze erreicht und um dann sicher zu gehen, dass eine Transaktion in den nächsten Block kommt muss man die Transaktionsgebühren erhöhen. Der Client könnte die Gebühren z.B. abhängig von der durchschnittlichen Transaktionsgebühr des letzten Blocks berechnen.

    Möglicherweise wird das Netzwerk dann für Mikropayments ineffektiv, diese Lücke könnten dann andere Altcoins oder Neuentwicklungen im Bitcoin 2.0 Bereich übernehmen, immerhin hätten sie dann einen entscheidenden Vorteil (billiger)

    Sehe das alles nicht so wild, es kommt auf die Technologie hinter dem Bitcoin an, sollte sich die erste Implementierung nicht durchsetzten werden bessere kommen. Der Markt regelt das 🙂

    Aber ist nur meine Ansicht 😉

  6. Ich kenne mich nicht wirklich aus aber warum muss es ein Limit geben? Warum kann die Blockgröße nicht frei sein? Dann könnte sie einfach so wachsen wie Transaktionen vorliegen.

  7. super, dass du das thema nochmal von einer anderen seite beleuchtet hast. deinem ersten artikel konnte ich leider nicht zustimmen. ich hätte außerdem noch erwähnt, dass XT eben NICHT nur die blocksize debate vorantreiben will, sondern dass noch ganz andere änderungen in der XT version sind. zum beispiel werden TOR-nodes im bitcoin netzwerk herabgestuft und wären nur noch bürger zweiter klasse. und noch einige andere sachen, die ich nicht ganz so heikel finde, aber auch für große diskussion sorgen sollten. für bitcoin ist es am wichtigsten, dass wir alle in geschlossener front auftreten und konstruktiv an lösungen zu problemen arbeiten, anstatt mit drohungen und ultimatums um uns zu werfen. allein die verbreitung von XT werte ich als angriff gegen das bitcoin-ecosystem und ich finde es ist eine ernsthafte diskussion wert ob man mike hearn aus dem kernentwicklerteam ausschließen sollte!

  8. BITCOIN ist nur in der form wie es jetzt ist ein problem für broker die den forex zum zocken benutzen udn das selber mit btc jetzt starten.. so mein bild des ganzen

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s