Core 0.13.1 veröffentlicht: Plan für Aktivierung von SegWit

Nach langem, langem Warten ist es soweit: Mit dem Release von Bitcoin Core 0.13.1 sind die Weichen für das Update zu Segregated Witness gelegt. Seit heute kann man die neue Version herunterladen. Aktiviert wird das neue Transaktionsformat aber frühestens Ende November.

Es dürfte in der Geschichte des Bitcoins kein Update geben, das so sehnsüchtig erwartet wurde wie Core 0.13.1. Denn diese Version hat eine kleine, aber wichtige Änderung: Sie aktiviert das bereits in 13.0 implementierte Segregated Witness.

Segregated Witness, um noch einmal kurz auszuholen, bedeutet, den Zeugen, also die Signatur, von der Transaktion zu trennen. Diese Idee wurde auf der ersten Scaling Bitcoin Konferenz vor bald einem Jahr erstmal durch Pieter Wuille publik gemacht. SegWit, so die Kurzform, ist auf den ersten Blick nur eine kleine Formalität: Die Signaturen werden nicht mehr in Transaktionen gespeichert, sondern als Extra-Paket versendet. Diese kleine Verlagerung von Daten hat eine Reihe von schlagenden Vorteilen. Die wichtigsten sind:

• SegWit beseitigt alle bekannten Formen von Transaction Malleability (was die Konstruktion verschiedener Arten von Smart Contracts, unter anderem für das Lightning Network, wesentlich vereinfacht)
• es verringert die formelle Größe von Transaktionen. Indem Teile der Transktion nicht mehr in die Berechnung der Blocksize einfließen, wird diese faktisch erhöht. Wenn alle Transaktionen im SegWit-Format geschehen, wird die tatsächliche Blocksize bei 1,7-2,0 MB liegen. SegWit bringt also die lange erwartete Erhöhung der Kapazität.
• Indem Signaturen getrennt werden, ändert sich die Berechnung von Gebühren. Damit wird ein Anreiz beseitigt, das UTXO-Set durch Transaktionen mit wenig inputs aber vielen outputs zu verschmutzen, während das Aufräumen des UTXO-Sets günstiger wird.

SegWit macht zudem künftige Softforks einfacher, wodurch die Einführung von Schnorr-Signaturen und anderen Konzepten möglich wird. Darüber hinaus skalieren die Sighash-Operationen von SegWit linear, was verhindert, dass spezielle, sehr große Transaktionen die Knoten abstürzen lassen. Schließlich vereinfach SegWit en Betrieb von Hardware-Wallets und erhöht die Sicherheit von Multisig-Transaktionen.

Ein Grund, weshalb die Core-Entwickler die Kapazität mit SegWit anstatt mit einem Anheben des Blocksize-Limits erhöhen wollen, ist, dass sich SegWit als Softfork implementieren lässt. Es kann also von Knoten, die wollen, aktiviert werden, während die Knoten, die nicht wollen, die Signaturen ignorieren können. Während eine Hardfork alle Knoten zwingt, upzudaten, müssen für eine Softfork wie SegWit lediglich alle Miner mitmachen.

Angesichts der vielen Vorteile, die SegWit bietet, ist sich Core recht sicher, dass die Miner updaten werden. Version 0.13.1 sieht einen sehr genauen Upgrade-Plan vor, der, wenn alles glatt läuft, Ende November zur Aktivierung von SegWit führt. Und zwar müssen, wie bei allen Softforks, 95 Prozent der Miner ihre Zustimmung signalisieren, damit SegWit aktiv wird. Hierfür wird ab dem 15. November eine Art Abstimmung beginnen, in der in Perioden von 2.016 Blöcke – etwa zwei Wochen – gemessen wird, wie viel Prozent der Miner für SegWit stimmen. Erreicht die Rate 95 Prozent, wird SegWit aktiviert. Erreicht sie es nicht, beginnt eine neue Periode von 2.016 Blöcken. Sollte nach einem Jahr noch immer keine Zustimmung erfolgt sein, wird SegWit niemals aktiviert werden.

Nach den Ereignissen der letzten Wochen ist mit einer Verzögerung der Aktivierung zu rechnen. Denn sowohl ViaBTC als auch der Pool von Bitcoin.com nutzen den alternativen Bitcoin-Client Bitcoin Unlimited, dessen Entwickler bisher noch keine Bereitschaft gezeigt hat, Segregated Witness zu implementieren. Da die beiden Pools zusammen rund 10-15 Prozent der Hashrate stellen, können sie, zumindest am Anfang, die Aktivierung verhindern.

Auf Dauer kann eine Änderung im Verhältnis der Hashrate oder schlicht und einfach die ganz normale Varianz von Pech und Glück beim Minen jedoch dazu führen, dass SegWit trotz des Widerstands der beiden Pools aktiviert wird. Möglich – und wahrscheinlicher – ist jedoch, dass die SegWit-Aktivierung von den Pools als Geisel benutzt wird, um Core auf die im Hongkong-Agreement versprochene Hardfork festzunageln.