Bitcoin Cash: Es gibt viel zu reden

A poor, off-color reproduction of Holy Grail King Table. Original 1420. Lizenz: gemeinfrei

Die wichtigsten Bitcoin Cash (BCH) News in einem Post: Bitcoin Unlimited implementiert Double Spend Relays und Bitcoin ABC legt die Vorschläge für die November Hardfork vor. Währenddessen wird bekannt, dass BitMain mehr Bitcoin Cash (BCH) hat als Satoshi, und dass ein Core-Entwickler durch einen vertraulichen Bugfix womöglich Bitcoin Cash vor dem Kollaps bewahrt hat. Der Preis fällt heftig, und natürlich ist fast alles kontrovers. Los geht’s!

Bitcoin Unlimited implementiert Double Spend Relays

Über Double Spends von unbestätigten Transaktionen und die Schwierigkeit, sie zu verhindern

Die Sicherheit von unbestätigten Transaktionen ist ein schwieriges Thema. Auf der einen Seite ist es so gut wie unmöglich, vollständig zu verhindern, dass Double-Spends von unbestätigten Transaktionen möglich sind. Ein Restrisiko bleibt immer, dass es dem Sender gelingt, die Münze im MemPool, die eigentlich für den Empfänger bestimmt ist, gegen eine auszutauschen, die an ihn selbst zurück geht. Und wenn es in letzter Instanz der Miner ist, der mit dem Betrüger kollaboriert.

Auf der anderen Seite sind unbestätigte Transaktionen in den meisten Fällen unbedenklich. Es ist egal, weil man sowieso erst später versendet, der Aufwand ist für den Angreifer zu groß, der Gewinn zu klein, und so weiter. Onlineshops, die Gastronomie, Accounts – das dürfte alles relativ unproblematisch sein. Anders ist es bei ATMs, ShapeShift, Börsen oder Juwelieren: Hier können Double Spends von unbestätigten Transaktionen systematisch, nachhaltig profitabel und weitgehend risikofrei ausgenutzt werden. Daher sollten solche Händler unbedingt auf eine Bestätigung warten.

All dies macht es zu einem undankbaren Geschäft, zu versuchen, unbestätigte Transaktionen sicherer zu machen, wie es sich die Bitcoin Cash Entwickler derzeit vorhaben. Die notwendige annährend absolute Sicherheit wäre mit einem Kartell von Minern möglich (wie es CoinGeek vorgeschlagen hat), oder mit Offchain-Kanälen wie Lightning. Ohne beides dürfte kaum eine Chance bestehen, unbestätigte Transaktionen an Börsen, ATMs und Juweliere zu bringen. Es gibt also nicht so viel zu gewinnen – man kann lediglich die Zone, in der unbestätigte Transaktionen ok sind, etwas anheben. Eventuell kann man die Komfortzone auf auch Glücksspielseiten und Spielekeys ausdehnen.

Double Spend Relays

Die  Entwickler des Bitcoin-Cash-Clients Bitcoin Unlimited (BU) haben nun mit BUIP085 Double Spend Relays implementiert. Das Feature wurde von BitcoinXT schon länger eingebaut. Es bedeutet, dass ein Node eine Transaktion nicht länger ablehnt, wenn ihr Input bereits von einer anderen Transaktion im MemPool verbraucht wird, also ein Double Spend Versuch vorliegt. Stattdessen wird die zweite Transaktion ganz normal akzeptiert und weitergeleitet.

Das Ganze soll, so kontraintuitiv es sich anhört, unbestätigte Transaktionen sicherer machen. Grundsätzlich ist das korrekt. Schauen wir einen einfachen Double-Spend an: Der Betrüger sendet zeitgleich zwei Transaktionen ins Netzwerk, die den Inputs auf eine je andere Weise verbrauchen. Ihr Node sieht die eine, aber der Miner presst die andere in einen Block, nachdem Sie die Ware schon ausgehändigt haben: Sie wurden bestohlen. Wenn ihr Node aber beide Transaktionen sieht, entlarvt er den Betrugsversuch und kann eine Bestätigung verlangen. Im Prinzip eliminieren die Double Spend Relays diese Double-Spend-Version.

Das Problem ist aber, dass es noch eine weitere gibt: Der “RBF”-Angriff. RBF bedeutet “Replace by Fee”: Man sendet eine Transaktion mit sehr geringen oder gar keinen Gebühren, wartet ab, bis der Händler sie akzeptiert, und sendet dann gemütlich bis zum nächsten Block denselben Input mit viel höheren Gebühren an sich selbst. Wenn ein Miner bestechlich ist, ersetzt er die erste Transaktion durch die mit den höheren Gebühren. Bitcoin (BTC) hat diese Praxis durch “RBF-Transaktion” explizit gemacht, um Usern ein Instrument zu geben, mit den Minern zu verhandeln.

Die normalen Nodes, sowohl von Bitcoin (BTC) als auch Bitcoin Cash (BCH), behandeln Transaktionen ohne RBF-Auszeichnung nach dem “First-Seen”-Prinzip: Sie nehmen und propagieren die erste Transaktion eines Inputs, und weisen andere Transaktionen mit demselben Input ab. Bitcoin Unlimited bricht nun mit diesem Prinzip, indem es alle Transaktionen weiterleitet. Das macht es einfacher, einen RBF-Double-Spend zu einem Miner zu bringen, weshalb die Double Spend Relays auch alles andere als unumstritten sind.

Auf der anderen Seite machen die Double Spend Relays ja nur transparent, was ohnehin schon passieren kann (und passiert). Mit ihnen kann man vielleicht Daten sammeln, um besser zu prognostizieren, wann eine Transaktion gefährdet ist, etwa wegen der zu geringen Gebühren oder abnormen Skripte. Dies könnte langfristig unbestätigte Transaktionen tatsächlich ein gutes Stück sicherer – annährend sicher – machen.

Allerdings sehen das nicht alle so, weshalb die Diskussion der Double Spend Relays hitzig und teilweise auch giftig, am Ende aber konstruktiv verlief.

BitcoinABC stellt Vorschlag für November-Hardfork vor – CoinGeek lehnt ab

Der Teil über die Double Spends wurde länger als erwartet. Sorry. Ich versuche, mich im folgenden kurz zu fassen: BitcoinABC ist der Client von Bitcoin Cash, der die sogenannte “UAHF” anführen soll (oder will). UAHF meint “User aktivierte Hard Fork”, was bedeutet, dass es interwallsmäßig eine Hardfork gibt, die nicht von den Minern aktiviert wird, sondern bei Erreichen einer bestimmten Blockhöhe. Der Takt ist ein halbes Jahr: eine Hardfork im Mai, eine im November.

Die Vorschläge für November

Die BitcoinABC-Entwickler um Amaury Sechet haben nun ihre Hardfork-Wünsche für November vorgebracht. Das Team erklärt, dass es die geplanten Änderungen am Protokoll rechtzeitig zur Feature-Deadline am 15. August entwickelt hat. Nun wird es es testen und mit den anderen Teams – vor allem Bitcoin Unlimited und BitcoinXT – diskutieren. Wie so oft wird es ungeschickt kommuniziert; nicht als Einladung, die Features zu besprechen, sondern so, als wären sie schon beschlossene Sache.

Es sind also die folgenden Änderungen:

1.) Die Einführung einer kanonischen Transaktionsordnung gemäß der ID bzw. Hash der Transaktion
2.) Die Regel, dass Transaktionen mindestens 100 Byte groß sein müssen
3.) Die Aktivierung von OP_CHECKDATASIG und OP_CHECKDATASIGVERIFY
4.) Push-Only als Regel für die ScriptSig

So. Und was bedeutet das? Kurz und soweit ich es verstehe:

Erstens, die kanonische Transaktionsordnung, also die Ordnung von Transaktionen in einem Block gemäß ihrer ID. Sie kam vor allem mit Graphene ins Spiel. Graphene ist ein Instrument, um die für die Distribution von Blöcken und Transaktionen notwendige Bandbreite deutlich zu senken. Es wird bereits entwickelt, ist aber noch nicht anwendungsreif, und irgendwie würde es auch mit der bisherigen Transaktionsordnung funktionieren, aber eben nicht so gut. Dagegen spricht, dass es Nachteile hat, die bisherige tologische Ordnung auszusetzen. Tom Zander meint etwa, dass es Parallelisierung verhindert. Überhaupt – wozu nochmal? Bandbreite ist echt nicht das Problem, das Bitcoin Cash mit seinen 0,1 Megabyte-Blöcken hat. Und selbst wenn – der Gewinn durch Graphene ist überschaubar. Aber darüber wird noch gestritten.

Zweitens, das Mindestlimit der Transaktionsgröße, verhindert einen Angriff auf den Merkle-Tree, und viertens, die Push-only-Regel, macht SPV-Nodes sicherer (soweit ich es verstehe). Das scheint beides unkontrovers zu sein.

Drittens, die Aktivierung zweier neuer OP_Codes, beruht auf einem Konzept von Andrew Stone von Bitcoin Unlimited. Da sich BU und ABC aber nicht einigen konnten, wie genau das Konzept umgesetzt werden soll, gibt es eben beide. Oder so. Man kann damit, wenn ich es richtig verstehe, prüfen, ob die Signatur einer beliebigen Nachricht gültig ist. Ein Entwickler sagte, man könne damit etwas in Transaktionen komprimieren, aber ich habe ehrlich gesagt nicht begriffen, wozu es gut ist. Nachdem schon die im Mai aktivierten OP_Codes noch keine einzige interessante Anwendung gefunden haben, bin hier nicht allzu enthusiastisch.

Insgesamt hätte ich mir erhofft, dass Bitcoin Cash entschlossener Richtung UTXO-Commitments geht. Aber es scheint, als wäre dies zugunsten anderer Features nach hinten gerückt.

Das Ende der UAHF?

Während 2.) und 4.) offenbar unkontroverse Verbesserungen sind, werden 1.) und 3.) heiß diskutiert. Und wie so oft in der dezentralen Entwickler-Landschaft von Bitcoin Cash kommt es dazu, dass die Entwickler-Teams verschiedene Koalitionen bilden; die einen wollen dies durchsetzen – und sei es nur aus Prinzip – und die anderen wollen etwas verhindern – und sei es auch nur aus Prinzip.

Wie schon bei den Double Spends gibt es kaum ein Thema,  das nicht dazu führt, dass die Bitcoin-Cash-Entwickler verschiedene Koalitionen bilden, bei denen die einen dafür und die anderen dagegen sind. Mal ist dieser mit jenem, mal seller mit dem da.

Man findet ABC, Unlimited, XT, Tom Zander (Flowee), Craig Wright und CoinGeek in den verschiedenensten Kombinationen, dazwischen noch Jonathan Toomin, Tomas van der Wamsen und andere. Ein Beispiel?

Beim Thema Double Spend Relays sind BU und XT auf einer Seite, während Tom Zander und ABC bzw. Amaury relativ stark dagegen sind, und sich Craig Wright und Coingeek neutral verhalten. Bei der kanonischen Transaktionsfolge dagegen sind ABC und Jonathan Toomin dafür, Tom Zander und Craig Wright heftig dagegen, und Unlimited eher neutral. Außer Peter Rizun, der twittert, dass es vermutlich mehr schadet als nützt.

Und so weiter. Diese Scharmützel um das, was in den Code kommt, sind für viele nervenaufreibend. Irgendwie zwischen Double Spends und kanonischer Ordnung wurde Amaury, der Leitentwickler von BitcoinABC, aus einem Bitcoin Cash Slack rausgeworfen. Er reagierte mit einem Post ausgerechnet auf r/Bitcoin, das ihm vermutlich noch lange nachhängen wird: “Hillarious: Creator of BCash, has been banned from the BCash Slack. And then they say r/bitcoin is censored“.

Da fast alles kontrovers und umstritten und seltsam verläuft, gerät das Konzept der halbjährlichen Hardfork ins Wanken. ViaBTCs Haipo Yang, einer der wichtigsten chinesischen Bitcoin-Cash-Befürworter, hat vor kurzem auf Twitter gar das Ende der UAHF gefordert:

Zu Deutsch: “Wir sollten die regelmäßigen Hard Forks von Bitcoin Cash stoppen. Wir brauchen eine stabile Protokoll-Spezifizierung, Wir brauchen verschiedene implementierungen. Es sollte keine Entscheidung der Entwickler sein, sondern eine Wahl der Miner.” Das ist deutlich, und die meisten in der Szene scheinen hier ganz bei Yang zu sein. BitcoinABC soll nicht die Macht haben, zu bestimmen, was mit dem Protokoll passiert, schon gar nicht nach dem Beitrag auf Reddit. Schützenhilfe bekommt Haipo hier von CoinGeek, dem Pool und Magazin von Poker-Milliardär Calvin Ayre, dessen Linie maßgeblich von Pseudo-Satoshi Craig Wright bestimmt wird.

In einem Statement auf CoinGeek erklärt Ayre, welche Hardfork-Änderungen sein Pool mittragen wird. Gut, dass er das macht, aber schlecht, dass seine Vision nicht nur von den Plänen von ABC abweicht, sondern keine einzige Gemeinsamkeit mit ihnen haben. CoinGeek möchte folgendes von der Hardfork:

1.) Die Reaktivierung von vier weiteren ursprünglich  vorhandenen, nun aber deaktivierten OP_Codes
2.) Die Aufhebung des gegenwärtigen Limits von 201 OP_Codes je Skript
3.) Die Erhöhung der Blocksize auf 128 Megabyte.

Nicht unterstützen wird CoinGeek hingegen die Implementierung von OP_DATASIGVERIFY (er meint damit drittens oben) sowie der kanonischen Ordnung der Transaktionen. Da CoinGeek mit gut 21 Prozent der Hashrate der derzeit stärkste Miner von Bitcoin Cash ist, dürfte die Position des Pools eine gewisse Bedeutung haben.

Einige sind insoweit dafür, dass eine letzte Hardfork – das Aufheben des 128 Megabyte-Limits – notwendig ist, um das Protokoll verknöchern zu lassen. Alles, was nötig ist, um mit dieser Blocksize umzugehen, von Graphene über UTXO-Commitments, kann man (theoretisch) auch ohne Hardfork machen, teilweise sogar ohne Softfork. Das wiederum führt zu seltsamen Koalitionen, in denen Peter Rizun, der vehementeste Kritiker von Craig Wright, plötzlich mit CoinGeek auf einer Seite steht.

Der Preis fällt, aber langweilig ist es nicht. Nun kommen wir zu demjenigen, der vermutlich der wichtigste im Lande Bitcoin Cash ist: Jihan Wu.

Bitmain hat mehr Bitcoin Cash als Satoshi

Die Firma von Jihan Wu, Bitmain, ist die mit Abstand größte Bitcoin-Firma. Das chinesische Unternehmen wird im September an die Börse gehen und erwartet, 12 Milliarden Dollar einzusammeln. Während einer Präsentation in diesem Zuge hat Bitmain eine Tabelle präsentiert, die zeigt, über welches Vermögen in virtuellen Währungen die Firma verfügt.

Samson Mow von Blockstream hat diese Tabelle per Twitter publik gemacht.

Hier geht’s direkt zur Tabelle. Ihr zufolge hat Bitmain seinen Bestand an Bitcoin Cash zwischen dem 31. Dezember 2017 und dem 31. März 2018 von 841.866 BCH auf 1.021.316 BCH aufgestockt. In Dollar sind das, laut der Folie, 900 Millionen, was mittlerweile, nach den Kursstürzen der letzten Wochen, auf 500 Millionen geschrumpft ist. Seinen Bestand an Bitcoin (BTC) hat Bitmain dagegen von 36.877 BTC auf 22.082 BTC abgebaut, was aber immer noch gut 147 Millionen Dollar entspricht bzw. entsprach. Weiter hat die Firma gut 900.000 Litecoin (51 Millionen Dollar), 312.000 DASH (103 Mio. Dollar) und 1000 Ether (757.000 Dollar) im Portfolio. Insgesamt besitzt Bitmain virtuelle Währungen im Wert von 1,2 Milliarden Dollar (zur Zeit der Präsentation).

Bitmain dürfte mit mit dieser Anlagestrategie in den letzten Monaten schmerzliche Verluste hinnehmen müssen. Aber man darf darauf vertrauen, dass die Firma nach dem Rekordjahr 2017 prächtig gefüllten Kassen und Assets hat. Sie wird es verkraften. Was es dagegen für Bitcoin Cash bedeutet, ist unklar. Macht es Bitcoin Cash zu Bitmain Cash? Eine Million BCH sind mehr als 5 Prozent der gegenwärtigen Geldmenge. Bitmain kann den Markt mit einem Wimpernschlag erschüttern. Wenn Bitcoin Cash fällt, reisst es Bitmain mit sich, und wenn Bitmain verkaufen muss, stürzt es Bitcoin Cash noch weiter hinab …

Cory Fields meldet Bug in ABC

Zuletzt haben wir noch den Core-Entwickler Cory Fields, der bei BitcoinABC einen Bug entdeckt hat. Er hat sich kürzlich den Code von BitcoinABC angeschaut, um zu sehen, wie andere Bitcoin-Implementierungen mit Features von Core umgeht. Dabei fiel ihm eine Änderung auf, die ihm unnötig erschien. Bei näherer Betrachtung entdeckte er einen konsenskritischen Bug im Signatur-Algorithmus. Wenn ihn jemand ausgenutzt hätte, hätte dies den Konsens zwischen BitcoinABC und dem Rest des Bitcoin-Cash-Netzwerks zerschlagen, was im besten Fall zu Chaos und Aufregung, und im schlimmsten zu einem Kollaps der Blockchain geführt hätte.

Fields hat versucht, den Bug vertraulich zu melden, und dabei festgestellt, dass es bei den Bitcoin-Cash-Entwicklern kein etabliertens Verfahren für die vertrauliche und anonyme Meldung von Bugs gibt. Nach einer kurzen Korrespondenz wurde ein solches aber eingerichtet.

About Christoph Bergmann (1395 Articles)
Das Bitcoinblog wird von Bitcoin.de gesponsort, ist inhaltlich aber unabhängig und gibt die Meinung des Redakteurs Christoph Bergmann wieder, es es seit Mitte 2013 führt. Christoph hat vor kurzem ein Buch geschrieben: Bitcoin: Die verrückte Geschichte vom Aufstieg eines neuen Geldes. Das Buch stellt Bitcoin in seiner ganzen Pracht dar. Ihr könnt es direkt auf der Webseite Bitcoin-Buch.org bestellen - natürlich auch mit Bitcoin - oder auch per Amazon. Natürlich freuen wir uns auch über Spenden in Bitcoin oder Bitcoin Cash an die folgende Adresse: 1BvayiASVCmGmg4WUJmyRHoNevWWo5snqC. Wer will, kann uns auch Hier mit Lightning spenden. Tipps für Stories sind an christoph.bergmann@mailbox.org immer erwünscht. Wer dies privat machen möchte, sollte meinen PGP-Schlüssel verwenden.

11 Comments on Bitcoin Cash: Es gibt viel zu reden

  1. Das sind doch mal gute Nachrichten. Wenn man noch ein bisschen wartet kann man vielleicht alle BCH aufkaufen für kleines Geld.

    • Anonymous // 15. August 2018 at 0:09 // Reply

      Das sagte man schon so viele Male 😉

  2. Dass die einzelnen Lager schon wieder sehr zerstritten über den künftigen Kurs sind, halte ich für kein gutes Omen. Beim aktuellen Markt über den Preisverfall zu spekulieren, der damit zusammenhängen könnte, halte ich eher an den Haaren herbeigezogen.
    “Investoren”, die bisher (auch) Alts hielten haben gemerkt, dass der ETF weiter hinausgezögert wird und zwecks Risikominimierung verkauft. Wenn Bitcoin fällt, fallen alle Alts mit (“Stablecoins” [sic!] ausgeschlossen) und wenn der Fall mehr als wenige % beträgt, flüchten alle Alt-Futures etc. in BTC. Nicht nur BCH ist gefallen, auch alle anderen mit, obwohl bei Monero der Fall nicht sooo hart ausgefallen ist und dadurch den Wiedereinstieg in die Top10 verursacht hat. Liegt wahrscheinlich daran, dass da eher Leute wegen der Überzeugung sind und nicht soooo viele “Investoren” angelockt werden/wurden.

    Ich würde behaupten, 90% des investierten Kapitals versteht nicht den Unterschied zwischen BTC, BCH, LTC, ETH, XRP oder sogar XMR. Vielleicht sind wir tatsächlich zu früh und die ganze Blase muss erstmal komplett platzen, bevor sich irgendwann in ein paar Jahren/Monaten neue Projekte etablieren können, die möglichst alles richtig machen?

    • Im Endeffekt müssen die Implementationen durch Hashrate unterstützt werden. Ich weiß nicht, welcher Miner Bitcoin Unlimited unterstützt. Da bleiben noch Bitcoin ABC durch Bitmain und ein CoinGeek Client, der dann wahrscheinlich von CoinGeek, SBI Crypto und ein paar anderen genutzt wird (Craig Wright behauptet, dass nChain ebenfalls inaktive Hashingpower habe, und dass noch andere Miner CoinGeek unterstützen werden). Es wurde “Protocol Client” für Bitcoin Cash angekündigt, ich nehme an, dass das dieser Client sein wird; die Zielsetzung scheint in die gleiche Richtung zu gehen. Also haben wir dann im Extremfall eine Situation ABC vs. CoinGeek. Ich denke aber, dass Bitmain in so einem Falle nicht ABC unterstützen würde, da es ein unnötiger Chainsplit wäre.
      Ich bin froh über die Preise. Da hat man nochmal Zeit nachzukaufen. Leider war ich nicht einer der Personen, die Bitcoin Cash bei $300 gekauft haben. Entwicklung sieht prächtig aus: Bitmain IPO, POP by HandCash, Moneybutton, CoinGeek Miner’s Choice. Alles kleine Dinge, aber zusammen schon eindrucksvoll. Und wenn CoinGeek’s Fork sich durchsetzt und die OP_CODEs reaktiviert, dann sehen wir auch, ob Craig Wright nun die ganze Zeit mit seinen Ideen und Patenten geschwindelt hat oder nicht 😉

      Und Paul: Komm jetzt mal endlich in die Monero Gruppe zurück 😀
      Du bist schon zur Legende geworden.

      • Und Paul: Komm jetzt mal endlich in die Monero Gruppe zurück 😀

        Bin noch im Urlaub, den ich eigentlich dringend brauchte aber die letzten zwei Wochen jetzt mit den Kids alleine verbringen muss, weil hier noch Ferien sind… Wenn ich mich nur auf TG einloggen würde, wären meine Kinder unterversorgt 😉
        Einschulung ist in 1,5 Wochen und ich hoffe, dann wieder in meinen alten Tagesablauf zurückzufinden…

  3. Da soll doch mal einer sagen, Bitcoin Cash sei zentralisiert. Da gibt es kein “ACK ACK ACK merged” wie bei Bitcoin Core.
    Ich unterstütze die Einstellung von CoinGeek und denke auch, dass OP_DATASIGVERIFY oder OP_CHECKDATASIG (je nach Implementation) nicht voreilig implementiert werden sollte.
    Eben wurde ein guter Artikel darüber veröffentlicht, wie wichtig ein stabiles Protokoll ist: https://medium.com/@craig_10243/the-myths-of-bitcoin-bf3664e9d767 (man vernachlässige den Namen des Autors)

  4. “Ihr zufolge hat Bitmain seinen Bestand an Bitcoin Cash zwischen dem 31. Dezember 2017 und dem 31. März 2018 von 841.866 BCH auf 1.021.316 BCH aufgestockt. In Dollar sind das, laut der Folie, 900 Milliarden, was mittlerweile, nach den Kursstürzen der letzten Wochen, auf 500 Millionen geschrumpft ist.”

    Dass da aber was von 900 Milliarden steht ist schon komisch, wo alle Coins zusammen keine 900 Mrd. an Wert haben 😀

  5. Täuschungsmanöver vorneweg und die schlechten Nachrichten, ganz komprimiert am Ende. 😀

  6. Conering des BCH-Marktes und die Developer des wichtigsten Cash Clienten haben ihren Code nicht im Griff?

    Ok, ob es gute oder schlechte Nachrichten sind ist relativ. ^^

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 )

Google+ photo

You are commenting using your Google+ 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 )

Connecting to %s