Stress, Kampf, Konsens

"Tauziehen / St. Marien / Wismar" von Harald Henkel via flickr.com. Lizenz: Creative Commons

Neues von der Blocksize-Debatte: Ein weiterer Stress-Test, verhärtete Fronten zwischen Befürwortern und Gegnern größerer Blöcke, eine Untersuchung und ein möglicher Konsens.

Die Blocksize-Debatte wird mehr und mehr zur Gretchenfrage des Bitcoins: Blöcke erhöhen – oder lassen wie sie sind? Wenn man das Thema hängen lässt, bleibt das Scalability-Problem bestehen und der Bitcoin wird niemals mehr als 5-7 Transaktionen je Sekunde prozessieren können. Der Traum der neuen Weltwährung wäre damit ausgeträumt. Wenn man dagegen die maximale Größe von Blöcken erhöht, steht eine Hard Fork an, die das ganze Netzwerk zerreisen könnte. Diese vertrackste Debatte setzte sich in der vergangenen Woche fort.

Stress!

In dieser Woche wurde das Bitcoin-Netzwerk einem erneuten Stresstest unterzogen. Stresstest bedeutet hier, das Netzwerk an die Grenzen seiner Belastung zu bringen und zu analysieren, was dabei passiert. Die Walletplattform coinwallet.eu hat knapp 500 Dollar an Transaktionsgebühren bezahlt, um die Blockchain für 12 Stunden bzw. 100 Blöcke mit Transaktionen zu spamen. Das Ziel war es, den Mempool mit den unbestätigten Transaktionen auf 200 Megabyte anwachsen zu lassen. Nach dem Stresstest hat coinwallet über die Resultate berichtet.

Während des Stresstests haben sich die Transaktionen verzögert und der Mempool ist angeschwollen. Allerdings nur auf bis zu 12 MB, womit das Ziel von 200 MB weit verfehlt wurde. Im Bitcoin-Netzwerk war der Stresstest dennoch zu spüren: Bis zu 15.000 Transaktionen hingen in der Warteschleife; wer mit MultiBit Bitcoins mit einer Standardgebühr versendete, musste bis zu 80 Blöcke warten; angeblich waren die API von blockchain.info und BitPay überlastet, was zu Ausfällen von mywallet, diversen Bitcoin-Automaten und zu Verwirrungen bei Zahlungen führte.

Ein nachhaltiger Schaden ist dem Netzwerk gleichwohl nicht entstanden. Der Stresstest kam und ging, die Miner haben die Transaktionsgebühren eingesammelt und die Blockchain hat die unbestätigten Transaktionen zuverlässig abgearbeitet. Wer während des Stresstests hohe Gebühren bezahlt hat, konnte seine Überweisung auch in einer ordentlichen Zeit bestätigen lassen. Dennoch verdeutlicht der Stresstest, wie wenig Mittel man tatsächlich benötigt, um das Bitcoin-Netzwerk zu verlangsamen oder erheblich teurer zu machen: keine 1.000 Euro am Tag. Mit größeren Blöcken wäre ein solcher Transaktions-Spam-Angriff weiterhin möglich, aber erheblich teurer.

Kampf!

Der Krieg um die Blockgröße tobt derweil weiter. Einige Fronten scheinen sich zu verschärfen. Gavin Andresen ist der Liebling des Publikums, das klar größere Blöcke wünscht. Wer möchte schon, dass der Bitcoin ein Nischen-Zahlungsmittel bleibt? Auf der anderen Seite stehen Kernentwickler wie Gregory Maxwell, Peter Todd und Adam Back, die größere Blöcke für unnötig oder inadäquat halten und eine Hard Fork fürchten.

Gavin Andresen hatte ja eigentlich vorgeschlagen, die Blöcke auf 20 MB zu vergrößern und diesen Vorschlag mit einer Modellierung untermauert, derzufolge diese Größe zu bändigen sein sollte. Allerdings fand er für diese Idee keine Mehrheit unter den Kernentwicklern. Daraufhin entfachte ein öffentlicher Konflikt, der sich auch um die Frage dreht, was der Bitcoin sein soll: ein vor allem dezentrales und sicheres Zahlungsnetzwerk für besondere Zwecke und große Überweisungen – oder ein Alltags-Zahlungsmittel für alles, vom Kaffee bis zum Volkswagen? Diese Frage droht, eine Kluft in die Bitcoin-Community zu treiben.

Nachdem Gavin Andresen also mit seinem 20-MB-Vorschlag aufgelaufen ist, hat er (öffentlich) mit dem Gedanken gespielt, die größeren Blöcke in Bitcoin XT – einer Bitcoin Core Fork von Mike Hearn – einzuspielen und die Community und Unternehmen zu überzeugen, von Core auf XT umzusteigen. In einem Interview hat Mike Hearn nun noch Öl ins Feuer gegossen: Er sagte, die für ihn ideale Lösung wäre es, wenn Andresen den anderen Entwicklern den Zugang zum Bitcoin Core Projekt einfach entzieht, die Änderungen einbaut und sagt, dies sei die Entscheidung, die gefallen sei. Sympathien gewinnt man so nicht. Erst recht nicht bei einer Community, für die Freiheit und Dezentralität zentrale Werte sind.

Auch auf der anderen Seite machen sich Erscheinungen der Verbohrtheit bemerkbar. So hat Suhas Daftuar von Chaincode Labs – einem New Yorker Kryptocoin-Entwicklungslabor – in einem Blogbeitrag auf Medium gleich das Scheitern des Bitcoins angedroht. Alleine schon die Forderung von Gavin Andresen, eine Hard Fork zur Vergrößerung der Blöcke zu starten, sei unverantwortlich und brandgefährlich. Eine Hard Fork sei ok, wenn absolute Einigung und Notwendigkeit bestehe. Etwa wenn es darum geht, einen essenziellen Bug zu beseitigen.  Aktuell bestehe allerdings weder eine Einigung noch eine Notwendigkeit, weshalb eine Hard Fork den Bitcoin in einen alten (mit kleinen Blöcken) und einen neuen (mit großen Blöcken) spalten könnte. Ein Wahnsinn, der den Sinn des Bitcoin-Projektes – ein dezentrales Netzwerk ohne “Authority” zu sein – ruiniere. Es drohen nicht nur Konfusion und Verluste durch Double-Spends und falsche Chains, sondern auch ein Angriff auf den Bitcoin als Medium der Wertaufbewahrung an sich.

Wissenschaft statt Getöse

Auf reddit hat die Diskussion zwischenzeitlich ein bedenkliches Klima angenommen. Die eine Seite schimpfte auf Gavin, der sich als Diktator gebäre und angeblich nicht fähig sei, den durchdachten Argumenten anderer Kernentwickler zu folgen. Die andere Seite schimpft auf jene Kernentwickler, wirft ihnen vor, keine eigenen Lösungsvorschläge vorzulegen und Interessenskonflikte zu haben, weil einige von ihnen bei Blockstream arbeiten, einem Unternehmen, das Sidechains entwickelt, welche eine alternative Lösung für das Scalability-Problem bieten (aber noch nicht mal als überzeugender Prototyp bestehen). Eine dritte Seite schließlich erinnert daran, dass sich jeder einig ist, dass man die Skalierbarkeit des Bitcoins an sich und auch die Blöcke im speziellen erhöhen muss, aber man sich noch nicht einig ist, wie genau das funktionieren soll, weshalb man nicht auf übereilte Entscheidungen drängen sollte.

Zu dieser Seite dürfte wohl auch Nick Szabo tendieren. Szabo gilt immer noch als heißester Kandidat auf den wahren Satoshi Nakamot, da er auf der einen Seite schon vorher BitGold entwickelt hat und auf der anderen Seite ein breites ökonomisch-philosophisches Wissen besitzt. Szabo twitterte in den Streit hinein: “Wir brauchen mehr Computer Science und weniger Lärm.”

Vor einer so wichtigen, großen und gefährlichen Entscheidung wie einer Hard Fork des Bitcoins, die alles zerstören kann, sollte man die erwarteten Konsequenzen tatsächlich genau und gründlich durchrechnen und abwägen. So hat Szabo etwa selbst aus einer Analyse von 20-MB-Blöcken herausgelesen, dass Angreifer duch das Veröffentlichen von extragroßen Blöcken reichlich Chaos anrichten könnten. Ebenfalls Probleme mit größeren Blöcken zeigt eine Analyse von Tradeblock über den Zusammenhang zwischen der Größe von Blöcken und der Dauer ihrer Verbreitung im Netzwerk, die demonstriert, dass jene mit dieser ansteigt. So benötigt ein Block mit 300 kb etwa 6 Sekunden, um 3.000 Knoten zu erreichen, während ein Block mit 800 kb bereits 16 Sekunden braucht. Ein Block mit 8 MB würde, so eine Hochrechnung von Tradeblock, demnach 137 Sekunden benötigen, um sich im ganze Netzwerk auszubreiten. Für die Miner wären dies 137 Sekunden, in denen sie potenziell auf der falschen Blockchain minen könnten. Ein Szenario, das eine weitere Problematik größerer Blöcke aufzeigt.

Consens?

Die Situation ist also verworren. Es gibt nur wenige Entwickler, die fähig sind, eine Erhöhung der Blockgröße in all ihren Konsequenzen zu durchschauen, aber eine riesige Community, die durch das Betreiben von Clienten ein Stimmrecht hat; es gibt eine unbedingte Notwendigkeit, das Scalability-Problem zu lösen, aber widersprüchliche Lösungswege und schwer zu durchschauende Risiken.

Dennoch scheint sich langsam so etwas wie ein Konsens herauszuperlen. Gavin Andresen hat seine ursprüngliche Absicht, die Blöcke auf maximal 20 MB zu vergrößern, aufgegeben und stattdessen einen BIP (=Vorschlag für eine Ergänzung des Bitcoin-Protokolls) eingereicht, in dem er eine Erhöhrung auf maximal 8 MB ab dem 11. Januar 2016 vorschlägt – wenn bis dahin 750 von 1.000 vergleichbaren Blöcken ein abgestimmtes Zeichen der Zustimmung enthalten (eine Versionsnummer mit einer bestimmten hex). Dann wird die Aktivierung der Änderung zum 11. Januar 2016 eingeleitet. Anschließend sollte die maximale Größe abhängig vom Bedarf linear ansteigen mit einem Limit von 8 Gigabyte zum 1. Januar 2036. Kurz: 8 MB ab dem 11. Januar 2016, aber nur, wenn 75 Prozent der Miner zustimmen; danach ein gradueller Anstieg je nach Bedarf, gedeckelt auf 8 Gigabyte 2036.

Während andere Kernentwickler weiterhin skeptisch bleiben bzw. sich noch nicht zum Vorschlag geäußert haben, haben immerhin die drei größten Mining-Pools Chinas Zustimmung signalisiert. Da diese mehr als 25 Prozent der Hashrate ausmachen und wohl auch einen großen Einfluss auf die chinesischen Börsen und anderen Pools haben, wären damit einige der wichtigsten Parteien mit im Boot.

About Sascha Nierste (34 Articles)
Hat Soziologie studiert und arbeitet unter anderem als freier Autor. Für das Bitcoinblog kümmert er sich mit Vorliebe um Neuigkeiten und Akzeptanzstellen.

4 Comments on Stress, Kampf, Konsens

  1. Frankfurter Würstchen // 26. June 2015 at 20:08 // Reply

    Die Änderung der Blockgröße ist wirklich keine triviale Sache. Gerade die größere Zeit zur Verbreitung des Tradeblocks ist nicht von der Hand zu weisen. Mittelfristig notwendig ist eine größere Blockchain imho schon. Der Kompromissvorschlag (8 MB und linearem Anstieg) klingt schon mal gut.

    Keine leichte Entscheidung jedenfalls.

    P.S.: Gut erklärt! Toller Blockpost, danke.

  2. Sehr guter artikel! Für mich persönlich steht jedenfalls fest, dass blöcke größer werden müssen und dass es nur eine frage der Zeit ist

  3. Carsten Otto // 26. June 2015 at 22:55 // Reply

    Die Änderung wird frühestens zum 11. Januar aktiv. Wenn bis dahin keine 75% dafür gestimmt haben, wird eben auf die 75% gewartet.

  4. Wahnsinn wie sehr man sich mit solch Banalitäten beschäftigen kann. Später wird man sagen, dass diese ganze Debatte völlig überflüssig war und vor allem auch die Argumente gegen eine Erhöhung an den Haaren herbeigezogen sind. Es gibt schlichtweg keinen einzigen vernünftigen Grund, die Blockgröße nicht zu erhöhen.

    Weder erhöht es die Margen oder Einnahmen der Miner noch führt dies die Rechner und Netze an ihre Grenzen. Im Gegenteil, es macht die Transaktionen langsamer und teurer, so dass man sich als Bitcoiner die Frage stellt, worin dann noch der Vorteil bestehen soll.
    Vor allem die Kernentwickler auf der gegnerischen Seite verstehe ich nicht, denn man kann davon ausgehen, dass sie selbst im Besitz einer soliden Menge an Bitcoin sein werden und sie an einer weiteren Verbreitung interessiert sein müssten.

    Die Erhöhung auf 8MB finde ich einen schlechten wenn auch vermutlich unausweichlichen Kompromiss, weil wir dann die gleiche Diskussion zwei Jahre später erneut führen müssen.
    Meiner Meinung nach wäre eine Ausweitung auf 200MB nachhaltig, dann würde man für Jahre vorsorgen und ein klares Zeichen dafür setzen, dass man mit dem Bitcoin mehr vor hat als nur den Zweck einer Privatwährung einer elitären Klientel erfüllen zu wollen.

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