Newsticker

Bitcoin Cash: Fork gelingt offenbar

Eine maximale Blocksize von 32 Megabyte, größere Nachrichten im OP_Return-Feld, und eine Handvoll neue opcodes: Bitcoin Cash hat gestern Abend erneut eine Hardfork vollzogen. Negative Nebenwirkungen scheint das Upgrade bisher nicht zu haben.

Die einen nennen es Hardfork, die anderen ein Upgrade: Wenige Dinge rufen so große Meinungsverschiedenheiten hervor wie die netzwerkweite, nicht abwärtskompatible Regeländerung bei Bitcoin. Während die Bitcoin-Entwickler selbst sich weiterhin davor scheuen, eine Hardfork zu benutzen, weil sie fürchten, damit das Netzwerk spalten zu können, verstehen die Bitcoin-Cash-Entwickler die Hardfork als ganz normales Instrument, um das Protokoll weiter zu entwickeln.

Gestern Abend haben sie einmal mehr vorgeführt, dass die Hardfork, zumindest bei Bitcoin Cash, tatsächlich nur eine Methode für ein Upgrade ist. Bei Block 530.350 – etwa gestern Abend um halb sieben – wurde die Hardfork eingeleitet, sechs Blöcke später wurden die Änderungen der Regeln aktiviert. Nodes, die das Upgrade nicht eingespielt haben, werden nun nicht mehr Teil des Netzwerks sein, sobald ein Block erscheint, der die neuen Regeln nutzt.

Die Hardfork hat vor allem drei Änderungen:

Erstens wird die maximale Blocksize von bisher 8 MB auf 32 MB erhöht. Bei alltäglichen Transaktionsmustern bedeutet dies, dass Bitcoin Cash damit die Kapazität für etwa 11.200.000 Transaktionen am Tag oder 130 Transaktionen in der Sekunde hat. Genutzt wird davon bislang aber noch nicht sehr viel. Im Durchschnitt gibt es bei Bitcoin Cash etwa 0,3 Transaktionen je Sekunde oder etwa 20.000 am Tag. Eine gute Visualisierung dieses etwas traurigen Zustandes gibt die Webseite TX-Highway wieder. Die Autobahn wurde auf 32 Spuren erweitert, obwohl so weit das Auge reicht nur ein Auto zu sehen ist.

Zweitens wird die Größe der Standard-Nachrichten im System von bisher maximal 80 auf bis zu 220 Bytes erhöht. Dies ist besonders wichtig für OP_Return, eine beliebte Methode, um Nachrichten in die Blockchain zu schreiben. OP_Return wird genutzt, um Token wie Colored Coins oder Counterparty auf die Blockchain zu bringen und wurde in letzter Zeit vor allem durch Memo.Cash, eine Art Twitter auf der Bitcoin Cash Blockchain, bekannt. Dank der Hardfork passen nun 220 anstatt vorher 80 Zeichen in einen Tweet Memo. Wie der Screenshot, den ich als Titelbild verwendet habe, zeigt, wird davon auch schon rege Gebrauch gemacht:

Der dritte Teil der Hardfork ist am schwierigsten zu verstehen, den Entwicklern zufolge aber am wichtigsten: Es wurde eine Reihe von Op-Codes, die ursprünglich im Bitcoin-Code waren, aber abgeschaltet wurden, reaktiviert. Op-Codes sind ein Teil der Skriptsprache von Bitcoin, mit der üblicherweise Transaktionen verifiziert werden. Reaktiviert werden nun die folgenden Codes: OP_CAT, OP_SPLIT, OP_AND, OP_OR, OP_XOR, OP_DIV, OP_MOD, OP_NUM2BIN, OP_BIN2NUM.

Was man damit konkret machen kann, ist schwer zu sagen. Steve Shadders, der Entwickler von BitcoinCashJ, und derjenige, der die Reaktivierung der Codes als erstes vorgeschlagen hat, erklärt es so: „Unter Entwicklern könnte man sagen, dass die Anwendungsmöglichkeiten von fundamentalen Operationen einer Skript-Sprache so gebräuchlich sind, dass man sie gar nicht aufzählen muss. Wir benutzen solche Basis-Operationen wie Mathematik, String-Operationen und Bitwise-Logik jeden Tag so oft, dass es beinah unmöglich ist, einen nützlichne Code ohne sie hervorzubringen.“

Ein Stück konkreter wurden heute bereits Chris Pacia von OpenBazaar und Emil Oldenburg von Bitcoin.com. Pacia hat mithilfe von OP_CAT eine Multisig-Adresse gebildet, die auf einem Merkle-Tree beruht. Diese Methode hat den Vorteil, dass die öffentlichen Schlüssel, die bei einer Auszahlung nicht beteiligt sind, auch nicht veröffentlicht werden, und dass die benötigte Datenmenge bei einer zunehmenden Anzahl involvierter Parteien deutlich sinkt. Das Verfahren wurde, soweit ich weiß, unter dem Arbeitstitel „MAST“ von Blockstream für die Sidechain Alpha entwickelt. Oldenburg hat derweil mithilfe von OP_XOR eine Rätsel-Transaktion gebildet. Ob und wie nützlich dies alles sein wird, ist derzeit noch nicht zu sagen. Wer Interesse (und genügend Kenntnisse) hat, kann auf dem OpCodes-Spielplatz mit den neuen Codes experimentieren.

Probleme sind auch gut 16 Stunden nach der Hardfork noch nicht aufgetreten. Es gibt keine Bewegung dafür, die alte Bitcoin Cash Chain („Bitcoin Cash Classic“) zu erhalten, keine Anzeichen dafür, dass die Anzahl der aktiven Full Nodes eingebrochen ist (weil sie verpasst haben, rechtzeitig zu upgraden), und keine Berichte über Börsen oder Wallets, die von der Blockchain abgehängt wurden. Auch Befürchtungen, die neuen OpCodes würden neue Angriffsvektoren eröffnen, haben sich bislang noch nicht bestätigt. Aber es dürfte noch zu früh sein, um hierzu irgendetwas mit Sicherheit zu sagen.

Auf den Kurs scheint diese an sich gute Nachricht aber keinen Einfluss zu haben. Heute purzeln die Preise aller Kryptowährungen, und Bitcoin Cash macht dabei nicht nur keine Ausnahme, sondern stürzt mit besonders hohen Verlusten sogar voran.

Über Christoph Bergmann (2802 Artikel)
Das Bitcoinblog wird von Bitcoin.de gesponsort, ist inhaltlich aber unabhängig und gibt die Meinung des Redakteurs Christoph Bergmann wieder ---

23 Kommentare zu Bitcoin Cash: Fork gelingt offenbar

  1. BCash. LOL.

    • Kannst du mich aufklären, was du mit dem peinlichen Kommentar eigentlich kommunizieren möchtest?

    • Christoph, ich wollte dir eigentlich vorschlagen, solche Kommentare einfach zu löschen. Aber vllt. ist es besser, das so stehen zu lassen, damit jeder sehen kann, wie die Bitcoin Core community vorgeht.

  2. Was ist mit den 18% der Nodes, die nicht upgegradet haben und aktuell nicht den Consensus-Regeln folgen? Kein Problem? https://cash.coin.dance/nodes

  3. Ich möchte darauf hinweisen, dass dies [BTX]Bitcore (Virtueller Fork von Bitcoin) noch vor BitcoinCash, gemeistert hat. Zwar nur mit 10 MB (20 MB mit SewWit) aber dafür 2.5 Minuten Blocktime. Somit kommt das ganze auf ca. 42 Mio Tx pro Tag. Es wurde schon live 5 Mio Tx am Tag durchgeführt. Und und und 😉 Made in Germany !

  4. Der unbekannte Mining Pool „rawpool“ hat seinen Node nicht geupdated und hat so mindestens 3 verwaiste Blöcke produziert.

    • Weiter oben steht die Lösung, aber hier noch Mal für den konkreten Hard Fork Block 530356 und seinen Hash für die Faulen:

      bitcoin-cli invalidateblock 0000000000000000013d91e08ec61cc99761751ef09c561209593eea6bb543da

      • Grégoire Lambert // 17. Mai 2018 um 0:35 //

        18% der Nodes nicht kompatibel. „Problemlos.“

      • Die Gesamtzahl der aktiven Nodes ist nicht gesunken
        https://cash.coin.dance/nodes/all

        Es gibt keine irgendwie relevante Fortsetzung der alten Chain (ein Pool hat versehentlich drei oder vier Blöcke erzeugt, es dann aber gelassen).

        Also: Mehr als ausreichend aktive Nodes, keine Abspaltung einer „Classic“-Chain –> „problemlos“

  5. herzmeister // 16. Mai 2018 um 20:19 // Antworten

    https://txhighway.cash/ is the real txhighway!

  6. Mmh, also unabhängig davon, dass jedenfalls zur Zeit keiner die 32 MB Blöcke benötigt, frage ich mich doch, ob denn 32 MB reichen würden, wenn die Währung mal wirklich unter Volllast laufen soll. Über 100 Transaktionen pro Sekunde hört sich ja erstmal viel an, aber schafft Visa nicht über das 10fache? Und was passiert, wenn die 32 MB tatsächlich irgendwann nicht mehr reichen (obwohl ich davon ausgehe, das BCH niemals diese Bedeutung in der Praxis erlangen wird)? Wird dann auf 64 MB upgegraded? Das würde doch auch nicht so viel bringen, bleibt doch die Latenz, mit der ein neuer Block gefunden wird, bei rund 10 Minuten. Das dürfte doch der limitierende Faktor sein, egal wie hoch die Blocksize ist, oder hab ich da was falsch verstanden?

    • „Fakesatoshi“ Craig Wright erklärt die Vision dahinter auf der Consensus ganz anschaulich und der Vortrag ist durchaus interessant:

    • um an einen neuen Block zu minen langt es den Header des neuen Blocks zu haben. D.h. es macht für den Miner keinen Unterschied wie groß der Block ist er kann sofort anfangen einen weiteren block zu generieren wenn er den Header hat. Theoretisch gesehen sollte der komplette block auch auf Korrektheit geprüft werden. In der Praxis kann dies jedoch zu einem späteren Zeitpunkt geschehen, da der Erzeuger des Blockes einen sehr großen finanziellen Anreiz hat einen korrekten Block zu erstellen.
      Wo das Limit ist? Es gibt theoretisch gesehen keines, da die Blockchain selber (nicht der jetzige code) auf beliebig viele Rechner parallelisierbar ist. D.h. wenn man 100x mehr Transaktionen will braucht man 100x mehr Rechner / Rechenleistung. Da bei 100x auch 100x mehr Transaktionsgebühren zu erwarten sind, sollten die zu erwartenden Gebühren reichen um dies auch zu finanzieren. Somit gibt es rein technisch und rein ökonomisch eigentlich kein Limit solange die Transaktionsgebühren die Kosten decken.
      Faktisch gibt es natürlich derzeit noch ein Limit, da der derzeitige Code noch keine lineare Skalierung erlaubt, hier gibt es noch einige Hürden zu nehmen.
      Die eigentlich Frage ist somit nicht ob es technisch oder ökonomisch machbar ist, sondern ob man nicht die Dezentralitaet opfert wenn immer weniger in der Lage sind die komplette Blockchain zu verifizieren.
      Dazu kann man sagen, dass man die Verifizierung der Blockchain selber auch verteilen kann, d.h. es muss nicht jeder jeden teil der blockchain bestätigen.
      Eigentlich ist es sogar unnötig überhaupt die komplette Blockchain zu bestätigen um eine Zahlung zu verifizieren.

      • Martin // 17. Mai 2018 um 11:29 //

        ökonomisch gesehen gibt es noch ein Problem für kleine Miner. Wenn ein Miner den Block noch nicht verifiziert hat, weiß er in der Regel nicht welche Transaktionen in dem Block sind und welche nicht. D.h. er wird deswegen in der Regel keine neuen Transaktionen in seinen Block packen, solange er dies nicht weis. D.h. je grösser der Block wird, desto grösser der Vorteil von großen Minern gegenüber von kleinen Minern. Dies könnte man dadurch umgehen, dass sich die Miner im Vorfeld auf einen Block-Kandidaten einigen, dies würde auch den Vorteil haben, dass ein double spend nach schon wenigen Sekunden ausgeschlossen werden kann.
        Auch wird das Problem dadurch stark vermindert, dass ein Miner wenn er einen neuen Bock erhält nur die Transaktionen anfordern muss die er noch nicht selber hat.

    • Man wird in Zukunft die Kapazität weiter erhöhen. 11 Millionen Transaktionen pro Tag sind schon mal genug, damit ein sehr großer Onlinehändler wie Amazon BCH anbieten kann. Es würden ja nicht alle User zugleich davon Gebrauch machen.

  7. Ich habe mal eine vmtl. ziemlich doofe Frage:
    Wenn ich meine Bitcoin Cash auf einem Ledger Wallet habe – muss ich dann in irgendeiner Form tätig werden, oder lasse ich die dort einfach weiterhin liegen?

  8. Was ist, wenn ich noch durch die Bitcoin Fork zur Einführung von Bitcoin Cash meine ersten BCC noch nicht „abgeholt“ habe ? Laufe ich Gefahr, diese zu verlieren, weil es irgendwann keinen kompatiblen client für Bitcoin Cash classic gibt ?

Schreibe eine Antwort zu WayneAntwort abbrechen

Entdecke mehr von BitcoinBlog.de - das Blog für Bitcoin und andere virtuelle Währungen

Jetzt abonnieren, um weiterzulesen und auf das gesamte Archiv zuzugreifen.

Weiterlesen