Inputs & Outputs

Input

Ein Input beschreibt, welcher bestehende UTXO ausgegeben werden soll, und liefert die Daten, die zur Erfüllung der zugehörigen Ausgabebedingungen erforderlich sind.

Ein Input besteht aus mehreren Feldern:

Input
├─ Previous TXID
├─ vout
├─ ScriptSig
├─ Sequence
└─ Witness (optional)

Previous TXID

Die TXID identifiziert die Transaktion, in der sich der zu spendende Output befindet.

Dieses Feld ist immer 32 Byte lang.

Der Wert wird intern im Little-Endian-Format serialisiert. Erst zusammen mit vout entsteht die eindeutige Referenz auf einen bestimmten früheren Output.

Mehr zur TXID-Darstellung: Transaktionen · Wie entsteht eine TXID?.

vout

Der Output-Index bestimmt, welcher Output innerhalb dieser Transaktion referenziert wird.

Erst die Kombination aus TXID und vout verweist eindeutig auf einen bestimmten Output der Blockchain.

vout ist ein 4 Byte Integer im Little-Endian-Format.

Beispiele:

• 00000000 = Output 0
• 01000000 = Output 1
• 02000000 = Output 2

ScriptSig

Das ScriptSig enthält zusätzliche Daten, die zur Erfüllung der Ausgabebedingungen des referenzierten Outputs benötigt werden können.

Der konkrete Inhalt des ScriptSig hängt vom verwendeten Script-Typ ab.

Es kann Signaturen, Public Keys, Redeem Scripts oder auch keine Daten enthalten.

Bei klassischen Legacy-Transaktionen befinden sich die Nachweise direkt im ScriptSig.

Das ScriptSig enthält typischerweise:

• die Signatur
• den Public Key

Bei nativen SegWit-Transaktionen enthält das ScriptSig keine Nachweisdaten.

00 steht hier für ein leeres ScriptSig.

Signatur und Public Key befinden sich stattdessen im Witness-Bereich.

Das ScriptSig enthält hier lediglich ein Redeem Script.

Die eigentlichen Nachweisdaten befinden sich weiterhin im Witness.

Das Redeem Script verweist auf das Witness Program.

Sequence

Das Sequence-Feld wird unter anderem für Relative Timelocks und Replace-by-Fee (RBF) verwendet.

Ursprünglich war es für die Aktualisierung unbestätigter Transaktionen vorgesehen.

Das Feld ist immer 4 Byte lang.

Typische Werte:

• ffffffff: Standardwert
• fdffffff: kann Opt-in RBF signalisieren

Witness (optional)

Bei SegWit- und Taproot-Transaktionen befinden sich viele Nachweisdaten nicht mehr im ScriptSig, sondern im separaten Witness-Bereich der Transaktion.

Dort liegen je nach Script-Typ beispielsweise:

• Signaturen
• Public Keys
• Witness Scripts
• weitere skriptspezifische Daten

Siehe auch: SegWit.

Für SegWit sind Signaturen und Public Keys typischerweise im Witness-Bereich gespeichert.

Bei Taproot Key Path Spends besteht der Witness oft nur aus einer kompakten 64 Byte Schnorr-Signatur.

Coinbase-Input

Auch eine Coinbase-Transaktion besitzt technisch genau einen Input.

Dieser verweist jedoch nicht auf einen früheren UTXO:

• Prev TXID ist der Null-Hash
• vout ist 0xffffffff

Statt ScriptSig oder Witness enthält der Input sogenannte Coinbase-Daten.

Previous TXID ist beim Coinbase-Input immer der Null-Hash.

vout ist immer ffffffff und markiert den Coinbase-Sonderfall.

Nach vout folgt die Varint-Länge der Coinbase-Daten und danach die eigentlichen minerdefinierten Daten.

Die Blockhöhe steht in der Praxis am Anfang dieser Coinbase-Daten (BIP34), als erstes gepushtes Script-Element.

In diesem vereinfachten Beispiel liegt die Blockhöhen-Information damit im grünen Coinbase-Data-Bereich.

Am Ende steht wie bei jedem Input das 4 Byte Sequence-Feld.

Output

Ein Output definiert einen möglichen zukünftigen UTXO.

Er legt fest:

• welcher Betrag verfügbar ist,
• und unter welchen Bedingungen dieser Betrag später ausgegeben werden darf.

Ein Output besteht vereinfacht aus:

Output
├─ Betrag
└─ ScriptPubKey

• Betrag: Anzahl der enthaltenen Satoshis.
• ScriptPubKey: Die Ausgabebedingung für eine spätere Ausgabe.

Value

Das Value-Feld enthält den Betrag in Satoshis.

Value ist immer ein 8 Byte Integer im Little-Endian-Format.

Das bedeutet: Der Betrag wird nicht als lesbare Dezimalzahl gespeichert, sondern als Bytefolge. Das niedrigstwertige Byte steht dabei zuerst.

Beispiel: 1,3 BTC

Im Output steht:

80a4bf0700000000

Als einzelne Bytes (Little Endian, von links nach rechts gelesen):

80 · a4 · bf · 07 · 00 · 00 · 00 · 00

Für die Umrechnung dreht man die Reihenfolge um und liest die Bytes wie eine normale Zahl von links nach rechts:

07 · bf · a4 · 80

Daraus ergibt sich die Dezimalzahl 130.000.000.

Bitcoin zählt Beträge intern in Satoshis. 1 BTC entspricht 100.000.000 Satoshis.

130.000.000 sats ÷ 100.000.000 = 1,3 BTC

Kurz zusammengefasst:

80a4bf0700000000 → Bytefolge umdrehen → 130.000.000 sats → 1,3 BTC

ScriptPubKey

Der ScriptPubKey serialisiert die Ausgabebedingung eines Outputs.

Je nach verwendetem Script-Typ wird die Ausgabebedingung unterschiedlich serialisiert.

Legacy P2PKH serialisiert die Bedingungen als 76a914...88ac.

P2WPKH serialisiert ein Witness Program Version 0 als 0014....

Taproot serialisiert ein Witness Program Version 1 als 5120....

Der ScriptPubKey enthält keine Coins und keine Signaturen.

Er beschreibt lediglich die Bedingungen, die ein zukünftiger Input erfüllen muss, damit Nodes den Spend als gültig akzeptieren.

Je nach verwendetem Script-Typ können diese Bedingungen beispielsweise verlangen:

• eine gültige Signatur,
• mehrere Signaturen (Multisig),
• einen bestimmten Zeitpunkt (Timelock),
• oder Taproot-spezifische Bedingungen.

Wird ein Output noch nicht ausgegeben, befindet er sich als UTXO im UTXO-Set.

Erst wenn ein zukünftiger Input auf diesen Output verweist und die erforderlichen Nachweise liefert, kann der UTXO ausgegeben werden.

Siehe auch: Transaktionen, UTXO, Scripts, Block · Zustandsübergang, Validierung.