Bitcoin Cash plant die nächste Hardfork

… und stürmt direkt in eine Kontroverse. Dabei geht es vor allem um einen Vorschlag, native Token auf die Blockchain zu bringen. Zwar feiert die Community den Streit und freut sich auf die Reaktivierung von zahlreichen Skriptbefehlen – doch es bleiben auch Zweifel über die Rolle von nChains Patenten in der Entscheidungsfindung.

Bitcoin Cash wollte eine dezentrale, unzensierte Diskussion der Entwicklung. Nun bekommt die Community zu spüren, wie anstrengend das sein kann.

Die beteiligten Entwickler-Team, etwa XT, Unlimited und ABC, haben vereinbart, es es regelmäßig Protokoll-Upgrades per Hardfork geben soll. Die erste Hardfork soll Mitte Mai bestimmt und später aktiviert werden. Wenn die Intention jedoch war, einen Rahmen zu etablieren, um friedlich und kontstruktiv solche regelmäßigen Hardforks zu planen – dann nimmt sich der Erfolg bescheiden aus. Denn die Diskussion war weder konstruktiv noch friedlich.

Zur Debatte steht die Reaktivierung deaktivierter Op_Codes von Bitcoins Skriptsprache, die Erhöhung der maximalen Blockgröße auf 32 Megabyte und die Erhöhung des Limits für Op_Return-Inhalte von 80 auf 220 byte. Wann genau und wie die Hardfork stattfinden soll, ist nicht klar. Angepeilt ist, dass die Hardfork am 15. Mai stattfindet, aber es gibt noch keine offizielle Ankündigung, dass dem auch tatsächlich so sein wird. Am 15. Februar war das „Feature Freeze“ – ab diesem Tag war die Deadline für die Aufnahme neuer Featurs in die Debatte.

Op_Group: Eine Konkurrenz zu ERC20?

Dass der Ablauf der Planung alles andere als befriedigend ist, zeigt das Beispiel Op_Group. Mit diesem neuen Op_Code hat Andrew Stone von Bitcoin Unlimited eine Möglichkeit vorgeschlagen, um native Token auf die Bitcoin Cash Blockchain zu bringen. Wer sich schon einmal mit Token, Ethereums ERC20, ICOs und Colored Coins beschäftigt hat, weiß, dass dies eine große Sache sein kann. Es ermöglicht unter anderem, Token in SPV-Wallets zu bringen und diese unabhängig von externen Protokollen, wie Colored Coins oder Counterparty, zu prozessieren.

Wenn Bitcoin Cash hinsichtlich von Token mit Ethereum mithalten möchte, ist etwas wie Op_Group unbedingt notwendig. Dementsprechend fand Andrew Stones Vorschlag recht viel Sympathie, beispielsweise von OpenBazaars Chris Pacia, und die Hardfork im Mai schien eine gute Gelegenheit zu sein, dieses auf solide und direkte Weise zu implementieren. Da Andrew Stone sein Konzept bereits im Oktober 2017 veröffentlicht hatte, sollte auch genügend Zeit dafür gewesen sein, dieses zu testen und zu durchdenken.

Nun wird aber Bitcoin ABC, die Referenz-Software von Bitcoin Cash, Op_Group vermutlich nicht in die Liste von Upgrades aufnehmen, die für die Hardfork im Mai in Frage kommen. Die Gründe dagegen sind nicht ganz durchsichtig. Shammah Chancellor von ABC stellte eine Liste von neun Bedingungen für perfekte Token auf und erklärte, dass Op_Group diese nicht erfülle. Craig Steven Wright, der wohlbekannte angebliche Satoshi und Chefentwickler von nChain, erkärte per Twitter, dass Op_Group unnötig und nicht ausreichend getestet sei. Jonald Fyookball, der Chefentwickler von Electron Cash, erklärte, dass Op_Group potentiell gefährlich sei, da es, anders als andere Skripte, Transaktionen außerhalb des Skript-Interpreters ändere. Dies ohne umfangreiche Tests einzuführen, sei ein zu großes Risiko.

Auf der anderen Seite wird auch gesagt, dass Op_Group niemals diskutiert worden sei, und dass es von Bitcoin Unlimited auch keine Versuche gegeben habe, es als Kandidat für die Hardfork einzubringen. Was irgendwie auch Sinn ergibt, da Op_Group auch per Softfork eingeführt werden kann. Ob nun so oder so – all dies klingt nicht eben nach Sonnenschein und einer konstruktiven Zusammenarbeit. Auch dass Andrew Stone von Bitcoin Unlimited die Kritik von Bitcoin ABC anfechtet, zeigt, dass hier nicht wirklich Einigkeit herrscht.

Satoshis verlorene Op_codes

Dass OP_Group auf eine nicht eben transparente Weise nicht in die Kandidaten der Hardfork-Features eingeht, ist schade – insbesondere, weil es das einzige zur Debatte stehende Feature ist, das einen einfach zu erkennenden Mehrwert für Nutzer hat. Native Token auf der Blockchain sind spitze und notwendig, falls Bitcoin Cash vorhat, jemals mit Ethereum zu konkurrieren.

Wesentlich weniger offentlichtlich ist der Nutzen von neun OP_Codes, die reaktiviert werden sollen. Satoshi hat diese Codes im ursprünglichen Design implementiert, doch nachdem einer von ihnen eine Sicherheitslücke hatte, wurden alle Op_Codes, die man nicht unbedingt brauchte, deaktiviert. Bitcoin Cash möchte nun so viele davon wie möglich wieder aktivieren. Zur Debatte stehen Op_Mod, Op_Div, Op_Cat, Op_Split, Op_and, Op_or, Op_Xor, Op_num2bin und Op_bin2num. Diese Codes stellen verschiedene Befehle für die Skriptsprache von Transaktionen dar, mit denen man verschiedene Smart Contracts bilden kann. Sie erlauben einfache Operationen, etwa die Verkettung von zwei Variablen.

Eine konkrete Anwendung scheint dabei aber niemand vor Augen zu haben. Zumindest konnte mir niemand der Entwickler genau sagen, was man mit den Op_Codes machen kann, außer, dass sie viel mehr Befehle und Smart Contracts ermöglichen. Die konkretesten Anwendungen, die ich herauskitzeln konnte, waren eine Lotterie auf der Blockchain sowie die Neuerfindung von Multisig. Auch eine öffentliche Diskussion der mit den Op_Codes verbundenen Risiken bleibt bisher aus, auch wenn die Entwickler diverse Maßnahmen und Tests eingerichtet haben. Dennoch ist für die Community relativ unklar, zu welchem Zweck man welche Risiken eingeht.

Die Rolle von nChain und den Patenten

Eine der unangenehmsten Aspekte der Hardfork sind die Zweifel, welche Rolle nChain dabei spielt. Zur Erinnerung: nChain ist die Firma von Craig Steven Wright, über die er bisher nach eigener Angabe mehr als 200 Patente angemeldet hat. Angeblich sollen diese Patente die von Craig Wright entwickelten Technologien lediglich davor schützen, auf anderen Chains als Bitcoin Cash verwendet zu werden. Selbst wenn dies so wäre – ich weiß nicht, ob das überhaupt rechtlich möglich ist – wäre dies durchweg kritisierenswert. Denn Bitcoin Cash definiert sich selbst dadurch, sich durch eine Hardfork von Bitcoin abgespalten zu haben.

nChain hat sich mittlerweile einen beträchtlichen Einfluss im Ökosystem von Bitcoin Cash erarbeitet. Es unterstützt unter anderem Yours und Electron Cash und hat an den Verhandlungen zur Hardfork teilgenommen. Dass nChain mehrere Patente zu Token auf einer Blockchain hat (etwa hier, hier oder hier), macht es zumindest schon mal ein Stück fragwürdig, dass die Firma in einen Entscheidungsprozess involviert ist, der Op_Group zumindest mal nicht unterstützt hat. Auch ein Verdacht, dass die nun zu reaktivierenden Op_Codes bereits Teil von Anwendungen sind, die nChain patentieren lassen hat oder patentieren möchte, wurde bisher nicht widerlegt oder auch nur entkräftigt.

Selbst wenn sich all jene Zweifel als unbegründet erweisen würde, wenn nChains Patente nichts, aber auch gar nichts mit den Entscheidungen zur Hardfork zu tun hätten – selbst dann bliebe ein schaler Beigeschmack, dass Bitcoin Cash es erlaubt, dass eine Firma mit einer solchen Patentwut einen solchen Einfluss im Ökosystem gewonnen hat.

Ganz abgesehen davon muss die Kryptowährung die Sache mit der öffentlichen, dezentralen Planung und Diskussion von Hardforks noch üben. Ansonsten ist dies ein Rezept für ein Desaster.