Wenn Core eine neue Version des Standardclient veröffentlicht, ist dies in der Regel eine erfreuliche Nachricht. Nach dem „Monster-Release“ von Core 0.12 folgt mit 0.12.1 ein auf den ersten Blick kleines Update, das aber einige Softforks implementiert und insgesamt von geradezu monströser Komplexität ist. Ein Versuch, zu erklären, was die in 0.12.1 implementierten BIPS 9, 68, 112 und 113 bedeuten.
Wenn man sich die Release-Notes zu Core 0.12.1 anschaut, wird man dürre Beschreibungen der BIPs finden, die für die wenigsten Menschen verständlich sein sollten. Um ehrlich zu sein, finde ich dieses Update extrem verwirrend, da es Änderungen einpflegt, die mir nicht unwichtig scheinen, aber ziemlich intransparent dokumentiert sind. Um zu verstehen, was in Core 0.12.1 passiert, muss man den Links zu den BIPs folgen und diese studieren. Ich selbst verstehe im besten Fall nur einen kleinen Teil. Letztens Endes scheint Core 0.12.1 jedoch eine Kaskade von Softforks zu sein, die die Grundlagen schaffen, um das Lightning-Netzwerk zu implementieren.
Zunächst wird BIP9 eingeführt. Dies ist ein neuer „Entfaltungs-Mechanismus“ (deplayment mechanism), um Softforks zu aktivieren. Softforks meinen Forks, die im Gegensatz zu Hardforks abwärtskompatibel sind, d.h. Knoten, die noch die alte Version benutzen, sind nach einer Softfork weiterhin kompatibel mit dem Rest des Netzwerkes, auch wenn sie nicht mehr alle Features nutzen und alle Transaktionen verifizieren können. Um eine Softfork zu aktivieren, muss eine bestimmte Prozentzahl der Miner – in der Regel 95% – ihre Zustimmung über die Versions-Felder in den Blöcken geben. BIP9 ändert nun die Semantik im Version-Field eines Blocks und erlaubt so die parallele Abstimmung über mehrere Softforks. Ich habe mal gehört über bis zu 28 Softforks gleichzeitig, bin mir aber nicht sicher.
Core möchte nun BIP9 nutzen, um gleich drei Softforks zu aktivieren. BIP68, BIP112 und BIP113. BIP68 und BIP112 sind wohl essenziell für komplexere Skripte und Verträge, wie sie das Lightning-Netzwerk benötigt, und BIP113 gleicht ein Problem, das durch diese Verträge entsteht, aus. Wenn ich es richtig verstehe.
Beginnen wir mit BIP68. Über dieses schreibt Core in den Release Notes, es führe „relative lock-time consensus-enforced semantics“ des Sequenze-Nummer-Feldes ein. Wenn das, was Ihnen datz einfällt, vor allem ein „Hääää?“ ist, kann ich Sie beruhigen: Mir und vermutlich 99% der Bitcoin-Community geht es genauso. Also: Mit BIP68 soll man sogenannte nLockTime Transaktionen schreiben dürfen, die erst von Minern in Blöcke gebracht werden können, wenn die Outputs dieser Transaktion eine bestimmte Anzahl von Blöcken tief liegen. Zumindest verstehe ich es so. Dies ermöglicht es bi-direktionale Payment-Channels einzurichten, wie sie für das Lightning-Netzwerk und BIP112 notwendig sind.
Dementsprechend ergibt die BIP112 Softfork mit BIP68 Sinn. Sie aktiviert mit einer Softfork OP_CHECKSEQUENCEVERIFY. Und das bedeutet? Dieses CSV abgekürzte Update definiert einen bestehenden Code im Script-System des Bitcoins um, so dass unter bestimmten Umständen die Ausführung des Scripts eine Fehlermeldung auslöst. Auf diese Weise können Scriptpfade implementiert werden, die nur nach Ablauf einer bestimmten Zeit aktiviert werden können. Wenn BIP68 mit nLockTime Transaktionen einfriert, friert BIP112 die Skripte von Transaktionen ein. So kann das Skript beispielsweise sagen, dass ein Output erst ausgegeben werden kann, wenn eine Transaktion seit 100 Blöcken bestätigt ist. Zumindest verstehe ich es so. Auch dies hilft, das Lightning-Netzwerk zu ermöglichen.
BIP113 hingegen schwächt „perverse Anreize“ für Miner, die durch das Einfrieren von Transaktionen entstehen. Denn aufgrund recht komplizierter Gründe kann es für Miner lohnenswert sein, ihre Zeitangaben für die Blockheader in die Zukunft zu verlegen, um zeitlich eingefrorene (locktimed) Transaktionen mitzunehmen, obwohl diese erst in beispielsweise 2 Stunden gemined werden dürften. Indem BIP113 per Softfork neue Konsens-Richtlinien für die Blockheader einführt, kann dieser „perverse Anreiz“ geschwächt werden.
Diese Kaskade von Softforks scheint vor allem dazu zu dienen, die Grundlagen für das Lightning-Netzwerk zu schaffen. Daneben ist noch bemerkenswert, dass das Alert-System, also der interne Messenger von Core, ab 0.12.1 standardmäßig abgeschaltet wird. Das Alert-System dient dazu, in Krisenfällen eine Nachricht an alle Teilnehmer des Netzwerkes zu schicken. Die Schlüssel für das System haben Satoshi Nakamoto, Gavin Andresen, Theymos und eventuell Mark Karpeless. Ob das Alarm-System abgeschaltet wird, um Gavin Andresen daran zu hindern, im Falle einer Fork die User zu benachrichtigen, oder weil Mark Karpeless seine Schlüssel womöglich an die japanische Polizei übergeben hat, ist nicht bekannt.
Wie so oft, wenn es tief in die Technik geht, möchte ich diesen Beitrag mit der Bemerkung abschließen, dass ich Laie bin und nur versuche, mir aus Dingen einen Reim zu machen, die ich bestenfalls zu Bruchteilen verstehe. Für Fehler entschuldige ich mich präventiv und fordere Sie als Leser auf, sich die BIPs und Release Notes selbst zu Gemüt zu führen.