Bitcoin Core 0.12.0 ist veröffentlicht
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.
Wie komme ich von 65 GB runter auf 2 GB? Ich habe gestern die Version 12 installiert. Kleiner ist nix geworden.
folgen Sie mal dem Link zu github im Artikel, dort finden Sie Instruktionen
OK, habe ich gemacht. Hab die Blockchain auch nochmal neu runterladen lassen. Hat zwei Tage gedauert. Lag nicht an meinen VDSL oder 6 x 3.5 Ghz Prozessor. Schneller ist das Teil also nicht merklich.
Es sind jetzt genau 2.64 GB geworden. Das ist sehr schön.
Möchte man wirklich eine Fullnode auf einem Smartphone betreiben? Immerhin sind die Anforderungen an die Bandbreite ja nicht ohne und in Zeiten von Volumentarifen ist dann mal ruckzuck das LTE-Volumen aufbebraucht 😀 … im WLAN ist das natürlich kein Ding. Ich werde wahrscheinlich trotzdem eher SPV-Wallets auf dem Smartphone nutzen und diese dann mit einer von mir betrieben Fullnode verbinden. Selbst die 2 GB sind auf einem Smartphone nicht ohne und könnten für andere Dinge besser verwendet werden.
„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. “
Ist die Frage, ob man wirklich eine komplette Transaktion austauschen kann, oder nur Details wie der Gebühren Betrag. Man soll auch zwei oder mehere Transaktionen zu einer Transaktion zusammenfügen können. Eine Transaktion aber auf eine andere Adresse umleiten macht „0-confirmation“ Transaktionen noch unsicherer als sie eh schon sind.
Ja, leider kann man die Transaktion komplett ändern, soweit mir gesagt wurde, weil eine andere Version, in der man nur die Gebühren ändert, viel komplexer ist. Für 0-conf ist das in der Tat nicht die beste Nachricht … (aber wg. opt-in auch nicht die schlechteste)
wg. opt-in:
„Now that we have Opt-In Full RBF in new core(less problematic version) Peter Todd is promoting Full RBF.“
Peter Todd@twitter.com:
https://twitter.com/petertoddbtc/status/702165246488797185
Hmm..ich glaube die Implementierung von Auto-Tor bezieht sich auf die ZUSAETZLICHE, nicht die ausschliessliche Nutzung von Tor, falls vorhanden.
–
Fahre 0.12.0 jetzt seit 20 stunden, laeft gut und oftmals schneller(64bit hier) aber der mempool ist fast staendig voll….damit das netzwerk von der schnelleren Blockfindung und den responsiveren(libsec) nodes vielleicht ein wenig profitiert, brauchen wir wohl erst ueber 50% 0.12.0nodes…
Die ganze Sache mit den Forks,bitcoin core und/oder bitcoin-classic ist bereits für 08/15 user (als der Du,Christoph,mich ja kennst) nicht ganz einfach zu verstehen.Mit der neuen version 0.12.0 scheint meinem Verständnis nach bereits eine Annäherung an eine hard fork (0.12.0 macht ja eine soft-fork) und damit eine Kapazitätserhohung des bitcoin core zu erfolgen.
Könntest Du freundlicherweise nochmal verständlich erklären (wie Du es ja bereits bei einer fork,dass die „alten bitcoin bestehen bleiben,gemacht hast.), was der Unterschied zwischen einem core und einem classic ist(praktisch für die user und nicht die Technik dahinter)?
Insbesondere ob und auch warum,dann der eine oder andere an Wert zu- oder abnimmt,falls sich classic durchsetzt.
Bereits jetzt ein Danke für Dich
Ich bin zwar nicht Christoph, aber vielleicht hilft es dir ja trotzdem 🙂
Core plant eine Kapazitätserhöhung des Netzwerkes durch eine leichte Änderung der Regeln, wobei diese Änderung kompatibel mit den alten Regeln bleibt (das Ganze ist aber nur durch einen „Hack“ realisierbar). Im Prinzip werden dabei die alten Teilnehmer des Netzwerkes, die nicht auf die neue Core-Version updaten, betrogen (etwas überspitzt gesagt) – sie können diese Schummelei nicht erkennen. Das ist aber durchaus positiv, da so die alten Teilnehmer nicht aus dem Netzwerk verstoßen werden. Das Prinzip wird als Softfork bezeichnet.
Classic dagegen möchte eine Kapazitätserhöhung des Netzwerkes durch neue Regeln, die mit den alten Regeln inkompatibel sind. Um diese neuen Regeln durchzusetzen, müssen demnach so gut wie alle Teilnehmer des Bitcoin-Marktes diese neuen Regeln unterstützen (indem sie auf Classic wechseln). Teilnehmer, die nach den alten Regeln weiterspielen wollen, würden quasi aus dem Netzwerk ausgestoßen. Das Prinzip wird als Hardfork bezeichnet. Ab dem Zeitpunkt hätte man theoretisch zwei Bitcoins mit unterschiedlichen Regeln. Aus technischen Gründen ist es aber eher unwahrscheinlich, dass das Netzwerk der alten Regeln überleben könnte, wenn sich Classic durchsetzt.
Bitcoins, die man besitzt, behalten ihre Gültigkeit bei den neuen und bei den alten Regeln. Wie sich der Preis für Bitcoins entwickeln wird (vorallem lang- und mittelfristig), kann aber niemand wirklich vorhersagen.
Classic plant zusätzlich zu der Einführung der neuen Regeln, auch die Änderungen von Core einzupflegen, da diese neben der Kapazitätserhöhung noch andere Vorteile haben. Classic wird die neuen Regeln aber nur einführen, wenn wirklich eine deutliche Mehrheit für diese neuen Regeln „stimmt“. Im Moment verhalten sich Classic und Core noch gleich. Übrigens hat Core diese Änderungen noch nicht im Code eingepflegt, das kommt erst mit einer späteren Version (Core macht also noch keine Softfork).
Zusammenfassend lässt sich sagen:
Core lässt im Prinzip alles beim alten und wird nur etwas Platz für neue Nutzer schaffen, bleibt aber kompatibel mit den alten Regeln. Irgendwann kann das System aber keine neuen Nutzer mehr aufnehmen.
Classic versucht das System so anzupassen, dass mittel- und langfristig mehr neue Nutzer das Bitcoin-System nutzen können, bricht dabei aber mit den alten Regeln.
Ich hoffe, das war verständlich und untechnisch genug. Eine Prognose über den Kursverlauf möchte ich nicht anstellen – und wird wahrscheinlich auch Christoph nicht anstellen.
Für den „einfachen“ Nutzer sollte sich weder bei Core noch bei Classic großartig etwas ändern, wenn er nicht direkt Core bzw. Classic einsetzt, sondern Wallets wie Electrum, Multibit, beliebige Webwallets (Coinbase, Blockchain.info) usw. nutzt. Mittelfristig wird es jedoch bei Core dazu kommen, das nicht mehr alle Transaktionen bestätigt werden können und die Transaktionsgebühren steigen werden, wenn nicht alternative Lösungen gefunden werden (die zwar theoretisch existieren, aber von der praktischen Realisierung weit entfernt – wenn nicht gar unmöglich sind).
guter Beitrag!
Danke 🙂
Danke Jan S,
mit der Frage nach der Kursentwiklung von bitcoin oder classic wohlte natürlich keine Prognosen.Sondern nur Beschreibungen wie ,“was passiert,wenn..“.“warum wird bitcoin teurer oder billiger ,falls…?
Eben die Bedingungen/Szenarien für den einen oderen anderen Kursverlauf des einen oder des aderen coins.
Könntst Du,Jan,freundlicherweise dazu etwas schreiben?
Hallo Thomas,
ich habe gestern versucht, meine Gedanken dazu zu sortieren. Im Endeffekt ist das ganze Thema aber so komplex und so abhängig von unzähligen Variablen, dass es einfach nicht objektiv wäre, einzuschätzen wie sich der Kurs vom Bitcoin entwickeln würde (insbesondere auch, weil der Markt selbst ja nicht wirklich rational reagiert).
Jedoch lässt sich festhalten, dass Bitcoin neue Nutzer aufnehmen muss, sonst wird der Kurs nicht steigen können, sondern im Gegenteil eher sinken. Dies kann „On-Chain“ geschehen, wie es Classic/XT/Unlimited vorhat und wie es Satoshi damals geplant hatte (und was ich persönlich auch unterstütze) oder „Off-Chain“ geschehen, so wie es Core plant. Diese Entscheidung „On-Chain“/“Off-Chain“ hat allerdings so große Auswirkungen auf das Bitcoin-Ökosystem, dass keine realistischen Voraussagen über die Preisentwicklung getroffen werden können.
Ich unterstütze die „On-Chain“-Skalierung, weil sie auf Dauer flexibler ist. Sie schließt „Off-Chain“-Systeme (wie z.B. das Lightning Network) nicht aus und der Markt kann freier entscheiden. Zudem denke ich, dass die Transaktionsgebühren auch die nächsten Jahre noch sehr günstig bleiben müssen, um das Wachstum des Netzwerks nicht zu behindern/verhindern – und dies ist nur möglich, wenn wir das Blockgrößenlimit anheben.
„0.12.0 macht ja eine soft-fork“
0.12.0 macht keinen soft-fork. Der kommt mit Segrated Wittnes (SegWit), welcher für April 2016 geplant ist also wahrscheinlich Bitcoin Core 0.12.1.
Die ganze Sache mit forks,core und /oder classic ist sicher für 08/15 user wie mich nicht ganz leicht zu verstehen.Meinem Verständnis nach macht die Version 0.12.0 bereits durch die softfork und anderer techn.Änderungen bereits einen Schritt zu einer Kapazitätserhöhung des Netzwerks,wie es ja classic machen will..
“ Allerdings sind Blockchain-Rescans sowie das Importieren von Wallets, Adressen und Privaten Schlüsseln nicht mehr möglich.“
Dies ist alledings keine gute Nachricht.Mal sehen,wie die Wallet-Hersteller darauf reagieren.
Könntest Du,Christoph,freundlicherweise noch einmal den praktischen (nicht technischen) Unterschied zwischen core und classic erklären?
Insbesondere ,ob und warum beim Durchsetzen des classic der „alte “ bitcoin an Wert verliert, bzw. der classic wertvoller wird ?
Dass bei einer Fork die „alten“ bitcoin bestehen bleiben ,hast Du ja mal bereits geschrieben.
Bezüglich des Satzes „Allerdings sind Blockchain-Rescans sowie das Importieren von Wallets, Adressen und Privaten Schlüsseln nicht mehr möglich.” besteht kein Grund zur Sorge. Dies ist immernoch möglich bei Core und wird wahrscheinlich auch immer möglich sein. Nur wenn man die Technik des Pruning einsetzt, trifft dieser Satz zu. Zum Pruning muss man sich aber aktiv entscheiden und ist keine Standardeinstellung.
„Meinem Verständnis nach macht die Version 0.12.0 bereits durch die softfork und anderer techn.Änderungen bereits einen Schritt zu einer Kapazitätserhöhung des Netzwerks,wie es ja classic machen will..“
Auch hier gilt: 0.12.0 macht keinen soft-fork. Der kommt mit Segrated Wittnes (SegWit), welcher für April 2016 geplant ist also wahrscheinlich Bitcoin Core 0.12.1.
Desweiteren:
Classic will einen hardfork möglichst bald machen, Bitcoin Core erst im Juli 2017.
Eine Kapazitätserhöhung erfolgt nicht mit Bitcoin Core 0.12.0
Sorry für den Doppelpost.Das Erscheinen des ersten posts dauerte so lange,dass ich erneut posten zu müssen glaubte.
Ich würde das schnellere Starten des Core x64 so rein gefühlt bestätigen. Geht bei mir aber seit ich eine SSD habe eh viel Schneller als ohne, weshalb der Unterschied nicht mehr so groß ist.
Noch was zu den Upload-Limits:
Ein Tageslimit macht meiner Meinung nach keinen Sinn. Wichtiger ist hier eine Begrenzung der Bandbreite auf z.B. 1 MB/s (z.B. wenn man einen 2 MB/s Upload hat).
>>>
Da ich kein 64-bit-System fahre, kann ich den vollen Geschwindigkeitsgewinn nicht nachvollziehen.
<<<
Basis der IT und insb. die Verbreiterung von Prozessorregistern nicht verstanden. Klassischer Luft-Artikel von Bergmann.
Klassischer Trollpost von Troll McTrollolol. Erleuchte uns oder such dir Trollfreunde und halt die Backen!
Danke an alle für die Erläuterungen
„Insbesondere ,ob und warum beim Durchsetzen des classic der “alte ” bitcoin an Wert verliert, bzw. der classicertvoller wird ?“
Da wurde noch nicht beabtortet
weil der alte Bitcoin nur vielleicht 5% des Transaktionsvolumens ausmacht, d.h. der alte Bitcoin nirgendwo akzeptiert und als Zahlungsmittel einsetzbar wäre.