BitPays Vorstoß für Extension Blocks und alternative Clients

Colorful Straws, Bild von wiley photo via flickr.com. Lizenz: Creative Commons

BitPay, Bitmain und Purse wollen den alternativen Client bcoin etablieren und Extension Blocks bewerben. An sich ist eine Vielfalt von Entwicklerteams für ein Open Source Ökosystem gesund. Aber bei Bitcoin ist es auch gefährlich. Darum denkt ein BitPay-Entwickler darüber nach, wie verschiedene Clients den Konsens behalten können.

Bcoin von Purse hat vor kurzem mit Extension Blocks einen Vorschlag zur Skalierbarkeit gemacht, der ausdrücklich das Ziel hat, alle Seiten zu befriedigen. Andrew Lee und Purse-Entwickler JJ – die beide früher bei BitPay gearbeitet haben – haben mit BitPay und Lightning-Entwickler Joseph Poon ein Konzept vorgestellt, das als Softfork aktiviert wird, ein flexibleres Kapazitätslimit ermöglicht, Mallebility löst und, als Bonus eine Schwachstelle von Lightning beseitigt. Win-Win-Win?

Angesichts der Verflechtungen von Purse und BitPay ist es kein Wunder, dass der Geschäftsführer des Zahlungsdienstleisters, Stephen Pair, offen dafür ist, die Idee auf seinen Servern zu testen. Auf dem Blog der Firma berichtet Pair, dass JJ die Extension Blocks in bcoin – den von Purse selbst in NodeJS geschriebenen Full Client – implementiert sind und nun auch auf einem öffentlichen Testnet ausprobiert werden. “Wenn es hält, was es verspricht, werden wir es auf dem Mainnet unterstützen.”

Auch die beiden wichtigen chinesischen Miner Jihan Wu (AntPool / Bitmain) und Wang Chun (F2Pool) können sich mit der Idee anfreunden. Jihan Wu twitterte, er liebe Extension Blocks, sie seien kompatibel mit BU, während Wang Chun meckerte, dass Core 0.14.1 noch nicht bereit für den Release sei,  da Extension Blocks fehlen.

Core – und weite Teile der Community – fragen sich hingegen: Warum? Extension Blocks ist fast dasselbe wie SegWit. Softfork, mehr Kapazität, Malleability-Fix? Warum wollen die Miner (und BitPay) eine unausgereifte, kaum getestete, eilig gebaute Lösung, die womöglich die Fungibilität von Bitcoins beeinträchtigt, aktivieren? Obowhl es mit SegWit eine sorgfältig entwickelte, lange getestete Lösung gibt, die fast dasselbe macht, aber eleganter und weniger disruptiv ist? Nur weil Extension Blocks nicht SegWit sind?

Die beiden Lösungen liegen so nahe beieinander, dass es im Prinzip für beide Seiten lächerlich ist, die andere abzulehnen.

BitPay und Bitmain kooperieren für neuen Client

BitPay und Bitmain (der Firma von Jihan Wu und Antpool) scheinen sich in den letzten Wochen oder Monaten näher gekommen zu sein. Gestern stellte BitPay eine Partnerschaft mit BitMain vor: “Im Laufe der kommenden Jahre wird BitPay mit seinem neuen Kunden Bitmain eine fortschrittliche Open Source Software für Miner, Pools und Full Nodes entwickeln, die Blockchain-Transaktionen speichert und sichert.”

Es folgen einige Absätze mit freundlichen Worten, die erklären, weshalb BitPay und Bitmain klasse Firmen und perfekte Partner sind. Weitere Infos bleiben leider aus. Es liegt nicht zu fern, zu vermuten, dass Bitmain und BitPay gemeinsam die Entwicklung von bcoin vorantreiben wollen. Wäre nicht so absurd.

BitMain versucht derzeit im Allgemeinen, den Aufbau alternativer Clients zu fördern. So hat der chinesische Hersteller von Mining-Hardware bereits den  Rust-basierte Bitcoin-Client von Parity  mit finanziert.

Man kann das ganze so oder so sehen. Als Angriff auf die Core-Entwickler, als politischen Zug, um einer Gruppe von Leuten Macht zu entreissen, vielleicht sogar als Versuch der “Wirtschaft”, der Plattformen und Miner, Macht auf Kosten der Open Source Community zu gewinnen, die unabhängig von solchen Einflüssen bleiben möchte.

Man kann es auch als Dezentralisierung der Entwicklung sehen, in der verschiedenen Teams mit verschiedenen Implementierungen konkurrieren und kooperieren sollen, wie es bei bei Linux geschieht. Allerdings hat das, selbst wenn es in friedlicher Absicht geschieht, seine Nachteile. Denn Bitcoin ist nicht Linux, sondern Geld.

Warum alternative Clients eine schlechte Idee sind

“Heute wird das [Bitcoin-]Netzwerk fast ausschließlich von Mining Pools, Börsen und Full Nodes unterhalten, die eine Version der C++ Implementierung benutzen, ” stellt Jason Dreyzehner, Head of Design, fest. Weil diese extreme Monokultur für viele, die neu in der Szene sind, verwirrend und beunruhigend ist, fragt er: “Warum werden nicht mehr alternative Bitcoin-Implementierungen genutzt?”

Dreyzehner erklärt, dass alle Knoten im Netzwerk einen perfekten Konsens erhalten müssen. Dies ist extrem wichtig, und jede Abweichung vom Konsens kann für Unternehmen Downtime oder gar Verluste durch Betrug bedeuten. Er zitiert den berühmten Ausspruch von Satoshi:

“Ich glaube für keine Sekunde, dass kompatible Implementierungen von Bitcoin jemals eine gute Idee sein werden. Das Design hängt so sehr davon ab, dass alle Knoten exakt dieselben Resultate haben, weshalb eine zweite Implementierung eine Gefahr für das Netzwerk wäre.”

Dieser Ausspruch von Satoshi hat sich, so Dreyzehner, in der Vergangenheit wiederholt bestätigt. So hat Coinbase früher etwa eine Ruby-Implementierung benutzt, diese aber aufgegeben, nachdem im Jahr 2013 eine Reihe von Consens-Fehlern zu Problemen bei Transaktionen geführt hatte. Es ist in der Softwareentwicklung absurd schwierig, einen perfekten Konsens aufrechtzuhalten. “Um sicher zu sein, müssen alternative Implementierungen eine Bug-for-Bug-Kompatibilität aufrechthalten, was bedeutet, dass sie exakt dieselben Bugs implementieren müssen, die in Bitcoin Core sind.” Dreyzehner nennt kleine Bugs, etwa nicht-standardisierte Merkle-Trees, und erklärt, dass diese Bugs durch ihre Präsenz in Core zu einem Teil des Protokolls geworden sind, da Core die einzige Spezifikation von Bitcoin ist.

Diese Problematik nimmt mitunter groteske Ausmaße an: “Selbst für alternative Implementierungen, die erfolgreich die bekannten Schrullen von Bitcoin Core übernehmen, besteht das Risiko von noch nicht entdeckten Macken, die für die alternativen Implementierungen zu Zero-Day-Schwächen werden können.” Anders gesagt: Wenn es in Core einen Zero-Day, ein noch nicht bekannter Bug, gibt, dann schadet das nicht direkt Core, sondern den anderen Clienten, weil sie den Konsens verlieren.

Aus solchen und mehr Gründen warnen viele Bitcoin Entwickler davor, alternative Clients für Bitcoin zu unterhalten.

Warum eine Monokultur der Clients aber auch nicht ideal ist

Die Monokultur bei Bitcoin ist nicht unbegründet. Aber sie verursacht auch drastische Probleme. So entmutigt sie etwa neue Entwickler, die nicht nur in der Lage sein müssen, mit der nicht eben als einfach geltende Sprache C++ zu arbeiten, sondern sich auch durch den als Spaghetti-Code bekannten, über die Jahre hingweg chaotisch gewachsenene Code von Core kämpfen. Dreyzehner zitiert aus der Einleitung von Purse zur Veröffentlichung von bcoin:

“Während Bitcoin Core auf dem Schlachtfeld getested wurde und der Standard ist, ist die Codebase schwer zugänglich, selbst für erfahrene Software-Ingenieure. Das Resultat ist, dass nur eine Handvoll von Entwicklern aktiv zu Bitcoin Core beitragen kann – und nur einige Dutzend Individun es mit alle Macken vollständig verstehen.”

Des weiteren ist es für manche Projekte problematisch, eine Infrastruktur aufzubauen, die mit C++ kompatibel ist, etwa weil dafür zunächst eigene Librarys zu schreiben sind. Auch ist es oft schwierig, auch nur kleine Veränderungen in Core voranzubringen, selbst wenn diese harmlos sind, sei es, weil es keinen Entwickler dafür gibt oder sie nicht in das Konzept oder die Struktur der aktuellen Entwicklung passt, unabhängig vom Konsens.

Außerdem – und vielleicht am Schlimmsten – führt die Monokultur zu einer Politisierung der Entwicklung. Kennen wir zur Genüge. Der Grund ist, dass auseinandergehende Visionen nicht, wie bei anderen Open Source Projekten, als eigene Implementierungen um den User konkurrieren können. Stattdessen müssen Änderungen durch “politischere Methoden, durch einen Lobbyismus für einen ‘Wandel von innen'” forciert werden. Das Ergebnis ist in allen sozialen Medien rund um Bitcoin überdeutlich zu spüren: “Politik vergiftet den Diskurs und stößt Individuen ab, die Konfrontationen vermeiden.”

Schließlich besteht die Gefahr, dass es noch unentdeckte (oder noch nicht eingeführte) Bugs in Bitcoin Core gibt. Bei der derzeitigen Monokultur können diese das gesamte Netzwerk lahmlegen. Ethereum hat während der Angriffe im vergangen Herbst demonstriert, dass eine duale Infrastruktur für eine Blockchain lebensrettend sein kann.

Was also tun? Defensiver Konsens?

Dreyzehner schlägt einen “defensiven Konsens” vor. Dieser soll es erlauben, dass alternative Implementierungen nicht jeden Bug von Core reproduzieren müssen – und sogar in der Lage sind, das Netzwerk vor einem Bug in Core zu schützen – aber gleichsam nicht wegen jeder kleinsten Unstimmigkeit in den Implementierungen den Konsens verlieren und forken. Diesen defensiven Konsens skizziert der Entwickler in drei aufeinanderfolgenden Schritten:

Erstens sollen die Miner versuchen, eine Fork zu vermeiden. Dazu benutzen sie einen sogenannten Candidate Block, mit dem sie testen, ob der Block von allen wichtigen Implementierungen im Netzwerk anerkannt wird. Diese Art von Risikokontrolle durch die Miner sollte Teil des Nodes sein, ohne jedoch eine Änderung des Protokolls darzustellen.

Zweiten sollen Knoten es vermeiden, einer Fork zu folgen. Sollte es dazu kommen, müssen Unternehmen darauf achten, durch die Fork keinen Schaden zu nehmen. Dazu sollten sie aufhören, auf einer Fork Transaktionen vorzunehmen, wenn diese kontrovers wurde, und stattdessen auf einen unkontroversen Client – wie derzeit Bitcoin Core – umsteigen.

Die beiden ersten Schritte waren lediglich lokale Methoden, mit einem erhöhten Risiko von Forks durch alternative Clients umzugehen. Sie berühren nicht das Konsens-Protokoll an sich. Anders der dritte Schritt. Mit diesem soll das Ökosystem eine Fork selbst dann vermeiden, wenn es eine Änderung der Regeln bzw. Uneinigkeit über diese gibt. Dies kann passieren, wenn neue Implementierungen die Konsens-Regeln verletzen, sei es versehentlich, sei es, weil sie einen Bug in Core nicht reproduzieren, oder sei es, weil sie bewusst die Regeln ändern wollen. In diesem Fall soll ein Signalisierungsprozess, wie man ihn gegenwärtig von SegWit kennt, es kenntlich machen, welche Konsensregeln von den Minern als gültig erachtet werden. Blöcke, die diesen verletzen, werden abgelehnt und verwaist.

Mit diesem Plan, so Dreyzehner, soll Bitcoin ebenso zuverlässig im Konsens bleiben wie bisher, aber zugleich eine blühende und bunte Vielfalt von Clients in verschiedenen Sprachen erlauben.

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

9 Comments on BitPays Vorstoß für Extension Blocks und alternative Clients

  1. Jens K. // 3. May 2017 at 16:21 // Reply

    Welche BIP-Nr. hat das denn?

  2. rakete8 // 3. May 2017 at 19:45 // Reply

    Ja genau…aber so etwas haben tooBigtoFail-Übermenschen doch gar nicht nötig, die wissen sofort was das beste für uns ist.

    Das ganze heisst “Aufweichen der bestehenden (Banken)Regulierung” und wir alle kennen es schon.

    ah, übrigens, extension blocks geht gleich auf 6 mb, nein, gefragt wurde niemand.2 leute vielleicht.
    ..es ist dann auch theoretisch ein leichtes, irgendwann nur noch die neue sidechain(extension-blocks) zu minen und den rest(mainchain) einfach wegzuwerfen, theoretisch.
    Sehr sicher. wenn man jihan wu und stephen Pair(BitPay) vertraut.

    ich persönlich habe gerade alle Bitpay wallets von meinen geräten geschmissen.

    • Das ganze heisst “Aufweichen der bestehenden (Banken)Regulierung” und wir alle kennen es schon.

      Sind wir bei Bitcoin schon so weit, dass wir eine Regulierung ähnlich der Banken benötigen? Diese soll also Core übernehmen? Das wäre der endgültige Beweis, das Bitcoin gescheitert ist, weil es eben diese zentrale Regulierung nicht benötigen sollte. Glücklicherweise sind wir weit davon entfernt.

      gefragt wurde niemand.2 leute vielleicht.

      Bitpay und Purse testen etwas, was eventuell den unendlichen Blocksize Streit schlichten könnte. Sie haben sich ein Testnet eingerichtet, welches jeder selbst probieren kann, falls er möchte und an Details interessiert ist. Soweit ich erkennen kann, sind sie weiter bei Core, aber nicht abgeneigt für neue Ideen, wie man Bitcoin voranbringen kann.

      es ist dann auch theoretisch ein leichtes, irgendwann nur noch die neue sidechain(extension-blocks) zu minen und den rest(mainchain) einfach wegzuwerfen, theoretisch.

      ich persönlich habe gerade alle Bitpay wallets von meinen geräten geschmissen.

      Richtig so. Als religiöser Fanatiker glaubt man an die einzig richtige Wahrheit.

      Btw.: Wang Chun hat WhalePanda (der vor kurzem behauptet hat, dass die Bitmain Lücke Remote Code Execution zulässt und dies gleich wieder gelöscht hat) zitiert, der behauptet hat, dass Bcoin nicht reif sei, da es kein SegWit unterstütze. Daraufhin hat er geantwortet, dass Core nicht reif sei, da es keine ExtBlocks unterstütze. Der Kontext ist imho wichtig.

      Mein Fazit:
      Wir stecken seit Jahren in einer Sackgasse und der Krieg zwischen Core und den Minern führt zu nichts Gutem. Jetzt weiter alle Vorschläge zu blockieren ist fanatisch und führt mit Sicherheit zu keinem akzeptablen Ziel (für alle Beteiligten!), daher bin ich froh, dass es Leute gibt, die sich ernsthafte Gedanken (und vor allem Tests!) durchführen, wie wir eventuell aus der Misere herauskommen könnten.

      • Jörg // 4. May 2017 at 12:30 //

        Sehr geehrter Herr Janowitz,

        vielleicht nehmen Sie einmal zur Kenntnis, dass man sehr wohl von einer objektiven Wahrheit ausgehen kann, die jenseits individueller Ansichten zu erwarten ist.
        Schließlich hätten Naturwissenschaften und mathematische Argumente sonst keinen Sinn.
        Da geht es um experimentelle Überprüfbarkeit bzw. Ausschluss durch Widerspruch, persönliche Meinungen haben sich solchen Erkenntnissen unterzuordnen. Punkt.
        Religiösen Fanatismus zu unterstellen wäre wirklich absurd.

        Im Übrigen wundere ich mich, dass ausgerechnet Sie, der Sie öffentlich Darstellungen anderer wiederholt z.B. auch als “bescheuert” verunglimpfen (etwa in Ihrem Kommentar vom 28.April 2017 at 19:43 zu diesem Thema https://bitcoinblog.de/2017/04/27/feature-bug-oder-backdoor-mit-antbleed-code-kann-bitmain-antminer-per-fernsteuerung-abschalten/ ),
        sich auf so etwas wie Konsens und freie Diskussion berufen.
        Was glauben Sie denn, wo das hinführen soll?

        Aber um einmal auf eine objektive Realität zurückzukommen: die Historie des Geschehenen gehört auch dazu.
        Und war es nicht so, dass eilfertige Programmierung bereits für Probleme gesorgt hat? (Zum Beispiel hier beschrieben: https://bitcoinblog.de/2017/03/15/bug-in-bitcoin-unlimited-hacker-schaltet-mehr-als-500-nodes-aus/ ) Oder habe ich das falsch verstanden?
        Entsprechendes wüsste ich gerade von der Core-Entwicklung nicht.

        Deshalb finde ich, den Satz im vorliegenden Artikel sollte man nicht einfach überlesen:
        “Warum […] eine unausgereifte, kaum getestete, eilig gebaute Lösung, die womöglich die Fungibilität von Bitcoins beeinträchtigt, aktivieren? Obwohl es […] eine sorgfältig entwickelte, lange getestete Lösung gibt, die fast dasselbe macht, aber eleganter und weniger disruptiv ist?”

      • Sehr geehrter Jörg,
        wenn Sie darauf bestehen, sich hier nicht zu Du-zen, wie schon an anderer Stelle vorgeschlagen, OK.

        Falls Sie allerdings Bitcoin Proposals mit Naturwissenschaften vergleichen, kann ich das leider nicht so stehen lassen. Oder können Sie die Entwicklung des Bitcoins nach Segwit oder gar Lightning Network naturwissenschaftlich oder mathematisch beweisen?

        Ich habe zu keinem Zeitpunkt behauptet, ich wäre objektiv, denn das ist (m)eine Meinung (die ich hier Kund gebe) nie. Bei etlichen Kommentaren habe ich dies sogar betont. Bitcoin ist für mich in erster Linie ein basisdemokratisches System, welches von verschiedenen Meinungen lebt und schlussendlich auf einem Konsens aufbaut, den die Mehrheit trägt. Ob ich diesen Konsens dann gut, in Ordnung, schlecht oder gar bescheuert finde, ist eine andere Sache und ich äußere meine Meinung dazu. Es gibt schlichtweg keine “objektive Realität”.

      • Jörg // 4. May 2017 at 15:58 //

        Sehr geehrter Paul Janowitz,

        zunächst danke für die Antwort.
        Sprachen nicht Sie oben mit Bezug auf den Kommentar von “Wahrheit” bzw. gar “religiösem Fanatismus”?
        Aber ich will keine Haarspalterei betreiben.
        Mir geht es eben auch darum, dass es doch verschiedene Meinungen bzw. Wertungen geben kann.
        Andere Standpunkte allerdings mit abfälligen Attributen zu belegen, finde ich wenig zielführend.
        Eine offene Diskussion setzt meiner Meinung nach soviel Toleranz voraus, die gegenteilige Ansicht zu respektieren.

        Schade, gerade Sie verfügten doch auch über gute Argumente.

      • Vielen Dank für Ihre konstruktive Kritik, immerhin sind wir scheinbar auf einem Guten Weg zur Diskussion! Ich werde in Zukunft noch stärker darauf achten, andere Meinungen nicht zu stark zu bewerten.

        Den naturwissenschaftlichen Beweis bleiben Sie mir aber schuldig…

      • Carmen // 5. May 2017 at 11:12 //

        …emotionale Argumente in einer technischen Diskussion, das ist eigentlich nie ein gutes Zeichen…

        -http://theoatmeal.com/comics/believe

        einen schönen Frühling uns allen.

      • Jörg // 5. May 2017 at 14:13 //

        Das freut mich. Euch auch ein schönes Wochenende!

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