Was bedeutet Endianness?
Endianness (Byte-Reihenfolge) beschreibt, in welcher Reihenfolge mehrere Bytes zu einer Zahl oder zu einer Hex-Zeichenkette zusammengelesen werden.
Die einzelnen Bytes selbst ändern sich dabei nicht. Es geht nur um die Darstellung und Interpretation derselben Daten.
Bytes:
01 23 45 67Bytefolge
01234567dieselben Bytes
Big Endian
01234567Little Endian
67452301Wert 1 (32-Bit, Little Endian)
01000000dieselben Bytes
Big Endian
01000000Little Endian
0000000101 00 00 00 als Little Endian gelesen = 1
Big-Endian-Darstellung: 01234567 (höchstwertiges Byte zuerst)
Little-Endian-Darstellung: 67452301 (niedrigstwertiges Byte zuerst)
Oben stehen dieselben vier Bytes. Unterschiedlich ist nur, ob du sie von links nach rechts oder in umgekehrter Byte-Reihenfolge als Hex-String liest.
Big Endian und Little Endian
Bei Big Endian steht das höchstwertige Byte an erster Stelle. Die Hex-Darstellung liest sich wie eine gewohnte Zahl von links nach rechts.
Bei Little Endian steht das niedrigstwertige Byte zuerst. Viele Felder in Bitcoin-Transaktionen und im Blockheader werden intern so gespeichert.
Ein einfaches Zahlenbeispiel mit vier Bytes:
01 00 00 00Werden diese Bytes als Little Endian interpretiert, ergibt das den Wert 1.
Als Big Endian wären es 16777216 (0x01000000). Dieselben Bytes, unterschiedliche Leserichtung.
Endianness hat nichts mit Kryptographie zu tun. SHA-256 und SHA256d liefern fest definierte 32 Bytes. Endianness betrifft nur, wie du diese Bytes danach anzeigst oder Felder in einer Transaktion dekodierst.
Wo begegnet Endianness in Bitcoin?
In Bitcoin tauchen beide Konventionen nebeneinander auf:
| Bereich | Typische Konvention |
|---|---|
| TXID in Explorern | Byte-Reihenfolge umgekehrt zur internen Hash-Ausgabe |
| Blockhash in Explorern | ebenfalls umgekehrte Byte-Reihenfolge |
| Prev-TXID in Inputs | umgekehrte Darstellung (32 Byte) |
| Version, Locktime, Nonce, nBits im Header | Little Endian in der serialisierten Bytefolge |
| Beträge in Outputs | Little Endian (8 Byte) |
Wenn du Rohdaten mit einem Hex-Editor liest, siehst du die interne Reihenfolge. In einem Block Explorer siehst du bei Hashes oft die umgekehrte Darstellung.
TXIDs und Blockhashes
SHA256d berechnet aus Transaktions- oder Headerdaten immer 32 Byte Hash-Ergebnis. Mehr dazu bei TXID und Blockhash.
Die in Explorern gezeigte TXID oder der angezeigte Blockhash sind nicht ein anderer Hash. Es ist dieselbe Bytefolge, nur in umgekehrter Byte-Reihenfolge als Hex geschrieben.
Wichtig:
- Die Umkehrung ist kein Teil von SHA256d.
- Die Umkehrung verändert den Hash nicht, nur die Leserichtung der 32 Bytes.
- Es handelt sich um eine Darstellungskonvention von Bitcoin Core und Explorern.
TXID im Explorer
4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33bals Bytefolge
4a 5e 1e 4b aa b8 9f 3a 32 51 8a 88 c3 1b c8 7f 61 8f 76 67 3e 2c c7 7a b2 12 7b 7a fd ed a3 3bIntern (SHA256d)
3ba3edfd7a7b12b27ac72c3e67768f617fc81bc3888a51323a9fb8aa4b1e5e4aals Bytefolge
3b a3 ed fd 7a 7b 12 b2 7a c7 2c 3e 67 76 8f 61 7f c8 1b c3 88 8a 51 32 3a 9f b8 aa 4b 1e 5e 4aTypischer Entwicklerfehler
Viele Tools liefern nach SHA256d den Hash in interner Byte-Reihenfolge. Der Block Explorer zeigt die umgekehrte Darstellung.
SHA256d berechnet
↓
Hash stimmt scheinbar nicht mit Explorer überein
↓
Ursache: Byte-ReihenfolgePraktischer Check: Nimm den Explorer-Hash, kehre die Byte-Reihenfolge um (je zwei Hex-Zeichen = ein Byte), und vergleiche mit dem direkten Hash-Output deiner Bibliothek. Details zu Hex und Bytes stehen auf der SHA-256-Seite.
Wer Transaktionen serialisiert, muss zusätzlich zwischen Text-Hex und dekodierten Bytes unterscheiden. Dazu siehe Hex, Text und Bytes.