Nach Monaten der Arbeit ist mit Core 0.12 eines der umfangreichsten Upgrades des Bitcoin-Client erschienen. Wir stellen einige der insgesamt 22 Verbesserungen vor.
Bitcoin Core ist die Referenz-Implementierung des Bitcoin-Protokolls. Mehr als 100 überwiegend freiwillige Entwickler arbeiten seit Jahren an der Open-Source-Software. Sie flicken Bugs, bauen neue Optionen ein und verbessern die Performance. Der neueste Streich der Bitcoin Core Entwickler, die Version 0.12, bringt zahlreiche spannende Änderungen mit.
Pruning: weniger Speicherplatz
Ein Node braucht derzeit rund 60 Gigabyte an Speicher. Dies ist für die meisten Systeme verkraftbar – noch. Wenn man jedoch die rohen Blöcke löscht und lediglich den Blockindex behält, kann man den Speicherbedarf auf derzeit rund 2 Gigabyte senken, womit auch für speicherschwache Systeme der Weg bereitet ist, um trotz des starken Wachstums der Blockchain auch zukünftig einen Node zu beheimaten. Das sogenannte „Pruning“ war bereits in Core 0.11 implementiert, hat bislang jedoch die Wallet-Funktionalität blockiert. Mit Core 0.12 kann man trotz Pruning auch Transaktionen senden und empfangen. Allerdings sind Blockchain-Rescans sowie das Importieren von Wallets, Adressen und Privaten Schlüsseln nicht mehr möglich. Dass ein fast vollwertiger Node nun aber wieder und für die nächsten Jahre auf ein Smartphone oder einen USB-Stick passt, ist eine wunderbare Nachricht.
Automatische Nutzung von Tor
Es muss ja nicht jeder wissen, dass Sie Bitcoins benutzen, oder? Wenn Sie einen Node betreiben, bekommt aber Ihr Internetprovider den vollen und unverschlüsselten Datenstrom der Bitcoin-Transaktionen mit. Etwas privater ist dies mit Tor. Der Internetprovider wird so zwar immer noch erkennen, dass Sie das Verschlüsselungsnetzwerk benutzen, weiß aber immerhin nicht, was Sie konkret machen. Bitcoin Core ist schon lange Tor-kompatibel, doch bisher musste man dies aufwendig einstellen. Mit 0.12 reicht es, Tor einzuschalten (einfach den Tor-Browser laden) und Core zu starten. Core wird dann automatisch einen „hidden service“ und einen .onion-Knoten bilden.
In der Praxis ist es aber wohl nicht ganz so einfach. Meine Versuche haben nicht funktioniert, zumindest konnte ich meinen Node bei bitnodes.21 weiterhin finden (was man, wenn er über Tor funkt, wohl nicht können dürfte)
Schnellere Validierung der Signaturen
Wie bereits angekündigt wird in Core 0.12 OpenSSL durch libsecp256k1 ersetzt, um die ECDSA-Signaturen zu validieren, mit denen sich Transaktionen authentifizieren. Diese von Core im Lauf der vergangenen drei Jahre selbst entwickelte library soll den Prozess der Validierung massiv beschleunigen. Auf 64-Bit-Systemen beschleunigt es die Validierung eingehender Transaktionen um das 5- bis 7-fache und halbiert die Dauer der rohen Indizierung (beim Starten eines Nodes) sowie der Validierung von Blöcken. Da ich kein 64-bit-System fahre, kann ich den vollen Geschwindigkeitsgewinn nicht nachvollziehen. Meinem Gefühl nach lädt der Client nicht spürbar schneller, läuft aber an sich etwas flüssiger.
Erste Implementierung von RBF
RBF ist die klar umstrittenste Änderung von Core 0.12. RBF bedeutet „Replace-By-Fee“ und soll es ermöglichen, dass man eine noch unbestätigte Transaktion durch eine andere Transaktion mit höherer Gebühr ersetzen kann. RBF ermöglicht also einfaches Double-Spending und steht daher in der Kritik, die Akzeptanz von unbestätigten Transaktionen zu beschädigen. Allerdings wird jeder, der es schon schon einmal erlebt hat, dass eine Transaktion wegen zu geringer Gebühren feststackt, zustimmen, dass RBF schon seinen Sinn hat. Insbesondere wenn wir auf eine Situation zusteuern, in der mehr Transaktionen anfallen als in die Blöcke passen, wird ein Werkzeug wie RBF notwendig sein, um einen Gebührenmarkt entstehen zu lassen. Um den Kritikern entgegenzukommen, hat Core RBF als „Opt-in RBF“ implementiert, was bedeutet, dass nicht jede Transaktion ersetzbar ist, sondern nur Transaktionen, die dies ausdrücklich ankündigen. In Bitcoin Core 0.12 wird RBF zwar prinzipiell unterstützt, allerdings ermöglicht der Client es noch nicht, ersetzbare Transaktionen zu schreiben.
Upload-Limits
Eine der engsten Flaschenhälse für Nodes ist das Upload-Limit. Während die meisten Internetprovider viel mehr Download als Upload zulassen, muss ein Node jede Transaktion bzw. jeden Block nur einmal empfangen, aber an mehrere peers verteilen, womit er in der Regel mehr Upload als Download benötigt. Damit der Node nicht die eigene Internetverbindung verstopft – und damit auch den Download drosselt – kann man mit Core 0.12 nun ein Upload-Limit einstellen. Die Option ist standardmäßig abgeschalten, kann aber aktiviert werden. Das Tageslimit muss mindestens 144 Megabyte betragen.
Mempool-Limits
Wenn eine Transaktion noch nicht bestätigt wurde, geht sie in den Mempool im Arbeitsspeicher ein. Da dieser entweder durch Spam-Angriffe oder schlicht durch zuviel Nachfrage nach Transaktionen sehr stark wachsen kann, kann dies dazu führen, dass ein Node ungemein viel Arbeitsspeicher braucht und, auf schwächeren Systemen, diese auch zum Absturz bringt. Mit Core 0.12 haben die Nodes daher nun die Möglichkeit, den Mempool zu limitieren. Als Standard werden 300 Megabyte festgelegt. Diese Grenze kann jeder User jedoch selbst einstellen. Wenn die entsprechende Grenze überschritten ist, werden die Transaktionen mit den geringsten Gebühren gelöscht und der Node setzt eine neue Mindestgebühr fest, um Transaktionen zu propagieren.
Sonstige Neuigkeiten
Es gibt noch zahlreiche weitere Update. Unter anderem:
- Bisher gab es in jedem Block einen Platz für Priority-Transaktionen, die man auch ohne Gebühr unterbringen konnte. Dieser Platz kann nun gekürzt werden.
- Core 0.12 unterstützt nun Nachrichten (etwa über neue Transaktionen oder Blöcke) an ZeroMQ
- Miner können nun schneller Blöcke bilden, indem sie die entsprechenden Transaktionen nicht alle auf einmal, sondern bereits bei deren Eintreffen in einen Block stecken.
- Die Berechnung der Gebühren für eine Transaktion wurde verbessert
Mehr Infos & Download
Mehr Infos über Core 0.12 findet ihr auf der Seite von bitcoinco.re (gut lesbar) und auf github (ausführlich und technisch inklusive der jeweiligen Command Lines). Die Dateien sind wie immer auf Bitcoin.org herunterzuladen.