Stresstest zeigt: Bitcoin Cash skaliert auf mehr als 2 Millionen Transaktionen am Tag
Am Wochenende fand der Bitcoin-Cash-Stresstest statt. Er war ein schlagender Triumph für die Big Blocker. Mit mehr als 2 Millionen Transaktionen am Tag und einem Rekordblock von 21 Megabyte und knapp 100.000 Transaktionen stellt sich Bitcoin Cash damit klar als die am höchsten skalierende dezentrale Kryptowährung auf.
Der Bitcoin-Cash-Stresstest begann schon einige Stunden vor dem 1. September und dauerte auch länger als 24 Stunden an. Zum Teil läuft er noch jetzt. Das Ziel war es, die Miner dazu zu bringen, möglichst große Blöcke zu produzieren und zu beobachten, was dann passiert.
Ein solcher Stresstest ist das Horror-Szenario der Small Blocker, die Ausgeburt jener Apokalypse, die als schwarzer Schatten hinter dem jahrelangen Blocksize-Streit gestanden hat: Man hat eine kaum limitierte Größe der Blöcke, und die Community startet mithilfe von Skripten und Spam-Transaktionen einen großen Angriff auf sich selbst. Laut allem, was man die letzten Jahre gehört hat, müsste das einem Blockchain-Suizid gleichkommen.
Es kam dem offenbar nichrt gleich. Der Stresstest war ein maßlos glorreicher Erfolg. Im Lauf von 24 Stunden wurden mehr als 2 Millionen Transaktionen bestätigt. Der größte gefundene Block hatte 21,35 Megabyte und beinhaltete fast 96.000 Transaktionen; mehr als 50 Megabyte an Blöcken in 100 Minuten war zeitweise die Regel. Bitcoin Cash hat damit den Skalierungs-Rekord für dezentrale Blockchains aufgestellt und bewiesen, dass die Währung bereit ist für einen sehr viel breiteren Einsatz als Zahlungsmittel.
Zusammenfassung der Stresstest-Stats von Blockchair.com
Allerdings gingen einige Teile des Ökosystems während des Stresstests in die Knie:
- So gut wie alle Transaktions-Visualisierungen wie Txhighway oder txstreet sind ausgefallen. Ich glaube, es liegt daran, dass die Webseiten erstens ein ungewohntes Besucheraufkommen hatten und zweitens schlecht gebaut sind: Sie benutzen einfach Javascript, um jede einzelne Transaktion durch ein Auto oder eine Person darzustellen. Das überfordert die Computer der meisten Systeme – und vermutlich auch das Backend.
TxStreet ist kaputtgegangen. Während mein Node eine Menge Transaktionen je Sekunde sieht, herrscht an der Bushaltestelle von TxStreet gähnende Leere.
- Auch einige Blockexplorer haben den Geist aufgegeben. Blockdozer, das auf Basis des Nodes BitPrim läuft, hat schon relativ früh aufgegeben und blieb relativ lange offline. Auch Blockexplorer.com war zeitweise down, lieft aber die meiste Zeit über sehr stabil und auch schnell. Blockchair.com dagegen blieb die ganze Zeit online, zeigte größere Blöcke aber teilweise mit einer minutenlangen Verzögerung. Vollständig funktional blieben schließlich die Blockexplorer von BTC.com und Coin.Dance.
Man darf vermuten, dass die Blockexplorer von zwei Seiten unter Druck gerieten: Erstens durch die vielen Daten, die sie vom Node in ihre Datenbanken überspielen mussten, zweitens durch die vielen Besucher der Webseite, die den Stresstest verfolgen wollten.
Blockchair ist zwei Blöcke hinter meinem Node, holt aber in einigen Minuten wieder auf.
- Am gravierendsten dürfte der vorübergehende Ausfall von BitPays Insight gewesen sein. Er führte nämlich dazu, dass man die CoPay/BitPay-Wallet einige Zeit lang nicht benutzen konnte.
- Die Börse CoinEx.com fiel vorübergehend aus. Es ist aber nicht klar, ob dies am Stresstest lag, oder ob noch ein zusätzlicher DoS-Angriff dazukam.
- Das Tool von Scale.Cash schaffte es teilweise nicht mehr, weitere Transaktionen in den MemoryPool zu bringen.
Mehr direkte Ausfälle sind mir nicht bekannt. Die Basisinfrastruktur von Bitcoin Cash, die Nodes und Miner, haben sich extrem widerstandsfähig gezeigt. Ich habe den Stresstest auf meinem persönlichen System beobachtet, auf dem ich einen Bitcoin-Unlimited-Node laufen lasse. Das System hat acht i7-Kerne und 32GB Arbeitsspeicher, was nicht eben High-Tech ist, aber doch auch nicht schlecht. Besser als ein Raspberry Pie, und als VPS nicht ganz günstig.
Ein 13MB-Block beschäftigt einen der Kerne meiner CPU für einige Sekunden. Der Rest meines Systems bleibt aber unbeeindruckt.
Mein Bitcoin Unlimited (BU) Node hat sich wunderbar geschlagen. Die Belastung war zu keinem Zeitpunkt wirklich zu spüren, selbst nicht beim Rekord-Block von 21 Megabyte. Ich war überrascht, wie stabil und unauffällig der Client unter diesen extremen Umständen läuft. Insgesamt brachen so gut wie keine Bitcoin Unlimited Nodes weg, die Anzahl stieg über den Tag hinweg sogar. Ein Entwickler erzählte mir, dass der schwächste seiner BU-Nodes – ein altes Laptop mit 32-bit-System und 2GB Arbeitsspeicher – eingefroren ist, nachdem ein 15-MB-Block eintraf.
Übersicht über MemPool und Blockhöhe im Debug-Fenster von Bitcoin-Unlimited. Mit am spannendsten sind die Statistiken zu den Xthin und Graphene.
Anders sah die Lage bei BitcoinABC aus. Hier sind von etwa 1450 Nodes rund 250 ausgefallen. Es gab einen Bericht, dass stark vernetzte BitcoinABC-Nodes mit mehr als 50 Peers eingefroren sind, weil sie die Netzwerk-Nachrichten nicht parallelisieren konnten, während Bitcoin Unlimited die Nachrichten schon länger besser filtert. Aber das ist nur Spekulation. Es wäre ebenso gut möglich, dass der massive – und offenbar dauerhafte – Verlust von BitcoinABC-Nodes auch politische Gründe hat: ABCs harte Position in der kommenden Hardfork behagt nicht jedem, während BU einen stärker kooperativen Ansatz gewählt hat.
Eine Schlappe für ABC, ein Triumph für BU: Anzahl von Bitcoin-Cash-Nodes auf Coin.Dance
Eindeutiger sieht die Lage bei den BitPrim-Nodes aus. Diese sind von 32 auf kurzzeitig 2 gefallen und stehen mittlerweile wieder bei 32. Das spricht sehr dafür, dass die BitPrim-Nodes Probleme mit dem hohen Transaktionsaufkommen hatten.
Auch die Miner scheinen den Stresstest gut bestanden zu haben. Sie sind relativ verantwortungsbewusst mit der Produktion von Blockspace umgegangen. Die meisten Pools haben ihre internen Limits nur nach und nach angehoben und sich langsam an größere Blöcke herangetastet. Erst wurde die 8MB-Marke geknackt, dann gab es die ersten Blöcke mit mehr als 10MB, dann mehr als 12 und schließlich mehr als 15.
Der absolute Rekord war ein Block mit 21,5 Megabyte, den BMG zu einem Zeitpunkt gefunden hat, zu dem der Stresstest eigentlich schon vorbei war. Mit 95.000 Transaktionen hat dieser Block 158 Transaktionen je Sekunde bestätigt, was ein phänomenales Ergebnis ist und das durchschnittliche Volumen von Bitcoin Cash um das etwa Tausendfache übersteigt.
Der mit Abstand größte Block, der jemals mit der Bitcoin-Software produziert wurde.
Bitmains Antpool dagegen hat ausschließlich Blöcke mit weniger als 100 Kilobyte geschürft. Ich vermute, der Pool hat die Spam-Transaktionen durch Scale.Cash ignoriert, was eine voldieselbe Taktik gefahrenlkommen legitime und auf Dauer vermutlich auch notwendige Strategie ist. BTC.com – eine Tochterfirma von Bitmain – hat lange Zeit denselben Kurs gefahren, dies aber im Lauf des Stresstests geändert und schließlich auch mehrere Blöcke von mehr als 10 Megabyte geschürft. Alle Pools haben jedoch auf besonders große Blöcke kleinere Blöcke folgen lassen, vermutlich, um dem Netzwerk die Zeit zu geben, die Blöcke und Transaktionen zu verarbeiten.
Für das Bitcoin-Cash-Ökosystem war der Stresstest ungemein interessant. Er hat gezeigt, dass die Bitcoin-Software durchaus in der Lage ist, auf ein Volumen von mehreren Millionen Transaktionen am Tag zu skalieren. Der Stresstest hat allerdings auch gezeigt, dass die Software noch weit davon entfernt ist, perfekt zu skalieren. So mangelt es etwa an der Parallelisierung der Aufgaben, bei ABC mehr als bei BU, aber grundsätzlich bei allen Implementierungen. Um mit einer dauerhaften Blocksize von 32 Megabyte klar zu kommen, bedarf es noch einer Menge Arbeit am Code.
Die vielleicht wichtigste Erkenntnis des Stresstests ist jedoch ein Wandel der Ziele: Es geht nicht länger darum, ein Limit für die Blocksize zu setzen oder zu erhöhen, sondern darum, die Technologien zu entwickeln, die größere Blöcke ermöglichen. Die Miner haben nicht einmal versucht, das Limit von 32 Megabyte auszureizen. Vielleicht haben sie Furcht, das der Block verwaist – was eine Art Selbstregulierung wäre – oder es scheiterte daran, dass das Programm, mit dem die Miner Blöcke bilden, zu lange braucht, um einen 32-MB-Block zu erzeugen. Auch hier müssen die Operationen stärker parallelisiert werden.
Trotz der Ausfälle einiger Services und des Bedarfs, die Software weiter zu optimieren, hat der Stresstest eines in aller Deutlichkeit gezeigt: ein großer Teil der Bedenken, die maßgeblich für den jahrelangen Blocksize-Streit verantwortlich waren – und dafür, dass Bitcoin bei 1MB + SegWit verharrt – waren unnötig. Aber für diese Erkenntnis ist es eigentlich bereits zu spät …
„maßlos glorreich“ ?
Gute Wortschöpfung, oder?
Was soll denn das fuer ein „Stresstest“ gewesen sein?! Nicht ein einziger Block war maximal gross mit 32MB, geschweigedenn gab es eine Folge von grossen Bloecken. Die Gesamtkapazitaet in 24h sind rund 4.6GB, mit 510MB hat man gerademal 11% davon erreicht! Ein Stresstest waere das zehnfache davon gewesen. Es gab zu keinem Zeitpunkt eine konstant hohe Transaktionsrate mit 2-500TPS, es gab keine Peaks mit 1-2000TPS. Gab es ueberhaupt speziell praepraierte Transaktionen, mit hunderten von Inputs und Outputs? Was ist mit quadratischem Hashing?
Vllt. hatten die Organisatoren ja einfach nicht mehr Mittel als $3749 zur Verfuegung? Das waere sehr laecherlich. Vllt. ist es aber auch so, dass das Netz einfach nicht mehr TX transportieren konnte und bei mehr TPS der Mempool in viele kleine Mempools fragmentieren wuerde.
Nein, das hier war kein Stresstest sondern eine Tech-Demo, mehr nicht.
1. Quadratisches Hashing ist bei Bitcoin Cash kein Thema, da der Signaturalgorithmus mit der initialen Hardfork geändert wurde.
2. Es wurden 2,2 Millionen Transaktionen erreicht. Das ist mehr, als die meisten Experten möglich gehalten hätten.
3. Stimmt, Tech-Demo wäre ein gutes Wort. Am Ende kann man als User nur mit Transaktionen stresstesten, und die Miner entscheiden, wieviel von dem Stresstest ans Netzwerk weitergeleitet wird. Die Miner waren eben recht vorsichtig …
4. Teilweise gab es offenbar wirklich Probleme mit der Aufnahme neuer Transaktionen in den MemPool und dem Abgleich des MemPools der Nodes. Aber da bin ich nicht genau im Bild. So etwas herauszufinden war ja Aufgabe des Stresstests. Zu sagen, ein Stresstest sei gescheitert, weil er Limits zeigt, ist irgendwie seltsam …
Es wurde in keinster Weise aufgezeigt, was das System kann und -viel wichtiger- was nicht, weil einfach nicht genug Last da war.
3. Ist falsch, oder? Die Fullnodes propagieren Transaktionen im Netz und diese kommen so bei den Minern in deren Mempool an. Die Miner entscheiden lediglich, welche TX in ihre Bloecke aufgenommen werden, die dann wiederum ins Netzwerk gehen. Und genau das Propagieren im Netz ist das Bottleneck bei Skalierung.
4. Ueber genau diese Probleme hoert man nichts, weil die fanatischen Claqueure sich zu hohlen Phrasen wie „masslos glorreich“ hinreissen lassen fuer ein Ergebnis, das ueberhaupt keins ist und in den Foren jede Form von Kritik damit erstickt wird.
Gab es mehr Transaktionen als sonstwo, ja, und? War es ein Stresstest, nein, nicht mal annaehernd. 2 Mio Leute koennen sich jetzt jeden Tag ein Bier kaufen, toll, fuer eine Weltwaehrung reicht das jedenfalls mal nicht und mehr ist auch nicht gezeigt worden.
Naja, wir wissen, dass das System keine Probleme damit hat, vereinzelt 20mb-Blöcke zu verarbeiten und auch über Stunden hinweg eine durchschnittliche Größe von 5-6mb verkraftet, ohne dass Nodes auf einigermaßen brauchbaren Systemen Probleme bekommen. Das ist wesentlich mehr, als man für Bitcoin (BTC) für möglich gehalten hat.
3. Das Propagieren von Transaktionen im Netzwerk ist kein Bottleneck, sondern das Propagieren von Transaktionen in Blocks. Ansonsten könnte man jede Kryptowährung „stresstesten“, indem man 10.000 Transaktionen je Sekunde propagiert. Am Ende zählt, was in die Blöcke kommt. Den MemPool kann man löschen oder limitieren.
4. Naja, man hört schon was über das Problem, aber es ist nicht gravierend. Für mich ist es eine ausgesprochen gute Nachricht, dass das Bottleneck darin liegt, dass eine Software Probleme hat, Transaktionen in den MemPool zu bekommen. So entsteht nämlich kein Schaden. Schlimmer wäre es, wenn man die Transaktionen problemlos zu den Minern kriegen würde, die sie in einen 100mb Block packen würden, und man danach feststellen würde, dass das Bottleneck in der CPU der Nodes liegt oder so …
Ich verstehe sowieso nicht, warum du so mißgünstig bist. Die Bitcoin-Software wurde in einem bisher unbekannten Ausmaß ausgereizt. Das sollte doch für jeden interessant und erfreulich sein, oder?
Ich antworte mal hier, weil ich unten den Reply-Knopf nicht sehe, weiss nicht, ob das Absicht ist.
Der Vergleich mit BTC hinkt gravierend. Wenn jemand BTC flooden will ist das sehr teuer, weil die Fees hoch sind (oder schnell hoch werden), BTC hat ja nur 1MB Bloecke. Kommen zu viele Transaktionen werden die low fee einfach weggeworfen, damit bleibt der Mempool klein und hendlebar. BCH hingegen kann man sehr billig flooden, weil die Fee fast Null ist, die Bloecke sind ja (fast) nie voll. Dann hat eine Node die Wahl, ob sie den Mempool fuellt mit einer wahrscheinlich validen TX oder sie wegwirft und den Mempool kuenstlich beschneidet. Letzteres wuerde DoS Angriffe ermoeglichen und dazu fuehren, dass die Blocksize nicht ausgereizt werden kann. Ersteres wuerde den Mempool stark wachsen lassen, was gestern wohl dazu gefuehrt, dass die Mempools der einzelnen Nodes divergiert und fragmentiert sind.
BTC hat DoS-Angriffe erfolgreich (bisher) ueberlebt, selbst als der Mempool auf das 300-fache der Blocksize angewachsen ist. Der Stresstest haette zeigen koenne, was BCH macht, wenn der BCH Mempool 10GB gross wird.
Der „Angriff“ gestern hat $3749 gekostet, etliche Dienste sind gecrasht und Mempools sind divergiert. Was passiert wohl, wenn ein potenter Angreifer mit ner Mio USD an den Start geht? Bei einer Multi Mrd Marketcap ein durchaus realistisches Angriffsszenario. Massloses Wachstum ist eine ganz, ganz furchtbare Idee.
Sorry, ich kann dir nicht ganz folgen. Bitcoin Cash hat bewiesen, dass Blöcke bis zu 20mb möglich sind. Du versuchst nun, das irgendwie ins Negative zu drehen. Ich verstehe weder wie noch warum.
Ich glaube hier reiben sich einige zu sehr an der Definition von „Stresstest/Lasttest“. Sicher, es wurde nicht 24h die volle Last erzeugt, aber das Experiment zeigt doch einducksvoll, dass BCH wesentlich massentauglicher als BTC ist, im Sinne von world wide „Cash“.
Auch die verschiedenen Abstürze waren gut, da es der zukünftigen Qualität des Ökosystems nur zu Gute kommt.
Ich muss nochmal hier oben antworten. Warum ist unten kein Reply-Knopf mehr?
Dass der Vergleich mit BTC sinnlos ist habe ich versucht, dir zu erklaeren. Wenns nur darum geht, mehr Kapazitaet als BTC zu haben kannst du auch Litecoin ins Feld fuehren oder fast alle anderen Coins. Andererseits haben andere Coins auch sehr viele TPS geschafft.
Was mich stoert ist, dass die BCHler -und dazu gehoerst du zweifelsfrei- sich alles schoenreden. Hier wurden keine $4000 in einen Angriff investiert, das ist garnichts. Dennoch redest du von „masslos glorreich“. Und als letzte Verteidigung kommt dann ein ad hominem, ala „warum bist du so missguenstig“. Schoenrederei macht blind. Aber vllt. meussen die BCHler sich einiges schoenreden, weil die Realitaet zu schlimm ist?
Hi, dass es nach zwei Ebenen keinen replay-Knopf gibt, liegt am Kommentarsystem. Kann ich nicht ändern, aber ich sehe jeden Kommentar 🙂
Also, ich wollte nicht persönlich werden, aber hatte einfach den Eindruck von Missgunst (wie halt Bitcoin Cash von Anfang an in Missgunst badet).
Der Test war für mich insoweit „maßlos glorreich“, als dass das Netzwerk ohne nennenswerte Beeinträchtigungen der Basis-Infrastruktur einen Block mit 20 MB hatte und einen fortlaufenden Traffic von 5-10MB / Block. Das ist etwas, das ich nicht erwartet hätte. Mein eigener Node war auch mit 20mb-Blöcken nicht im Ansatz herausgefordert, was ich auch nicht erwartet hätte. „Maßlos erfolgreich“ war der Stresstest also insofern, dass Bitcoin Cash sehr viel mehr Transaktionen verarbeiten kann, als man gedacht hätte.
Dass es nicht weiter ging, also dass sich nicht 32mb-Block an 32mb-Block gereiht hat, ist für mich auch „maßlos glorreich“. Denn die Miner verhalten sich offenbar sehr viel verantwortungsbewusster als man bisher angenommen hat, und sie hüten das Netzwerk davor, an einer Überlast zu Schaden zu kommen.
Das sind für mich die zwei Dinge, die den Stresstest erfolgreich machen: Bitcoin Cash widersteht einer allgemein angekündigten und beworbenen, durch Skripte unterstützten Spam-Attacke, ohne ein Blocksize-Limit zu benötigen. Das war das, was zu beweisen war, und das wurde bewiesen.
Ich stimme dir zu – 4.000 Dollar ist nicht viel. Ich wäre auch sehr gespannt, was passiert, wenn man dafür mal 100.000 Dollar oder so in die Hand nimmt, das Volumen von in den MemPool eingehenden Transaktionen auf 1000tps erhöht, und das über ein, zwei, drei Wochen hält. Hier wäre die Frage, ob die Miner den Nodes gigaweise Spam aufdrängen, oder ob sie irgendwann anfangen, die Gebühren zu erhöhen oder Spam irgendwie zu filtern. Ich selbst würde die Gebühren ziemlich früh erhöhen, und damit im Rahmen des sehr bescheidenen Einflusses meines Nodes dafür sorgen, dass Spam-Transaktionen verzögert propagiert werden und dass die Blöcke länger brauchen, um im Netzwerk anzukommen, da ich sie nicht als graphene / xthin konstruiere, sondern als ganzen Block, was vermutlich ein paar Sekunden länger dauert. Ich gehe davon aus, dass viele andere wichtige Nodes, und vermutlich auch Miner wie BTC.top, AntPool und BTC.com, das auch so machen werden. Aber natürlich weiß ich es nicht, und es wäre eine ziemlich spannende Frage. Aber es war nicht die Frage, um die es beim Spamtest ging.
Chris, lass gut sein… Du bist nicht der erste, der es versucht. Es kostet nur Zeit und Nerven. 🙁
Meine Güte, gut dass nicht die ganze Zeit über nahezu-100% Auslastung erreicht wurde: Am Ende hätte es Nodes der Exchanges noch vom Netz gehauen und der Handel wäre beeinträchtigt gewesen.
Wenn man fuer $3749 Nodes crashen und Exchanges vom Netz hauen kann hat das System ein gewaltiges Problem.
Die genannten Ausfälle sind dadurch zu erklären, dass die Software einfach nicht optimiert war. ABC ist gecrasht, da sie einfach Core ohne große Optimierungen geforkt haben (also den ganzen unoptimierten Code von Dashjr übernommenen). Insight ist in Javascript, da wundert ein Ausfall nicht, Node.js und Multithreading ist nahezu unmöglich. Unlimited ist optimiert, wie man feststellen konnte.
Das Nano Testnetz hatte vorgestern auch einen Stresstest mit konstant 25txn/s über mehr als eine Stunde ohne Ausfälle von Knoten, max peak war schon mal 750 txn/s (ohne Gebühren und ohne maßlos Strom zu verheizen). „Skalierungs-Rekord“ ist das also nicht.
Laborbedingungen in einem Testnet sind leider nicht mit einem Mainnet mit hunderten / tausenden Nodes und Exchanges zu vergleichen, denn kein seriöser Angreifer wird sich eines Testnets annehmen, bei dem es wirtschaftlich um genau Null geht. Auch wenn ich kein BCH Fan bin, ist BTCs 1MB willkürlich gewählt und nicht zeitgemäß und zumindest das hat dieser „Stress-Test“ auch gezeigt. Das wurde hier aber auch schon ausführlich durchgekaut…
Klar, nur ist der Unterschied bei Nano recht minimal: Release Candidate node v16 mit 40-45 peers gegen v15.2 mit 650 peers. Der Test würde auf dem Mainnetz ziemlich ähnliche Resultate produzieren, wird auch bald gemacht.
Nano ist PoS. Jede weitere Erörterung ist nicht nötig..
Ripple soll ja noch besser sein, hab ich gehört.der
Strikethroughwar unbeabsichtigt.. sollte eigtl. ein /sarcasm tag sein..Nano skaliert schlecht, da du alle Votes pro Transaktion speichern musst. Das können große Datenmengen werden, sobald Nano halbwegs dezentralisiert I. Ansonsten gibt’s auch nicht sowas wie SPV, was die Währung relativ unbrauchbar macht mMn.
Man muss allerdings fairerweise zugeben, dass der Entwickler weiter daran arbeitet und nicht wie die meisten Projekte im Sande verlaufen, sobald der ICO durch ist. Leider ist ein Mensch wohl zu wenig, um so ein Projekt zu stemmen und wirklich sinnvolle Lösungen für die ziemlich komplexen Probleme zu finden…
Fähige Entwickler im Feld der Kryptographie sind allerdings rar und werden noch von ICOs angelockt, die Fantastilliarden eingesammelt haben. Es ist wohl utopisch zu glauben, Nanos Entwickler wird all die Probleme selber lösen können, auch wenn ich ihm großen Respekt zolle, das Projekt selbst so weit gebracht zu haben.
Am Ende wird sich nicht nur bei Nano wohl herausstellen, dass „feeless“ und Dezentralität & Sicherheit sich ausschließen.
Der Test hat gezeigt, dass die Blockchain eine große Last verarbeiten kann. Es ist aber sehr schade, dass man sehr weit unter der maximalen Last von 24h mal 32MB Blöcke geblieben ist. Das hätte die Blockchain genauso verkraftet und es wäre schön gewesen, das der Welt zu demonstrieren.
Wie Chris oben sehr zutreffend sagte, wurden nur durchschnittlich 11% der Kapazität ausgenutzt.
Es ist auch, finde ich, peinlich, dass Blockexplorer und Copay im Prinzip gecrasht sind. Aber OK, das ist kein Mangel an der Bezahltechnologie selber. Egal.
Warum die Miner aber die Blocksize so weit unter 32MB limitieren geht mir nicht ganz auf. Es ist doch so wichtig, der Welt zu beweisen, dass Bitcoin Cash enorme Last in der Praxis tragen kann. Was nützt uns ein 32MB Protokolllimit, wenn es in der Praxis nichts gilt? Ein schädliches Signal wurde hier gesetzt.
Anders ausgedrückt: Angenommen wir hätten 1GB Blocksize im Protokoll, dann hätten wir nicht eine einzige Transaktion mehr verarbeiten können! Wir sind nicht protokolllimitiert, sondern limitiert durch das Versagen der Miner und der Software.
In meinen Augen hätte das ganze Ökosystem sicherstellen müssen, dass 24h mal 32MB Blöcke einfach so klappen, Ich mag nicht der Spielverderber sein, aber ich teile den Enthusiasmus nicht in dem Ausmaß, welches man an vielen Orten liest.
Wenn z.B. Amazon nun überlegt, ob sie auf Bitcoin Cash Zahlungen basieren lassen wollen, was werden sie dann denken? Werden sie denken „toll, dass der Big Block Ansatz funktioniert“ oder werden sie denken „Wenn es das Netz nicht mal schafft, Transaktionen anständig zu propagieren und zu verarbeiten, wie sollen die dann jemals unsere Last verarbeiten?!“.
Und wie sollen wir die Last der ganzen Welt tragen, wenn wir nicht mal so einen billigen Ministresstest durchführen können?! Wir haben hier ernsthafte Probleme gefunden und diese ehrlich anzuerkennen ist notwendig, damit „Satoshis Vision“ wahr werden kann.
Mein BU 1.3.0.1 Node mit Raspberry Pi 3 ist erstaunlich standhaft geblieben. Ist am 1.9 zwar zwei mal gecrasht (um 17:09 und 23:11), aber wenn man bedenkt, wie schwach die Hardware ist, ist es schon eine super Leistung (die CPU-Auslastung war allerdings fast durchgehend bei über 95%, sonst sind es unter 10%).
Die Visualisierungs-Seiten hatten Probleme, da nicht alle Transaktionen über die benutzten APIs zugeliefert wurden: https://www.reddit.com/r/btc/comments/9c82to/txhighway_was_stress_tested_and_upgraded_thanks/
Bevor ich’s vergesse:
Was is’n hier passiert?:
explorer.bitcoin.com/bch/block/546301 → explorer.bitcoin.com/bch/block/546302
Was ist hier passiert?
Fast eine Stunde zwischen zwei Blöcken
Nichts sonderlich ungewöhnliches, hier auf der BTC Chain über eine Stunde:
https://www.blockchain.com/de/btc/block-height/539980
https://www.blockchain.com/de/btc/block-height/539981
Ah ok.. Danke
Schön… sie schaffen es…
Blöd nur das fast niemand BCH benutzt.
Auch BTC, ETH, LTC u.s.w. nutzt fast niemand.
Neuer Stresstest, neue Rekorde! When article?
Bald 🙂 Aber der Stresstest ist derzeit nicht das interessanteste an BCH —