Bitcoin-Rohtransaktionen und Skripttypen

Explorer zeigen eine Bitcoin-Transaktion als übersichtliche Listen von Adressen und Beträgen an. Diese Ansicht ist jedoch eine Dekodierung von Rohbytes, und einige der angezeigten Informationen sind in der Transaktion überhaupt nicht enthalten. Durch das Lesen der Rohstruktur erkennt ein Ermittler, was auf der Blockchain aufgezeichnet ist und was ein Werkzeug abgeleitet hat, warum sich die Gebühr nicht allein aus einer Transaktion berechnen lässt und welche Felder die Wallet-Fingerabdrücke tragen, auf denen spätere Heuristiken beruhen. Anhand der Adressformate erkennen Sie, welcher Skripttyp verwendet wird. Dies grenzt die Wallet-Software und ihren Entstehungszeitraum ein und zeigt, was beim Ausgeben der Coins öffentlich wird.

Die Serialisierung, Feld für Feld

Eine Transaktion wird als Bytefolge gespeichert und weitergeleitet. Seit SegWit (BIP 141, aktiviert im August 2017) gibt es zwei Formen: die Legacy-Form und die erweiterte Form nach BIP 144, die verwendet wird, wenn mindestens ein Input Witness-Daten enthält.

Ganzzahlen sind Little-Endian: Das niederwertigste Byte steht zuerst. Eine CompactSize-Ganzzahl benötigt für Werte unter 253 ein Byte, andernfalls ein Präfixbyte (fd, fe oder ff), gefolgt von 2, 4 oder 8 Bytes. Hier ist eine SegWit-Transaktion mit einem Input und zwei Outputs in ihre Felder aufgeteilt; lange Werte sind gekürzt:

02000000                     Version 2
00 01                        SegWit-Marker und -Flag
01                           Anzahl der Inputs 1
ab09…1d7c                    vorherige txid, interne Byte-Reihenfolge (32 Bytes)
01000000                     vorheriger Output-Index 1
00                           scriptSig-Länge 0 (nativer SegWit-Input)
fdffffff                     Sequence 0xfffffffd
02                           Anzahl der Outputs 2
40420f0000000000             Wert 1.000.000 sat
16 0014 3c1e…9d02            Skript, 22 Bytes: P2WPKH
0c6a070000000000             Wert 485.900 sat
16 0014 77b4…e051            Skript, 22 Bytes: P2WPKH
02 47 3044…01 21 02a1…5f     Witness: 2 Elemente, Signatur (71 Bytes), öffentlicher Schlüssel (33 Bytes)
00000000                     Locktime 0

Lesen Sie den ersten Wert, indem Sie seine Bytes umkehren: Aus 40 42 0f 00 … wird 0x0f4240, also 1.000.000 Satoshis (0,01 BTC). Beachten Sie, was fehlt: keine Absenderadresse, kein Input-Betrag und keine Gebühr.

Inputs und Outpoints

Ein Input enthält keine Coins; er verweist auf einen früheren Output, der als Outpoint bezeichnet und als txid:vout geschrieben wird. Die 32 Bytes lange txid im Input wird in interner Byte-Reihenfolge gespeichert, umgekehrt zu der von Explorern angezeigten Reihenfolge: ab09…1d7c in den Bytes wird auf dem Bildschirm als 7c1d…09ab dargestellt. Diese Umkehrung zu vergessen, ist eine klassische Ursache für „Transaktion nicht gefunden“.

Der Betrag und das Skript des ausgegebenen Outputs befinden sich im vorherigen Output. Um zu wissen, wer wie viel bezahlt hat, müssen Sie daher jeden Outpoint nachschlagen. Das scriptSig (Legacy-Skripte) oder der Witness (SegWit-Skripte) des Inputs liefert die Daten, die die Bedingungen des vorherigen Outputs erfüllen, üblicherweise Signaturen und öffentliche Schlüssel. Ein Coinbase-Input, der neue Coins erzeugt, hat eine ausschließlich aus Nullen bestehende vorherige txid und den Index 0xffffffff.

Sequence, Version, Locktime und Wallet-Fingerabdrücke

Die Felder rund um die Inputs und Outputs wirken wie Standardangaben, enthalten aber Informationen:

• Sequence. Werte unter 0xfffffffe signalisieren Ersetzbarkeit gemäß BIP 125, wobei 0xfffffffd die übliche Wahl ist. Seit Bitcoin Core 28.0 (2024) akzeptieren Nodes standardmäßig Ersetzungen, unabhängig davon, ob die ursprüngliche Transaktion dies signalisiert hat. Daher ist der Wert heute hauptsächlich als Fingerabdruck relevant. Relative Zeitsperren (BIP 68) verwenden dasselbe Feld.
• Version. Fast immer 1 oder 2; Version 2 ist für relative Zeitsperren erforderlich, und Wallets unterscheiden sich darin, welche Version sie verwenden.
• Locktime. Unter 500.000.000 als Blockhöhe und andernfalls als Unix-Zeitstempel zu lesen; null bedeutet keine Einschränkung. Viele Wallets setzen den Wert auf die aktuelle Blockhöhe, um Miner davon abzuhalten, kürzlich erzeugte Blöcke umzuschreiben, um Gebühren zu vereinnahmen (Anti-Fee-Sniping). Eine Locktime von 880.213 in einer bei 880.214 bestätigten Transaktion sagt daher etwas über die Software aus, die sie erstellt hat.

Diese Werte bilden zusammen mit den verwendeten Skripttypen, der Reihenfolge der Outputs und der Signaturkodierung einen Wallet-Fingerabdruck. Ein einzelner Fingerabdruck beweist nichts; eine über mehrere Transaktionen hinweg konsistente Kombination ist eines der Signale, die Lektion 4.2 nutzt, um eine Zahlung von Wechselgeld zu unterscheiden.

Output-Skripte und Adressformate

Jeder Output enthält einen Wert in Satoshis und ein scriptPubKey, also die Bedingung für seine Ausgabe. Standardskripte folgen festen Vorlagen, sodass sich der Typ an den ersten Bytes ablesen lässt. Eine Adresse ist eine Kodierung eines Standardskripts, kein Feld der Transaktion: Decoder leiten sie ab, und das Format verrät den Typ.

Bei P2PKH steht 76 a9 14 … 88 ac für OP_DUP OP_HASH160 {push 20 bytes} OP_EQUALVERIFY OP_CHECKSIG. SegWit-Outputs beginnen mit einem Versions-Opcode (00 für Version 0, 51 für Version 1, Taproot), gefolgt vom Ablegen des Programms auf dem Stack. Ein OP_RETURN-Output ist nachweislich nicht ausgebbar und enthält Daten, keinen Wert. Testnets verwenden andere Präfixe (m oder n für P2PKH, 2 für P2SH, tb1 für SegWit), sodass eine verirrte Testnet-Adresse in einem Datensatz leicht zu erkennen ist. Einige alte Skripte, etwa frühe Pay-to-Public-Key-Outputs und reine Multisig-Skripte, haben überhaupt keine Standardadresse; Data Warehouses lassen die Adressspalte möglicherweise leer, und ein Filter auf address IS NOT NULL schließt sie unbemerkt aus.

Base58Check

Legacy-Adressen beginnen mit einem Versionsbyte, hängen die 20 Bytes lange Nutzlast an (einen HASH160 eines öffentlichen Schlüssels oder Skripts), fügen als Prüfsumme die ersten 4 Bytes von SHA-256(SHA-256(Version ‖ Nutzlast)) hinzu und stellen die 25 Bytes in einem Alphabet mit 58 Zeichen ohne 0, O, I und l dar. Jedes führende Nullbyte wird zu einer führenden 1, weshalb jede P2PKH-Adresse damit beginnt. Die Kodierung unterscheidet Groß- und Kleinschreibung, und die Prüfsumme weist nahezu jeden Tippfehler zurück. Das Versionsbyte ist das Klassifizierungsmerkmal: 0x00 bedeutet P2PKH, 0x05 P2SH, alles andere ein anderes Netzwerk oder eine andere Coin.

Bech32 und bech32m

Native SegWit-Adressen verwenden bech32 (BIP 173): einen menschenlesbaren Teil (bc für Mainnet, tb für Testnet), das Trennzeichen 1 und einen Datenteil in einem Alphabet mit 32 Zeichen, das 1, b, i und o ausschließt. Das erste Datenzeichen ist die Witness-Version (q = 0, p = 1), gefolgt vom Programm und einer Prüfsumme mit 6 Zeichen. Ein Programm mit 20 Bytes ergibt 42 Zeichen (P2WPKH), eines mit 32 Bytes 62 (P2WSH). Bech32 besteht vollständig aus Kleinbuchstaben (Großbuchstaben sind für QR-Codes zulässig, gemischte Groß- und Kleinschreibung muss zurückgewiesen werden), ist höchstens 90 Zeichen lang, und seine Prüfsumme erkennt jeden Fehler, der bis zu vier Zeichen betrifft.

Es hat eine Schwachstelle: Wenn eine Zeichenfolge mit p endet, kann das Einfügen oder Löschen von q-Zeichen unmittelbar davor dazu führen, dass die Prüfsumme gültig bleibt. Die strikten Programmlängen von Version 0 machen dies weitgehend harmlos, spätere Versionen erlauben jedoch andere Längen. Daher führte BIP 350 bech32m ein, das bis auf die Prüfsummenkonstante identisch ist (0x2bc830a3 statt 1). Version 0 behält bech32 bei; die Versionen 1 bis 16 einschließlich Taproot verwenden bech32m, und Decoder müssen jeweils die falsche Prüfsumme zurückweisen. Klassifizieren Sie in Pipelines niemals anhand von „beginnt mit bc1“: Lesen Sie das vierte Zeichen und die Länge. Vor 2021 geschriebene Parser können gültige bc1p-Adressen zurückweisen, und eine Pipeline, die nicht parsebare Zeilen verwirft, erfasst die Taproot-Aktivität ohne Warnung nur unvollständig.

Witness-Daten, Gewicht und Größe

SegWit verlagert Signaturen in einen separaten Witness. Dessen Inhalt hängt vom Typ des ausgegebenen Outputs ab:

• P2WPKH: eine DER-Signatur mit einem Sighash-Byte (üblicherweise 71 oder 72 Bytes) und ein komprimierter öffentlicher Schlüssel mit 33 Bytes.
• P2WSH: die zur Erfüllung erforderlichen Elemente, gefolgt vom Witness-Skript selbst, sodass die Ausgabebedingungen erst sichtbar werden, wenn der Output ausgegeben wird.
• P2TR-Schlüsselpfad: eine Schnorr-Signatur mit 64 Bytes (BIP 340) oder 65 Bytes bei einem vom Standard abweichenden Sighash-Typ. Eine Ausgabe über den Skriptpfad legt ein Skript (BIP 342) und einen Kontrollblock offen.
• In P2SH eingebettetes SegWit: Das scriptSig enthält nur ein kurzes Redeem-Skript wie 0014…, und die Signaturen befinden sich im Witness.

Witness-Bytes werden geringer gewichtet. BIP 141 definiert das Gewicht als Basisgröße × 3 + Gesamtgröße, wobei die Basisgröße Marker, Flag und Witness ausschließt; die virtuelle Größe (vsize) ist Gewicht ÷ 4, aufgerundet, und Gebührensätze werden pro vbyte angegeben. Im Beispiel beträgt die Basisform 113 Bytes, und der Witness-Abschnitt fügt einschließlich Marker und Flag 109 hinzu, insgesamt also 222 Bytes. Das Gewicht beträgt 113 × 3 + 222 = 561, und 561 ÷ 4 ergibt aufgerundet 141 vbytes.

Die dekodierte Ansicht und die Gebühr

Bitcoin Cores getrawtransaction mit Ausführlichkeitsgrad 2 gibt die dekodierte Transaktion sowie jeden ausgegebenen Output (prevout) und die Gebühr zurück, wenn der Node über die Undo-Daten des Blocks verfügt (Lektion 2.1 behandelt die Node-Aufrufe):

{
  "txid": "4f3a…c21e", "hash": "9b07…e4d2",
  "version": 2, "size": 222, "vsize": 141, "weight": 561, "locktime": 0,
  "vin": [{
    "txid": "7c1d…09ab", "vout": 1,
    "scriptSig": {"asm": "", "hex": ""},
    "txinwitness": ["3044…01", "02a1…5f"],
    "prevout": {"value": 0.01500000, "height": 868120,
      "scriptPubKey": {"type": "witness_v0_keyhash", "address": "bc1q…7k3f"}},
    "sequence": 4294967293
  }],
  "vout": [
    {"value": 0.01000000, "n": 0,
     "scriptPubKey": {"type": "witness_v0_keyhash", "address": "bc1q…m2d8"}},
    {"value": 0.00485900, "n": 1,
     "scriptPubKey": {"type": "witness_v0_keyhash", "address": "bc1q…x9qa"}}
  ],
  "fee": 0.00014100
}

Die Gebühr wird niemals in die Transaktion geschrieben; sie ergibt sich aus Inputs minus Outputs. Hier hat der eine Outpoint einen Wert von 1.500.000 sat, die Outputs ergeben zusammen 1.000.000 + 485.900 = 1.485.900 sat, die Gebühr beträgt also 14.100 sat, und 14.100 ÷ 141 = 100 sat/vB. Ein einfaches decoderawtransaction gibt dieselbe Struktur ohne prevout und fee zurück, da es die vorherigen Outputs nicht einsehen kann. Beträge werden in BTC als JSON-Zahlen geliefert; wandeln Sie sie vor jeder Berechnung in ganzzahlige Satoshis um (Lektion 2.6). Eine Coinbase-Transaktion hat keine Gebühr: Ihre Outputs beanspruchen die Blocksubvention zuzüglich aller anderen Gebühren. Lektion 2.9 zeigt dieselbe Berechnung in SQL anhand von Input- und Output-Tabellen.

txid gegenüber wtxid

Die txid ist der doppelte SHA-256-Hash der ohne Marker, Flag und Witness serialisierten Transaktion; die wtxid hasht die vollständige SegWit-Form, und Bitcoin Core zeigt sie als hash an. Ohne Witness-Daten sind beide identisch. Der Ausschluss des Witness beseitigte die Malleabilität durch Dritte: Eine Änderung der Signaturkodierung veränderte früher die txid einer ansonsten identischen Transaktion. Änderungen am Witness verändern heute nur die wtxid, sodass Ketten unbestätigter Transaktionen sicher aufeinander verweisen können. Blöcke binden wtxids über ein Witness-Commitment in der Coinbase ein. Identifizieren Sie Transaktionen in Berichten anhand der txid in der Byte-Reihenfolge der Anzeige.

Was Skripte über Wallets und Verwahrung verraten

Adressformate spiegeln die Geschichte von Wallets wider:

• 1…: alte Wallets, reine Legacy-Dienste, einige seit Langem bestehende Wallets von Börsen; neue P2PKH-Aktivität deutet heute oft auf ältere oder individuell entwickelte Software hin.
• 3…: bis zur Ausgabe mehrdeutig: Multisig oder eine Wallet mit einem einzelnen Schlüssel, die verschachteltes SegWit verwendet, eine verbreitete Standardeinstellung etwa von 2017–2019. Bei der Ausgabe klärt das Redeem-Skript dies auf: 0014 plus 20 Bytes ist verschachteltes P2WPKH, 0020 plus 32 Bytes verschachteltes P2WSH, ein mit ae (OP_CHECKMULTISIG) endendes Skript klassisches Multisig.
• bc1q…: in den letzten Jahren der Standardtyp für Empfangsadressen der meisten gängigen Wallets; P2WSH mit 62 Zeichen bedeutet üblicherweise Multisig oder ein anderes benutzerdefiniertes Skript.
• bc1p…: Wallets, die Taproot nach seiner Aktivierung bei Block 709.632 im November 2021 eingeführt haben, sowie Werkzeuge für Inscriptions und Token.

Skripttypen treten auch innerhalb von Transaktionen gemischt auf: Wenn alle Inputs P2WPKH sind und die Outputs aus einem P2WPKH und einem P2SH bestehen, ist der mit den Inputs übereinstimmende Output mit höherer Wahrscheinlichkeit Wechselgeld (eine Heuristik, keine Tatsache; siehe Lektion 4.2).

Klassisches Multisig

Klassisches Multisig verbirgt seine Ausgabebedingungen, solange die Mittel nicht ausgegeben sind (nur ein Hash befindet sich auf der Blockchain), und veröffentlicht sie bei der ersten Ausgabe. Ein 2-von-3-P2WSH-Input:

witness[0]  (leer)             -- von OP_CHECKMULTISIG benötigtes Dummy-Element
witness[1]  3044…01            -- erste Signatur (DER, Sighash-Byte 01)
witness[2]  3045…01            -- zweite Signatur
witness[3]  5221…21…21…53ae    -- OP_2 <key1> <key2> <key3> OP_3 OP_CHECKMULTISIG

52 ist OP_2 (zwei Signaturen erforderlich), jedes 21 legt einen Schlüssel mit 33 Bytes auf dem Stack ab, 53 ist OP_3 und ae ist OP_CHECKMULTISIG. Eine einzige Ausgabe legt den Schwellenwert, alle drei öffentlichen Schlüssel und die beiden Schlüssel offen, mit denen signiert wurde. Verwahrer verwenden häufig charakteristische Ausgabebedingungen (2-von-3, 3-von-5), und derselbe öffentliche Schlüssel in vielen Multisig-Skripten verknüpft diese Adressen wesentlich zuverlässiger mit einem Schlüsselinhaber als verhaltensbasierte Heuristiken. Viele Wallets sortieren Schlüssel lexikografisch (BIP 67), was selbst ein kleiner Fingerabdruck ist.

Taproot

Taproot kombiniert Schnorr-Signaturen mit 32 Bytes langen „x-only“-Schlüsseln (BIP 340), einem Output-Schlüssel Q = P + t·G, wobei P ein interner Schlüssel ist und der Tweak t eine Bindung an P und die Merkle-Wurzel eines optionalen Skriptbaums herstellt (BIP 341), sowie Skriptregeln, die OP_CHECKMULTISIG durch OP_CHECKSIGADD ersetzen (BIP 342).

Auf dem Schlüsselpfad sehen eine Wallet mit einem einzelnen Schlüssel, eine n-von-n-Gruppe mit Schlüsselaggregation (MuSig2) und ein Schwellenwertverfahren alle gleich aus. Der Skriptpfad legt nur das verwendete Blatt offen, wobei die Länge des Merkle-Pfads gewisse Rückschlüsse auf die Größe des Baums zulässt. Taproot beseitigt die Multisig-Spuren immer dann, wenn der Schlüsselpfad verwendet wird; es verbirgt weder Beträge noch den Graphen oder zeitliche Abläufe, und das Format bc1p selbst macht seine Nutzer weiterhin unterscheidbar. Ausgaben über den Skriptpfad enthalten auch Inscriptions: Seit 2023 betten große Witnesses mit einer OP_FALSE OP_IF … OP_ENDIF-Hülle Bilder und Token-Daten ein, ein Muster, das aus der Zahlungsanalyse herausgefiltert werden sollte.

Prüfungsschwerpunkt: Rechnen Sie mit Aufgaben zum Dekodieren oder Klassifizieren, nicht nur zum Abrufen von Wissen: Feldreihenfolge und -größen, Little-Endian-Werte und CompactSize; Outpoints und umgekehrte txid-Byte-Reihenfolge; scriptPubKey-Vorlagen, BIPs, Präfixe und Längen (1, 3, bc1q mit 42 und 62, bc1p mit 62); Base58Check-Versionsbytes und bech32 gegenüber bech32m; die Tatsache, dass Adressen, Input-Beträge und Gebühren abgeleitet und nicht gespeichert werden; Berechnung von Gewicht und vsize; Gebühr anhand vorheriger Outputs; txid gegenüber wtxid und Malleabilität; wie sich ein P2SH bei der Ausgabe eindeutig bestimmen lässt, was eine Multisig-Ausgabe offenlegt und was Taproot-Ausgaben über den Schlüsselpfad und den Skriptpfad verbergen.