Bitcoin Cash wird ein Jahr alt und feiert das mit ganz viel Spam
Eine originelle Art, den Traffic auf der Blockchain darzustellen: TxStreet zeigt Transaktionen als Personen, die auf den Bus warten.
Gestern war es ein Jahr her, dass sich Bitcoin Cash von Bitcoin abgespalten hat. Die Bitcoin Cash Szene feiert dies, indem sie die eigene Blockchain mit Spam-Transaktionen angreift. Beweist sie damit, dass man Bitcoin doch onchain skalieren kann?
Ein Jahr ist es nun her, dass die Blocksize-Kriege beendet wurden. Nachdem sich die Bitcoin-Szene seit 2015 in Big Blocker und Small Blocker gespalten und diese Parteien sich mehr als zwei Jahre lang erbittert darüber gestritten haben, ob man das Blocksize-Limit anheben darf oder nicht, haben sich die Big Blocker am 1. August 2017 von Bitcoin (BTC) getrennt, indem sie Bitcoin Cash (BCH) gründeten.
Bitcoin Cash ist eine Fork von Bitcoin, was bedeutet, dass die Blockchain mit allen Transaktionen bis zum 1. August 2017 identisch ist mit der von Bitcoin (BTC). Block 478.558, gefunden am 01. August 2017 um 13:16 Uhr, war der letzte gemeinsame Block der Blockchains von Bitcoin (BTC) und Bitcoin Cash (BCH). Ab dann hat Bitcoin Cash die Konsensregeln so geändert, dass die Blöcke von Bitcoin nicht mehr akzeptiert, aber das Limit auf bis zu 8 Megabyte angehoben wird. Dank des angepassten Difficulty-Algorithmus fror Bitcoin Cash nicht ein, sondern wurde mit der Hilfe von Minern am Leben erhalten.
Als schließlich die SegWit2x-Initiative an der Hardfork zu 2MB scheiterte, wurde Bitcoin Cash endgültig zum Coin für die Big Blocker. Damit war die ehemals vereinte Bitcoin-Szene geteilt. Small Blocker benutzen Bitcoin (BTC), Big Blocker benutzen Bitcoin Cash (BCH), und beide Seiten meinen, sie benutzen den „wahren Bitcoin“. Da Bitcoin Cash im Vergleich zu Bitcoin nur etwa ein Zehntel von Preis, Hashrate und Transaktionsvolumen hat, dürfte klar sein, dass Bitcoin (BTC) weiterhin der „echte Bitcoin“ ist – während Bitcoin Cash eher eine Realisierung einer möglichen Zukunft von Bitcoin ist, in der die Größe der Blöcke wachsen darf.
Nein, Bitcoin Cash verschwindet nicht
Wer hoffte, dass „bcash“ eingeht, versandet oder verhundert, hat sich ebenso geirrt wie die, die erwartet hatten, dass der „echte Bitcoin“ den „SegWitcoin“ vom Thron stößt. Es gab kein Flippening, aber Bitcoin Cash hält sich konstant auf dem vierten Platz im Ranking der Kryptowährungen, hat am Tag zwischen 10.000 und 20.000 Transaktionen und wird fortlaufend weiterentwickelt und beworben.
Unter den Entwicklungen sind folgende Highlights zu nennen:
- Beseitigung von Quadratic Scaling: Der Signatur-Algorithmus von Bitcoin hat das Problem, dass die zur Prüfung von Signaturen benötigte Rechenleistung quadratisch mit der Anzahl der Inputs einer Transaktion skaliert. Sie müssen das nicht vollständig verstehen; es ist ein Bug, der dazu führen kann, dass spezielle Transaktionen extrem viel Rechenleistung ziehen. Bitcoin Cash hat diesen Bug noch am Tag der Hardfork ausgemerzt.
- Die Verbesserung des Difficulty-Algorithmus: Mit dem per Hardfork im November eingeführten neuen Algorithmus für die Anpassung der Mining-Schwierigkeit haben die Bitcoin-Cash-Entwickler es geschafft, stabile Block-Intervalle von 10 Minuten zu gewährleisten, unabhängig von der Hashrate. Bei Bitcoin (BTC) fluktuiert das Intervall dagegen bei einer starken Zu- oder Abnahme der Hashrate.
- Die Einführung des CashAddr-Formats: Mit dem CashAddr-Format in bech32 hat Bitcoin Cash ein Adress-Format angebommen, das es verhindert, dass man versehentlich BTC an eine BCH-Adresse sendet (und umgekehrt). Zugleich hat das CashAddr-Format einige Vorteile, die aber für die meisten User eher unerheblich sind.
- Die Reaktivierung von deaktivierten opcodes für die Skriptsprache von Bitcoin. Was genau man damit machen kann, ist bis heute nicht wirklich klar. Aber sie sind da.
Daneben gibt es sehr aktive Entwicklungen zu UTXO-Commitments und auch zu Graphene. Beides könnte ein wichtiges Hilfsmittel sein, um die Kapazität von Bitcoin Cash sehr weit zu steigern.
Weiter gibt es eifrige Entwicklungen der „nicht-monetären“ Anwendungen. Zu nennen wäre hier Memo.Cash, eine Art Twitter auf Basis von Bitcoin Cash, sowie die Diskussion darüber, welche der vielen zur Auswahl stehenden Methoden man benutzen soll, um Token auf die Blockchain zu bekommen. Diese Diskussion ist mittlerweile ziemlich hitzig, was relativ typisch für Bitcoin Cash ist.
nChain vs. Unlimited vs. ABC
Das vergangene Jahr hat in der Bitcoin-Cash-Szene eine Menge Drama und internen Ärger gesehen. Das liegt vielleicht auch daran, dass es bei Bitcoin Cash anders als bei Bitcoin nicht ein zentrales Entwickler-Team gibt. Stattdessen wird Bitcoin Cash von mehreren an sich gleichberechtigten Teams entwickelt. Zu nennen sind vor allem BitcoinABC von Amaury Sechet, der die Version geschrieben hat, die die Fork eingeleitet hat, und Bitcoin Unlimited. Daneben gibt es noch BitcoinXT, BitPrim und andere.
Der Klassiker: TxHighway zeigt für jedes MB an maximaler Blocksize eine Spur auf einer Autobahn. Gewöhnlich sind die 32 Spuren von Bitcoin Cash eher leer. Zum Geburtstag waren sie aber ziemlich voll.
Jeder in der Bitcoin-Cash-Szene weiß, dass BitcoinABC bzw. Amaury und Bitcoin Unlimited nicht eben die besten Freunde sind. Dies allein reicht schon, um immer wieder Reibungen auszulösen. Aber das ist noch gar nichts im Vergleich zum Zank um Craig Stephen Wright, dem beliebten oder gehassten Pseudo-Satoshi, und seiner patentwütigen Firma nChain. Wright hat die Angwohntheit, viel zu versprechen, und wenig zu liefern, aber dafür umso lauter in alle Richtungen zu pöbeln. Mittlerweile stellen sich Mitglieder von Bitcoin Unlimited und BitcoinABC offen gegen ihn auf, was vielleicht der einzige Punkt ist, in dem die beiden Teams einer Meinung sind.
Jihan Wu, der CEO von BitMain, und Roger Ver, der CEO von Bitcoin.com, sind weiterhin mehr oder weniger starke Befürworter von Bitcoin Cash. Allerdings ist zwischen den beiden und Craig Wrights nChain eine immer tiefere Entfremdung zu spüren. Dies ist besonders bemerkenswert, weil Wright den Poker-Milliardär Calvin Ayre überzeugt hat, den CoinGeek-Mining-Pool zu gründen, der ausschließlich Bitcoin Cash schürft und immer mehr Hashrate auf die Waage bringt.
Damit hat sich Craig Wright einen Einfluss auf die Entwicklung von Bitcoin Cash gesichert, der von vielen in der Szene immer kritischer gesehen wird. Trotz dieser und weiterer Meinungsverschiedenheiten scheint die Bitcoin Cash Szene aber einigermaßen an einem Strang zu ziehen und zu versuchen, sich einerseits von Bitcoin (BTC) zu distanzieren, aber sich andererseits auch als „der echte Bitcoin“ zu etablieren. Auffällig erfolgreich ist sie damit aber bislang noch nicht.
Stresstest oder Autoaggression?
Um nun den Geburtstag gestern zu feiern, hat die Bitcoin Cash Community dafür gesorgt, dass auf der Blockchain ordentlich etwas los war. Obwohl der Bitcoin Cash Stresstest erst am 1. September stattfinden soll, haben eine Menge Leute schon das Spam-Tool von scale.cash benutzt, um automatisch eine große Menge an Transaktionen zu bilden. Der „Dust“, der dabei entstand, geht an eine Wohltätigkeitsorganisation.
Zwischenzeitlich waren 22 Transaktionen je Sekunde zu sehen, es gab immer wieder Blöcke von beinah oder ganz 8 Megabyte, und am gesamten Tag wurden rund 700.000 Transaktionen versendet. Dabei zeigte das Netzwerk keinerlei Probleme, das Volumen zu bewältigen. Die Gebühren blieben weiterhin bei etwa einem Cent je Transaktion, der MemPool wurde sehr rasch weitgehend geleert, die Belastung auf die Nodes blieb gering (zumindest war mein Node selbst auf dem Höhepunkt des Stresstestes unauffällig. Weder Bandbreite noch CPU noch Festplattenoperationen sind bemerkenswert gestiegen).
BitcoinSubway.Cashvisualisiert das Transktionsaufkommen der beiden Bitcoins durch Personen, die an einer U-Bahn-Station warten.
Ob es Sinn ergibt, die eigene Blockchain zu spammen, sei mal dahingestellt. Die Communities von Bitcoin (BTC) und Ethereum würden im Leben nicht auf die Idee kommen, die ohnehin schon hohe Last künstlich zu erhöhen. Sie betrachten unnötige Transaktionen als Spam, vielleicht auch als DoS-Angriff, und das, was die Bitcoin-Cash-Szene derzeit treibt, als eine digitale Form von Autoaggression. Andererseits aber demonstriert der Spam, was Bitcoin Cash kann. 700.000 Transaktionen am Tag, mitunter sogar mehr als 20 Transaktionen je Sekunde, sind offenbar kein besonders großes Problem. Zumindest weiß man, dass es kein Problem darstellt, einen Tag lang ein solches Volumen zu haben.
Bitcoin Cash stellt sich damit als Mitbewerber zu VISA und PayPal auf, schreibt btc.com in einem Blogpost zur Geburtstagsfeier. Ob das tatsächliche Volumen von anscheinend 96 bis 227 Transaktionen je Sekunde tatsächlich möglich ist, wird sich vielleicht am 1. September zeigen. Denn dann wird es erst den echten Stresstest geben. Das Spam-Feuerwerk zum Geburtstag war nur ein kleiner Vorgeschmack.
Ich habe keine Zweifel daran, ob 32MB klappen wird. Im BU Giganet wurden auch schon 1GB Blöcke auf Standardhardware getestet.
Und wenn man den nChain Tests glaubt, dann wurden auch schon 380GB Blöcke erfolgreich getestet – zwar auf einer 20k Euro Maschine, aber in ein paar Jahren wird es schon viel günstiger sein.
Ich bin zwar auch seit *immer* Gegner des strikten 1MB Limits bei Bitcoin, aber bleiben wir bitte Mal auf dem Boden der Tatsachen anstatt irgendwelches PR-Geblubber weiterzuverbreiten. Ein durchschnittlicher Internetanschluss in Deutschland ist immer noch asymmetrisch und hat eine theoretische Bandbreite von 1Mbit/s im Upload. Das bedeutet, man kann maximal 75MB pro 10 Minuten verschicken, entweder an einen Peer oder eben verteilt auf mehrere Peers, mehr geht nicht. Mit einer 1Gbit/s Anbindung im Rechenzentrum schaffst Du in der Theorie 7,5GB pro Minute, mit 10Gbit/s entsprechend 75GB pro Minute. Zugang zu einer besseren Anbindung dürfte kaum jemand haben, selbst letzteres ist schon problematisch zu bekommen und sehr kostspielig, auch in einem gut ausgebauten Rechenzentrum, alleine die Hardware jenseits 10Gbit/s kostet ein Vermögen.
Im Mining von Bitcoin bedeutet jede Verzögerung in der Übertragung einen Nachteil im Vergleich zum Erzeuger des letzten Blocks. Wenn ich 1 Minute für die Synchronisierung des letzten Blocks benötige, bleiben mir nur noch im Schnitt 9 Minuten für das Mining (die Prüfung des Blocks nimmt auch noch Zeit in Anspruch, aber es wird zu komplex). Ich habe also bereits 10% Nachteil zum letzten Block Producer, bevor ich überhaupt anfangen kann, zu Minen. Langer Rede kurzer Sinn: Bei Bitcoin sehe ich bei der heutigen Netzwerktopologie kein Problem für Blöcke bis 100MB alle 10 Minuten, alles darüber sollte man wirklich gut testen, bevor es in ein Livenet übergeht.
> Ein durchschnittlicher Internetanschluss in Deutschland ist immer noch asymmetrisch und hat eine theoretische Bandbreite von 1Mbit/s im Upload. Das bedeutet, man kann maximal 75MB pro 10 Minuten verschicken, entweder an einen Peer oder eben verteilt auf mehrere Peers, mehr geht nicht.
Sicher, wie gesagt wird hier von einer 20k Euro Maschine gesprochen und nicht einem Raspberry Pi zuhause.
> Im Mining von Bitcoin bedeutet jede Verzögerung in der Übertragung einen Nachteil im Vergleich zum Erzeuger des letzten Blocks. […] Ich habe also bereits 10% Nachteil zum letzten Block Producer, bevor ich überhaupt anfangen kann, zu Minen.
Das stimmt so nicht. Die Verzögerung ist tatsächlich ein Problem für den Erzeuger des Blockes. Der gibt entsprechend auch viel Geld für einen guten Internetanschluss aus. Sonst könnte ja schon heute ein Erzeuger extra langsam einen Block übertragen und sich einen Vorteil verschaffen.
> Wenn ich 1 Minute für die Synchronisierung des letzten Blocks benötige,
Die Übertragung des Blockes dauert nicht so lange. Es wird ja nicht nochmal der ganze Block übertragen, wenn der Empfänger schon die Transaktionen im Mempool hat und dementsprechend kennt. Siehe Graphene, welches bei Bitcoin Unlimited implementiert ist: Mit Graphene werden bei der Synchronisation eines 1MB Blockes nur 2KB ausgetauscht.
Bei 380GB Blöcken würde Graphene nichtmal einen Megabyte Daten für die Synchronisation übertragen.
> bei der heutigen Netzwerktopologie kein Problem für Blöcke bis 100MB alle 10 Minuten, alles darüber sollte man wirklich gut testen, bevor es in ein Livenet übergeht.
Wurde im Bitcoin Unlimited Gigablock Testnet (1GB Blöcke) erfolgreich getestet (habe ich ausversehen im Kommentar davor Giganet genannt). https://news.bitcoin.com/bitcoin-unlimited-reveals-gigablock-testnet-performance/
Stimme dir zu Paul.
Ich denke sogar, dass 100mb zum jetzigen Zeitpunkt schwierig wären. Das wären ja 14GB Blockchain-Daten am Tag. Das wäre sicherlich nicht einfach zu handlen. Aber es gibt derzeit auch keinen Bedarf für 100mb Blöcke, und wenn man die Größe wachsen lässt, wird dieser Bedarf erst in 10 oder mehr Jahren da sein.
Bis dahin sollte man halt das Pruning noch ein bißchen verbessert / vereinfacht haben, und UTXO-Commitments … wenn dann noch die Bandbreite ein Stück besser wird und der Preis steigt, so dass die Coiner genügend Kohle haben, um es in gute Systeme zu investieren, sehe ich damit kein Problem.
380GB-Blöcke sieht man nach so einem typischen nChain-Begriff aus …
@Anonymous
Graphene ist mit Sicherheit eine tolle Technologie, Du kannst mir bestimmt auch meine Frage beantworten: https://bitcoin.stackexchange.com/questions/77660/what-is-the-difference-between-compact-blocks-thin-blocks-xthin-and-graphene-c
All diese Technologien wollen mehrfache Synchronisierungen der selben Daten obsolet machen, was auch offensichtlich sinnvoll ist. Allerdings ist damit eben nur eine Optimierung in der Größenordnung von maximal 50% und ist praktisch vernachlässigbar, wenn wir über Skalierbarkeit um Faktoren jenseits der x1000 reden, denn die Daten müssen weiterhin übertragen werden.
@Christoph
Mit solchen Voraussagen wäre ich vorsichtig, oder hättest Du vor 10 Jahren geahnt, womit Du Dich heute beschäftigen wirst? Hättest Du vor zwei Jahren geahnt, dass wir eine Marktkapitalisierung von 300 Milliarden haben und selbst einzelne Scams wie EOS mehrer Milliarden einsacken? Ein Bedarf kann von heute auf morgen entstehen und wir sollten uns durchaus darüber Gedanken machen, wie „wir“ das stemmen könnten, gerade bei Monero macht man sich dazu sehr viele Gedanken, denn wir verballern aktuell 13KB im Gegensatz zu ca. 200 Byte bei Bitcoin für eine simple Transaktion. Bulletproofs optimieren das auf ca. 2KB runter, was immer noch ein Faktor 10 gegenüber Bitcoin ist. Auch E-Mail oder Transportverschlüsselung wie SSL (aus aktuellem Anlass) hat ihren Preis, Optimierungen sollten allerdings immer eine hohe Priorität behalten. Im Vergleich hat das unendlich [sic!] skalierbare IOTA ohne jegliche Privacy Implementierung Transaktionsgrößen von 3KB (auf die Gefahr, dass ich gleich wieder angegriffen werde, aber ich habe diese auch noch nicht aufgegeben… https://www.youtube.com/watch?v=e–McNtkTm4&lc=UgxngIimB3YS3dJ783h4AaABAg.8jOml6IF1MT8jPpb6IH1q9 ).
Auch ein Monero wird nicht unendlich Onchain skalieren, auch wenn die Wege dafür mit variabler, sich anpassender Blockgröße theoretisch gelegt wären. Second Layer ist definitiv ein Thema, auch wenn es nicht soooo akut ist, da die Chain mit aktuell ca. 3000 Tx pro Tag auch heute noch eine Skalierbarkeit von x10 oder x100 verkraften würde, mit Bulletproofs ab Oktober entsprechend ca. um den Faktor 10 höher. Offchain Skalierbarkeit ohne Einbußen in der Privatsphäre ist aber definitiv ein Thema, für solche Fragen finanziert die Community seit Jahren auch zwei Wissenschaftler als Vollzeit-Researcher, die sich nur um theoretische Fragen kümmern, ohne auch nur eine Zeile Code beizutragen.
#Graphene
Ich kenne mich damit auch noch nicht aus, und meine eigentlich, xthin reicht noch ein Weilchen (daher bin ich auch nicht soo euphorisch). Graphene ist wohl noch deutlich effektiver als xthin / compact. Wieweit genau weiß ich aber nicht.
Das tolle an solchen technologien ist, dass sie 1. Spitzen durch Block-Übertragungen abbauen. Vor Compact / xthin gab es immer eine Spike im upload-traffic, wenn man einen Block an seine Peers übertragen hat. Das ist jetzt weitgehend eingeebnet. 2. trennen sie die Größe der Blöcke weitgehend vom Thema Skalierbarkeit und reduzieren es auf die Anzahl von Transaktionen.
Daher ist max. 50% nicht ganz richtig.
#Volumen
Das Transaktionsvolumen aller Kryptowährungen skaliert linear. Selbst Ethereum mit den vielen Smart Contracts, Games und Token. Ich sehe nicht, warum sich das plötzlich ändern sollte. Daher habe ich ja auch nie verstanden, warum wir uns jetzt solche Gedanken machen müssen, ob Bitcoin 20mb / 100mb / endlose mb schafft, oder ob Bitcoin Cash Gigabyte-Blöcke verkraftet.
Klar kommt es immer irgendwie anders als man meint, aber ich glaube, Geld ist zu tief in der Gesellschaft, als dass es einen Knall gibt und alle Krypto benutzen. Das geht Stück für Stück, immer weiter, aber nur schrittweise.
Die TX-Größe von 2kb ist für Monero natürlich ein Problem, vor allem, wenn man bedenkt, dass Pruning nicht geht (oder verwechsle ich da was?) und auch SPV / Light – Infrastrukturen zumindest schwieriger sind.
Die 50% sind durchaus valide aufs Netzwerk gesehen, denn man synct Transaktionen eben nur einmal statt doppelt (im Block). Spikes im Traffic bei einzelnen „guten“ Nodes sind entweder auf viele Peers zurückzuführen oder auf Selfish-Nodes, die Blöcke nicht propagieren und die Last auf den Rest des Netzwerks abladen. Für das Betreiben eines Nodes gibt es ja keinen Reward und Bandbreite kostet Geld, was sich mit größeren Blöcken weiter verschärft…
Das sehe ich anders. Siehe die Anfänge von Bitcoin als irgendwann das 1MB Limit eingeführt wurde, um dem „Spam“ von Satoshidice entgegenzuwirken. Es gab einige Spikes, die das Tx-Aufkommen plötzlich um über 100% gesteigert haben, ich würde selbst eine plötzliche Steigerung um 1.000% nicht komplett ausschließen. Dafür reicht ein gebeuteltes Land wie z.B. Venezuela, falls die Leute wirklich begreifen, dass es Alternativen zu zentralen Währungen gibt. Das kann man leider nicht prognostizieren, aber wenn es da ist, sollte man dafür gewappnet sein. Daher bin ich auch kein Fan simpler Anhebungen der Limits, sondern nachhaltige Lösungen, die sich mit dem Bedarf anpassen.
Pruning ist in einem gewissen Maß möglich, allerdings nicht vergleichbar mit Bitcoin, denn kein Node kann feststellen, ob ein Output bereits ausgegeben wurde oder nicht. Ich sehe im Speicher allerdings auch keinen Flaschenhals, denn diesen gibt es heute ab ca. 20€ pro TB und damit kann ich aktuell noch alle Blockchains der Welt speichern. Bandbreite ist das größere Problem und es gibt dabei auch physikalische Größen zu beachten. Einen 10GB Block alle 10 Minuten zu synchronisieren wäre z.B. wesentlich einfacher als 50 Millionen einzelne Transaktionen zu je 200 Byte, denn der Overhead ist praktisch identisch für jede einzelne. Hierbei bekommen irgendwann auch Ping-Zeiten zwischen Kontinenten eine Relevanz, die eben durch physikalische Gesetze wie die Lichtgeschwindigkeit irgendwann nicht weiter optimiert werden können.
Ich antworte noch ausführlicher, aber das kann ich nicht so stehen lassen:
„Das sehe ich anders. Siehe die Anfänge von Bitcoin als irgendwann das 1MB Limit eingeführt wurde, um dem „Spam“ von Satoshidice entgegenzuwirken.“
Wo hast du das denn her? In dem Satz ist ja fast alles falsch.
Warum das 1MB Limit eingeführt wurde ist in der Tat (für mich) nicht ersichtlich, vielleicht sollte ich Dein Buch doch lesen 😉
Hehe, bei solchen historischen Fehlgriffen würde ich das dringend empfehlen 🙂
Satoshi hat das 1mb Limit ohne Angabe von Gründen 2010 eingeführt. Satoshi Dice kam 2012 und hatte insgesamt etwa so viele Transaktionen wie die Silk Road (in weniger Zeit allerdings). SD hatte zwar mehr Transaktionen als jede andere Anwendung dieser Zeit, war aber noch weit davon entfernt, in Richtung 1mb Limit zu gehen.
Wenn du diesen Chart anschaust, siehst du eine mögliche „Satoshi Dice“ Spitze Mitte 2012 – auf etwa 30k Transaktionen.
https://www.blockchain.com/charts/n-transactions?timespan=all
Wobei ich aber nicht glaube, dass SD der einzige Grund dafür war. In der Zeit gab es immer mehr Börsen, die ersten Börsen für graue Anleihen in Bitcoin entstanden, das Volumen auf der Silk Road wurde immer größer, es gab Pyramidenspiele wie das von Pirate@40 und so weiter.
Ich weiß aber nicht, ob SD einmal gegen ein per Softfork gesetztes (und durch eine solche aufhebbares) Blocksize-Limit gestoßen ist. Es gab solche Limits, aber ich glaube, erst bei 0,25 mb.
Absurd, dass wir darüber seit über einem Jahr diskutieren… https://bitcoinblog.de/2017/03/07/bitcoin-erreicht-sein-limit-absurde-folgen-des-fee-markets/comment-page-1/#comment-32239
Zur Auffrischung der Tatsachen wäre eine Lektüre womöglich sinnvoll, aber ich bin kein Historiker. Im Prinzip ist das der perfekte Zeitpunkt, ein Buch über Bitcoin herauszugeben, denn wahrscheinlich wird es ohne großartige Überarbeitungen in 10 Jahren auch noch aktuell sein 😉
Huch, wir hatten das schon mal 😉
Ja, absurd, wie lange uns ein einzelnes Thema beschäftigt.
Paul, ich kann dir keine E-Mails schreiben bzw. ich kann nicht auf deine E-Mails antworten.
„I’m sorry to have to inform you that your message could not
be delivered to one or more recipients. It’s attached below.“
Das sagt mein Mailprogramm 🙁
Von verschiedenen Mail-Adressen aus:
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
—–
host gmail-smtp-in.l.google.com [64.233.184.26]
SMTP error from remote mail server after RCPT TO::
552-5.2.2 The email account that you tried to reach is over quota. Please direct
552-5.2.2 the recipient to
552 5.2.2 https://support.google.com/mail/?p=OverQuotaPerm h9-v6si3305606wrq.337 – gsmtp
Empfängst du denn überhaupt Mails?
@Paul
Graphene und die Unterschiede zu anderen Techniken werden hier gut erklärt: https://youtu.be/BPNs9EVxWrA?t=2h56m18s
Bei 380GB müssten 38GB pro Minute übertragen werden. Das sind 600MB pro Sekunde. Solche Anschlüsse findet man idR eher in Rechenzentren. Bei 380GB Blöcken hat schon jeder Mensch auf der Erde 20 Transaktionen pro Tag. Bis wir da angekommen sind, wird sich die Technologie weiter verbessert haben.
Was Graphene nachher macht ist, einfach kompakt zu übermitteln, welche Transaktions-IDs im Block sind. D.h. die eigentliche Synchronisation der Blöcke erfolgt sehr schnell und ist kein Problem.
Das 1MB Limit wurde von Hal Finney als temporäre DoS Protection vorgeschlagen. Es sollte dafür sorgen, dass Neulinge es leichter hatten, die Blockchain herunterzuladen (vor der ASIC Zeit und Kommerzialisierung der Minings).
Siehe hier: https://bitcointalk.org/index.php?topic=946236.msg10388435#msg10388435
By the way, wie zitiert man hier? Das Zeichen ‚>‘ funktioniert anscheinend nicht.
PS: Paul, komm jetzt endlich mal zurück zu Telegram 😀
Ich denke für Bitcoin Cash wird es mit den Gigablocks dann spätestens nach dem übernächsten Halving spannend. Wahrscheinlich werden die Miner einfach einen Patch anwenden, der den Reward vergrößert / verlängert. Alle anderen können mitforken oder bleiben auf der instabilen und unsicheren Chain.
Oder ist so etwas wie Proof-Of-Stake geplant?
Wir kommst du darauf, dass die Miner einen Patch anwenden, sobald die Blöcke einen Gigabyte groß werden? Wenn die Blöcke so groß sind, dann ist entsprechend auch ein großer Reward durch Fees vorhanden.
Genauso wundere ich mich über die PoS Vermutung. Gerade Bitcoin Cash geht doch den nicht-PoS Weg (Lightning ist PoS).
Wenn man die Blöcke vergrößert, dann geht doch nicht in einem Automatismus der Fee Reward hoch. Grundsätzlich ist doch eher gerade das Gegenteil zu erwarten: 1+1 ist doch immer noch 2. Oder?
Die Transaktionsgebühren ergeben sich aus Angebot und Nachfrage. Und mit höherer Blocksize wird erst einmal nur das Angebot vermehrt. Wodurch im Effekt der Preis (TX-Fees) sinkt.
Ich kann Euch nur nahelegen, sich Mal den Lösungsansatz Moneros anzusehen.
Monero hat:
1. Minimal festgesetzte Transaktionsgebühren pro KB, alles was darunter ist, wird von einem Node als Spam behandelt und verworfen / nicht weiter propagiert.
2. Keine strikte Block Größe. Ein Miner kann sie um bis zu 100% gegenüber dem Median der letzten 100 Blöcke erhöhen, mit jedem Prozent verliert er aber auch genauso viel vom Block Reward. Das heißt, nur wenn mindestens normalpreisige Transaktionen (4x minimum Fee) im Block sind, lohnt sich der Verlust des Block Rewards gegen die eingenommenen Fees.
3. Mit steigender Block Size fallen die minimalen Gebühren pro Kilobyte.
Umso mehr Forks , umso besser.
Schön wäre es auch wenn man die Anzahl der Coins auf 22 Millionen erhöht.
Zwei „tolle“ Statements, die noch besser aussehen würden, wenn sie mit irgendwelchen Argumenten gefüttert werden würden.
Forks gibt es mittlerweile mindestens 2.000, wie viele brauchen wir zum Optimum? Kann jede beliebige Menge liefern, für einen Unkostenbeitrag von 0,1 BTC.
Ich wäre für 23. Das ist die natürliche Hackerzahl, man braucht das noch nichtmal nachlesen, wurde nämlich verfilmt! https://de.wikipedia.org/wiki/23_%E2%80%93_Nichts_ist_so_wie_es_scheint
Kannst du ja gerne machen. Zeig mal, wie tausende non-mining UASF Raspberry Pis irgendwas ändern können.
nchain bcash ist meiner Meinung nach der echte Bitcoin.
In ein paar Jahren schafft der locker Terrabyte Blöcke.
Gewiss, sei mal nicht so kleinlich… Yottabyte! Mindestens. Dann aber alle 10 Sekunden oder lass es besser Millisekunden sein, wer will schon 10 Minuten oder besser gesagt 600 Sekunden auf einen neuen Block warten???
10 Minuten ist vermutlich die ideale Blockzeit, um die Orphan-Rate so gering wie möglich zu halten. Kürzer braucht man auch nicht, 0-conf funktioniert.
Stimme weitgehend zu. Ich finde auch 10 min vollkommen unproblematisch, da 0conf. Und wo 0conf nicht funktioniert, helfen auch kürzere Blockintervalle nicht viel.
Ein guter Nebeneffekt von längeren Blockintervallen ist, dass die Metadaten bzw. die Blockheader insgesamt überschaubar bleiben. Bei Ethereum gibt es etwa alle 15 Sekunden eine Stateänderung, was für Wallets ziemlich belastend ist.
0-conf kann man sogar sehr sicher machen. Das scheinbare Problem ist ja, dass ein Miner nicht gezwungen ist, first-seen-safe anzuwenden.
Wenn sich aver mehr als 50% der Miner zusammentun (im Idealfall natürlich alle) und Blöcke orphanen, die einen (offensichtlichen) Double-Spend beinhalten, dann hat man sehr sichere 0-conf Transaktionen. Die Miner kontrollieren sich also gegenseitig, dass first-seen-safe eingehalten wird.
Was ist „nChain Bitcoin Cash“?
Und ja, in Zukunft werden die Blöcke wohl größer werden, um Kapazitäten zu schaffen. Ich tippe auf den ersten Terabyte Block im Jahr 2038. Das entspricht 50 Transaktionen pro Person pro Tag.
„Satoshi hat das 1mb Limit ohne Angabe von Gründen 2010 eingeführt.“
Es gab sehr wohl gut überlegte, sicherheitstechnische Gründe dafür. Das Sie das so salopp vom Tisch wischen, wundert mich eigentlich. Die technischen Hindergeünde sollten Sie eigentlich besser wissen als ich und als man anderer hier. Aber so eine Aussge ist nicht ok.
Es mag Gründe gegeben haben, sicherlich, aber Satoshi hat uns nicht den Gefallen getan, sie zu nennen. Hier die entsprechenden Links:
https://bitcointalk.org/index.php?topic=383.0
https://bitcointalk.org/index.php?topic=1347.msg15366#msg15366
Sollten Sie einen Grund finden, mit link zu einem Zitat von Satoshi, nehme ich meine Aussage liebend gerne zurück.
https://bitcointalk.org/index.php?topic=946236.msg10388435#msg10388435
BCash lol