Bitcoin Unlimited 0.12 ist erschienen
Und noch ein Client: Bitcoin Unlimited 0.12 ist eine modifizierte Version von Bitcoin Core 0.12. Ohne RBF und Blocklimit, aber mit thinblocks und derselben Versionsnummer wie Classic.
Heute morgen wurde der experimentelle Release von Unlimited 0.12 veröffentlicht. Bitcoin Unlimited ist ein alternativer Client auf Basis von Bitcoin Core, der jedoch auf ein festes Blocklimit verzichtet und es dem User überlässt, zu entscheiden, bis zu welcher Größe er Blöcke akzeptiert. Auf diese Weise soll, so die Idee hinter Unlimited, ein spontaner Konsens im Netzwerk entstehen.*
Nachdem Core in dieser Woche die Version 0.12 veröffentlicht hat, zieht Unlimited nach. Der Release ist eine modifizierte Version von Core 0.12, die neben dem Verzicht auf ein definiertes Blocklimit einige weitere Änderungen mitbringt:
- kein RBF: nicht jeder ist Freund von RBF (siehe mehr dazu im Artikel über Core 0.12). Mit Unlimited kann man die Vorteile von Core 0.12, wie etwa die bessere Performancen genießen, ohne zugleich RBF unterstützen zu müssen
- Veröffentlichung der individuellen Einstellungen: Der Unlimited Node teilt dem Netzwerk nun mit, welches Blocklimit er unterstützt
- Xtreme Thinblocks: Wie bereits beschrieben können thinblocks bei entsprechender Verbreitung im Netzwerk die Anforderungen an Bandbreite und CPU spürbar senken, indem Clients nur noch die Blockheader anfordern, um die Transaktionen dann selbst einzufügen.**
- Xpress Validation: Wenn ein Client einen neuen Block erhält, validiert er nur die Transaktionen, die neu für ihn sind. Dies sollte die CPU-Belastung im Betrieb eines Nodes reduzieren.
- Traffic-Shaping: Während Core 0.12 über die Command-Line ein Ziel für den täglichen Upload in Megabyte erlaubt, kann man bei Unlimited über die Benutzeroberfläche einstellen, wie hoch der Upload und Download je Sekunde sein soll. Ich finde den Traffic-Shaper von Unlimited angenehmer, aber das ist wohl Geschmackssache.
Es sollte beachtet werden, dass es sich um einen experimentellen Release handelt. Man kann ihn parallel zu Core oder Classic benutzen (einfach Bitcoin von einer anderen Datei aus starten), sollte aber vor allem bei neuen Transaktionen eine Sicherheitskopie der privaten Schlüssel erstellen, um präventiv Probleme zu verhindern. Im Idealfall macht man auch eine Sicherheitskopie der Blockchain, falls Fehler in Bitcoin Unlimited die Blockchain durcheinanderbringen.
Nun noch zwei Anmerkungen:
1.) Der spontane Konsens: Sollte es vorkommen, dass ein Block die von einem Unlimited-Node definierte Blockgröße überschreitet, wird Unlimited ihn dennoch aufnehmen, aber als eine zweite Chain abspeichern, die vorerst nicht gültig ist. Erst wenn der Block eine vom User einstellbare „Tiefe“ erreicht, d.h. durch eine bestimmte Anzahl weiterer Blöcke bestätigt wird, akzeptiert Unlimited diese Chain als gültig und passt das Limit automatisch an.
2.) Thinblocks: Dieses Feature zeigt erst Wirkung, wenn man mit anderen Unlimited 0.12 Nodes verbunden ist. Eine Übersicht über entsprechende IP-Adressen findet man hier. Zum Teil muss man sich noch manuell mit diesen Adressen verbinden. Genauere Angaben über die Reduktion des Traffics kann ich hier aber nicht liefern.
Tolle Sache, jedenfall viel sinnvoller als Classic.
Ich mag vor allem die Thinblocks, die sich ja komplett ohne fork einsetzen lassen, können auch Miner damit arbeiten? Dann spielt ja die Blockgrösse kaum noch ein Rolle, also wozu auf 2MB hardforken wenn man damit auch problemlos mehr schafft.
Immer vorausgesetzt natürlich es spricht technisch nichts gegen die Thinblocks. Die Core Entwickler arbeiten ja an ähnlichen Features.
Ich befürworte zwar momentan keinen Hardfork, aber da der ohnehin irgendwann kommt, sollte so etwas wie Thinblocks auf jeden Fall mit drin sein. So hat man gleich bis 32 MB alles drin und muss nicht jedes Jahr erneut forken, mit allen Risiken.
Naja, classic hat gestern eine roadmap für die Skalierung vorgelegt, die langfristig auf dem Vorschlag von bitpay beruht. Darüber schreibe ich dann noch mehr.
Ähm… soweit ich ThinBlocks verstanden habe, ändert es an der Blocksize selbst nix, sondern löst das Problem der Verteilung der Blöcke.
Die Classic-Roadmap beinhaltet u.a. ThinBlocks als Lösung.
Für Thinblocks benötigt man keinen Hardfork.
Die Angst vor Hardforks ist unverständlich. Meiner Meinung nach hätte es schon viel früher Hardforks geben müssen, denn je größer das Netzwerk wird, desto schwieriger ist es, eine Hardfork durchzuführen. Sicher wäre es auch sinnvoll, sich auf einen definierten Zeitraum für planmäßige Hardforks zu einigen (jährlich z.B.), um Bitcoin auch in Zukunft sinnvoll erweitern zu können.
Mit Thinblocks wird die Blockgroesse aber (von der Spitzenbandbreite her) egal, da die Transaktionen dann als Stream fliessen und nicht mehr als Burst in einem Block. Natürlich gibts dann den nächsten Flaschenhals, z.B. CPU Last beim Zusammenbauen und Validieren der Blöcke, aber zumindest das Hauptproblem mit der Chinesischen Firewall ist gelöst. Wenn Classic auf Thinblocks setzt und ggf. eine dynamische Blockgrösse, so ist das auf jeden Fall besser, als einfach ein 2MB Hardfork. Denn das ist definitiv zu dünn um eine gefährliche Hardfork zu rechtfertigen. Wenn Sie allerdings solide Vorschläge haben, sieht das ggf. anders aus, allerdings müssen sie auch die Entwickler haben um das umzusetzen.
Thinblocks könnten aber relativ sofort kommen, ohne Fork, wenn nichts sonst dagegen spricht.
„Mit Thinblocks wird die Blockgroesse aber (von der Spitzenbandbreite her) egal, da die Transaktionen dann als Stream fliessen und nicht mehr als Burst in einem Block.“
Das ist zwar richtig, ändert aber nichts an dem momentanen Transaktionslimit. Um das zu erhöhen, braucht man weiterhin eine Hardfork.
Ein Problem von Thinblocks ist übrigens, dass das Ganze nur funktioniert, wenn die Nodes die entsprechenden Transaktionen im Block selbst in ihrem „Mempool“ haben. Fehlen Transaktionen, so müssen diese erst wieder von anderen Nodes oder eben der gesamte Block angefordert werden. Das erhöht wiederum die Latenz der Blockausbreitung (und um die Latenz geht es ja letztendlich). Inwieweit das technisch relevant ist, darüber kann ohne entsprechende Daten nur spekuliert werden. Aber dank Bitcoin Unlimited können diese Daten relativ gefahrlos gesammelt werden (da Unlimited nur wenige Nodes im Netzwerk stellt). Ich werde meine Node auch auf Unlimited 0.12 updaten, wenn die stabile Version erscheint.