SegWit

Die Änderung war struktureller Natur, nicht kosmetisch. Die Signaturen wanderten in einen Witness-Bereich, den alte Nodes nie herunterladen. Dadurch konnte eine Kapazitätserhöhung als Soft Fork ausgeliefert werden, und Witness-Bytes kosten je eine Gewichtseinheit statt vier. Eine Ausgabe von einer bc1q-Adresse kostet daher ungefähr die Hälfte dessen, was ein Legacy-Input kostet.

Wie es funktioniert

Segregated Witness teilt eine Transaktion in zwei Teile und hasht sie getrennt.

Der Basisteil enthält die Version, die Inputs, die Outputs und die Locktime. Der Witness-Teil enthält für jeden Input den Stapel von Elementen, die ihn autorisieren, typischerweise eine Signatur und einen öffentlichen Schlüssel. Der Transaktionsbezeichner wird allein über den Basisteil berechnet, sodass nichts im Witness ihn ändern kann. Ein zweiter Bezeichner, die wtxid, umfasst beide, und die Merkle-Wurzel aller wtxids in einem Block wird innerhalb der Coinbase-Transaktion festgeschrieben, sodass auch die Witness-Daten nicht manipuliert werden können.

Die Kapazität folgt aus einer Änderung der Verrechnung, nicht aus einer Änderung des Limits. Jedes Byte außerhalb des Witness kostet vier Gewichtseinheiten, jedes Byte innerhalb kostet eine, und ein Block darf 4.000.000 Gewichtseinheiten enthalten. Daten außerhalb des Witness können daher weiterhin 1.000.000 Bytes nicht überschreiten, genau wie zuvor, während Signaturen im freien Budget mitlaufen. Ein Node vor 2017, der nach der alten Methode misst, sieht einen gültigen Block und erhebt keinen Einspruch, und genau deshalb benötigte die Aktualisierung keinen Hard Fork.

BIP-143 schrieb neu, wie ein Witness-Input signiert wird, und der praktische Gewinn ist größer, als es klingt. Der alte Signatur-Hash-Algorithmus berechnete Teile der Transaktion für jeden Input erneut, sodass das Signieren einer Transaktion mit vielen Inputs quadratisch wuchs. Der neue verwendet vorberechnete Hashes wieder und schreibt, was entscheidend ist, den ausgegebenen Betrag fest. Zuvor konnte einer Hardware-Wallet etwas Falsches über den Wert eines Inputs gesagt und sie dazu gebracht werden, eine enorme Gebühr zu autorisieren.

SegWit nummerierte außerdem seine Output-Typen. Witness-Version 0 umfasst P2WPKH und P2WSH; Witness-Version 1 blieb leer und wurde später von Taproot gefüllt. Neue Output-Typen lassen sich nun hinzufügen, ohne dass jedes Mal erneut über das Adressformat gestritten werden muss.

Warum das beim Bitcoin-Kauf wichtig ist

Drei Dinge in Ihrer eigenen Nutzung von Bitcoin gehen direkt auf diese Aktualisierung zurück.

Das erste ist, was Sie zahlen, um Bitcoin zu bewegen. Ein nativer SegWit-Input umfasst rund 68 vbytes gegenüber etwa 148 bei einem Legacy-Input, sodass eine Wallet, die drei Inputs bei einer Gebühr von 20 sat/vB ausgibt, bei einer einzelnen Transaktion mehrere Tausend Satoshi spart. Diese Ersparnis entsteht beim Ausgeben, nicht beim Empfangen, daher ist der Adresstyp entscheidend, den Ihre eigene Wallet verwendet, nicht der, von dem Ihre Börse auszahlt.

Das zweite ist, was Ihre Hardware-Wallet Ihnen sicher sagen kann. Da BIP-143 den Input-Betrag festschreibt, wird die auf einem Bildschirm von Trezor oder Ledger angezeigte Gebühr aus Daten abgeleitet, die das Gerät prüfen kann, und nicht aus Daten, die der angeschlossene Computer behauptet. Damit wurde ein echter Angriff geschlossen, und deshalb erfordert das Signieren eines Legacy-Inputs weiterhin, dass dem Gerät die gesamte vorherige Transaktion übergeben wird, damit es den Betrag selbst prüfen kann.

Das dritte ist Lightning und damit jede Börse, die darauf aufbaut. Strike überträgt Wert standardmäßig über Lightning, und Lightning-Kanäle werden in SegWit-Outputs finanziert, weil das Protokoll ohne eine stabile txid nicht funktionieren kann. Kein SegWit, keine Kanäle, kein Produkt für sofortige Abwicklung darauf.

Der Malleabilitätsfehler, der zuerst verschwinden musste

Transaktionsmalleabilität klingt nach einem Randfall und war das größte einzelne Hindernis dafür, irgendetwas auf Bitcoin aufzubauen.

Eine ECDSA-Signatur hat mehr als eine gültige Kodierung. Vor SegWit konnte ein Dritter, der den Mempool beobachtete, eine unbestätigte Transaktion nehmen, eine Signatur neu kodieren, ohne sie ungültig zu machen, und sie erneut verbreiten. Die Bitcoin gingen weiterhin an denselben Ort für denselben Betrag. Nur der Transaktionsbezeichner änderte sich, und jede Software, die den ursprünglichen Bezeichner gespeichert hatte, glaubte nun, die Zahlung sei verschwunden. Mt. Gox machte die Malleabilität öffentlich für die Aussetzung der Auszahlungen im Februar 2014 verantwortlich, eine Behauptung, die andere Entwickler damals bestritten, doch der zugrunde liegende Fehler war real.

Zahlungskanäle machten ihn nicht lästig, sondern fatal. Ein Kanal funktioniert, indem er eine signierte Rückerstattungstransaktion hält, die einen Finanzierungs-Output ausgibt, der durch seine txid identifiziert wird, noch bevor diese Finanzierungstransaktion überhaupt verbreitet wird. Ändert sich die txid, wird die Rückerstattung nicht ausgebbar, und eine Partei kann das Geld der anderen als Geisel halten. Das Lightning-Netzwerk-Papier aus dem Jahr 2015 von Joseph Poon und Thaddeus Dryja nannte in seinem eigenen Text eine Korrektur der Malleabilität als Voraussetzung.

SegWit beseitigte das Problem an der Wurzel, indem es die Signaturen aus der Preimage des Bezeichners nahm. Jeder Input, der einen Witness-Output ausgibt, hat eine txid, die kein Dritter ändern kann, und Kanalprotokolle konnten endlich wie entworfen gebaut werden.

SegWit vs. Witness-Daten

SegWit ist die Aktualisierung; Witness-Daten sind die Struktur, die sie geschaffen hat. Das eine ist ein Ereignis mit einem Datum, dem 24. August 2017, und einer Spezifikation, BIP-141. Das andere ist ein Feld, das heute in den meisten Transaktionen im Netzwerk existiert, Signaturen und Skripte trägt und seine eigene Serialisierung und sein eigenes rabattiertes Gewicht hat. Zu sagen, eine Transaktion „nutzt SegWit“, ist eine Kurzform dafür, dass sie Inputs ausgibt, deren Autorisierung in diesem Feld liegt.

SegWit vs. Taproot

Zwei Soft Forks, vier Jahre auseinander, beide zum Thema Witness. SegWit schuf die Witness-Struktur und definierte die Output-Typen der Version 0, deren Adressen mit bc1q beginnen. Taproot füllte Version 1, fügte Schnorr-Signaturen hinzu und änderte, wie Skripte innerhalb eines Witness ausgewertet werden, was Adressen ergibt, die mit bc1p beginnen. Taproot konnte nur deshalb so günstig ausgeliefert werden, weil SegWit das Versionsschema bereits gebaut hatte, und deshalb liest man beide am besten als ein Design, das in Etappen umgesetzt wurde.