SegWit

Was ist SegWit?

SegWit steht für Segregated Witness und bedeutet „getrennte Nachweisdaten“. 2017 wurde SegWit mit BIP141 als Soft Fork aktiviert. SegWit erweitert das Transaktionsformat, indem Nachweisdaten getrennt von den übrigen Transaktionsdaten serialisiert werden.

Dadurch entstehen zwei unterschiedliche Sichtweisen auf dieselbe Transaktion:

• die Transaktionsdaten ohne Witness für die TXID
• die vollständige Transaktion inklusive Witness für die WTXID

Außerdem führt SegWit ein neues Blocklimit-Modell ein: das Blockgewicht. Blöcke werden dadurch nicht mehr nur über eine einfache maximale Byte-Größe beschrieben, sondern über Weight Units (WU). Witness-Daten zählen dabei geringer als die übrigen Transaktionsdaten. SegWit ist keine neue Art von Bitcoin und keine zweite Blockchain.

Kurz zusammengefasst:

• Witness-Daten werden von den übrigen Transaktionsdaten getrennt
• neue Serialisierung mit Marker und Flag
• Einführung von TXID und WTXID
• Einführung des Blockgewichts
• Grundlage für spätere Erweiterungen wie Taproot

Warum wurde SegWit eingeführt?

SegWit adressierte mehrere Grenzen des damaligen Transaktionsformats.

Stabile TXIDs für Zahlungskanäle und Lightning

Ein besonders wichtiger Punkt war die Vorbereitung auf Protokolle wie Zahlungskanäle und Lightning.

Solche Protokolle bauen auf Transaktionen auf, die sich gegenseitig referenzieren. Dabei müssen Folge-Transaktionen oft vorbereitet werden, bevor die vorherige Transaktion bereits bestätigt ist.

Dafür braucht man stabile TXIDs.

Vor SegWit war das schwieriger, weil bestimmte Nachweisdaten innerhalb der TXID-Berechnung lagen. Diese Eigenschaft wird als Transaction Malleability bezeichnet (die Veränderbarkeit der Transaktionsdarstellung), ohne Empfänger, Betrag oder Gültigkeit der Zahlung zu verändern.

Für einfache Zahlungen war das meist handhabbar. Ein Empfänger konnte auf Bestätigungen warten und prüfen, welche Zahlung tatsächlich in die Blockchain aufgenommen wurde.

Für Zahlungskanäle war es jedoch ein strukturelles Problem. Wenn sich die TXID einer Funding-Transaktion vor der Bestätigung änderte, verwiesen vorbereitete Folge-Transaktionen auf einen Output, der unter dieser Kennung nie entstanden war.

SegWit löst dieses Problem, indem typische Nachweisdaten in den Witness-Bereich verschoben werden.

Der Witness fließt nicht in die TXID ein. Dadurch bleibt die TXID stabil, solange sich nur Witness-Daten ändern.

Mehr Blockkapazität ohne Hard Fork

SegWit war auch ein technischer Kompromiss in der damaligen Blocksize-Debatte.

Eine direkte Erhöhung der maximalen Blockgröße hätte eine Hard Fork erfordert, weil alte Nodes größere Blöcke nach ihren bisherigen Regeln abgelehnt hätten.

SegWit konnte dagegen als Soft Fork aktiviert werden.

Statt das alte Limit einfach durch ein größeres Byte-Limit zu ersetzen, führte SegWit das Blockgewicht ein.

Dabei zählen Base-Daten stärker als Witness-Daten:

Witness-Daten sind weiterhin Teil des Blocks. Sie werden von SegWit-fähigen Nodes heruntergeladen und geprüft.

Der Unterschied liegt nicht darin, dass diese Daten verschwinden, sondern darin, wie sie im Konsenslimit gewichtet werden.

Dadurch konnte die nutzbare Blockkapazität erhöht werden, während das Wachstum der Base-Daten stärker begrenzt blieb.

Erweiterbares Transaktionsformat

SegWit führte außerdem eine erweiterte Transaktionsserialisierung mit Marker und Flag ein.

Dadurch konnten Witness-Daten getrennt von den übrigen Transaktionsdaten übertragen und validiert werden.

Außerdem führte SegWit Witness-Versionen ein. Diese Versionierung machte spätere Erweiterungen einfacher, ohne jedes Mal das gesamte Transaktionsformat neu zu entwerfen.

Ein wichtiges Beispiel dafür ist Taproot, das als SegWit-Version 1 eingeführt wurde.

Was hat SegWit technisch verändert?

SegWit definiert eine erweiterte Transaktionsserialisierung.

Transaction
├─ Version
├─ Marker
├─ Flag
├─ Inputs
├─ Outputs
├─ Witness
└─ Locktime

• Marker = 00
• Flag = 01 (bei nativem SegWit-Format)
• Legacy-Transaktionen besitzen Marker und Flag nicht
• der Witness-Bereich steht nach den Outputs

Mehr zum Gesamtaufbau: Transaktionen, Transaktionsstruktur.

Witness-Daten

Der Witness-Bereich enthält pro Input die Daten, die zur Prüfung der referenzierten Ausgabebedingungen benötigt werden.

Je nach Script-Typ können dort liegen:

• Signaturen
• Public Keys
• Redeem Scripts
• Witness Scripts
• weitere Nachweisdaten

Der Witness enthält keine neuen Konsensregeln.

Er enthält lediglich die Daten, die zur Erfüllung bestehender Ausgabebedingungen nötig sind.

Ein Node wertet Witness-Daten zusammen mit dem ScriptPubKey des referenzierten Outputs aus.

Details: Scripts, Inputs und Outputs, Validierung.

TXID und WTXID

SegWit führt zwei unterschiedliche Hashes für dieselbe Transaktion ein.

TXID

Die TXID ist der SHA256d-Hash der Transaktion ohne Marker, Flag und Witness.

Verwendet für:

• Referenzierung von Outputs
• Input-Verweise (Prev-TXID + vout)
• UTXO-Verkettung in der Blockchain

WTXID

Die WTXID ist der Hash der vollständigen SegWit-Transaktion inklusive Witness.

Sie dient unter anderem der Identifikation im Merkle-Baum von Blöcken (Merkle Root im Blockheader, Witness-Merkle-Root separat).

Bei SegWit gilt:

TXID ≠ WTXID

Bei Legacy-Transaktionen ohne Witness:

TXID = WTXID

Zum Nachrechnen: TXID-Parser auf der Transaktionsseite.

Blockgewicht und virtuelle Größe

SegWit hat die Blockgröße nicht einfach von 1 MB auf einen größeren festen Byte-Wert erhöht.

Stattdessen wurde ein neues Konsenslimit eingeführt: das Blockgewicht.

Das Blockgewicht wird in Weight Units (WU) gemessen.

• maximales Blockgewicht: 4.000.000 WU
• Base-Daten zählen mit Faktor 4
• Witness-Daten zählen mit Faktor 1

Witness-Daten sind weiterhin Teil des Blocks.

Sie werden von SegWit-fähigen Nodes heruntergeladen und geprüft.

Der Unterschied liegt nicht darin, dass diese Daten verschwinden, sondern darin, wie sie im Konsenslimit gewichtet werden.

Virtuelle Bytes

vB steht für virtual byte, also virtuelles Byte.

Ein vByte ist keine zusätzliche Datenart, sondern eine aus dem Blockgewicht abgeleitete Anzeigeeinheit.

Da Base-Daten mit Faktor 4 gewichtet werden, entspricht ein Base-Byte nach der Umrechnung wieder einem vByte:

1 Base-Byte × 4 = 4 WU
4 WU / 4 = 1 vB

Bei Witness-Daten zeigt sich der Gewichtsvorteil:

1 Witness-Byte × 1 = 1 WU
1 WU / 4 = 0,25 vB

Deshalb gilt:

vBytes = Weight Units / 4

Wallets und Blockexplorer verwenden vBytes häufig, um Gebühren als sat/vB anzuzeigen.

Warum dieses Modell?

SegWit war auch ein technischer Kompromiss in der damaligen Blocksize-Debatte.

Eine direkte Erhöhung der maximalen Blockgröße hätte eine Hard Fork erfordert, weil alte Nodes größere Blöcke nach ihren bisherigen Regeln abgelehnt hätten.

SegWit konnte dagegen als Soft Fork aktiviert werden.

Die nutzbare Blockkapazität wurde erhöht, ohne das alte Limit für die Nicht-Witness-Daten einfach durch ein größeres festes Byte-Limit zu ersetzen.

Dadurch konnten mehr Transaktionsnachweise in Blöcke aufgenommen werden, während das Wachstum der Base-Daten stärker begrenzt blieb.

Mehr zum Block als Container: Blocks. Gebühren hängen mit Gewicht zusammen: Fees.

Welche Script-Typen nutzen SegWit?

SegWit ist ein Transaktionsformat.

Die folgenden Script-Typen nutzen dieses Format häufig oder ausschließlich:

• P2WPKH (Pay to Witness Public Key Hash)
• P2WSH (Pay to Witness Script Hash)
• P2SH-P2WPKH (SegWit in P2SH-Hülle)
• P2SH-P2WSH
• P2TR (Taproot, SegWit v1)

Wichtig:

SegWit beschreibt wo Nachweisdaten liegen und wie gehasht wird.

P2WPKH oder P2TR beschreiben welche Ausgabebedingung gilt.

Beide Konzepte sollten getrennt gedacht werden.

Überblick: Scripts.

Aktivierung von SegWit

SegWit wurde über BIP141 als Soft Fork aktiviert.

• Aktivierungsblock: 481824
• Datum: 24. August 2017

In diesem Block erschien die erste breit beobachtete SegWit-Transaktion im Mainnet.

Technisch bedeutet die Aktivierung:

Nodes mit SegWit-Regeln akzeptieren das erweiterte Format und wenden Gewichts- und Witness-Validierung an.

Beispiel im Hex-Format: Transaktionsseite.