RPC-Byte-Reihenfolge

Die Zeichenkette aus 64 Zeichen, die Ihre Wallet als Transaktions-ID bezeichnet, folgt nicht der Reihenfolge, die diese Bytes sonst überall haben. Bitcoin Core hält einen Hash in einem Typ, der ihn mit dem höchstwertigen Byte zuerst ausgibt, jeder Explorer hat diese Gewohnheit übernommen, und die Konvention ist heute dauerhaft. Sie ist harmlos, wenn Sie einen Bezeichner in ein Suchfeld einfügen, und teuer, wenn Sie ihn in Code einfügen.

Wie es funktioniert

Die RPC-Byte-Reihenfolge ist eine Darstellungstransformation, die beim Verlassen eines Nodes angewendet wird, kein anderer Hash.

Ein Hash verlässt SHA-256 als 32 Bytes ohne inhärente Richtung. Bitcoin Core hält ihn in einem Container, der diese Bytes als eine einzige sehr große Zahl darstellt, und beim Ausgeben einer Zahl steht der höchstwertige Teil links, wodurch das Byte-Array umgekehrt wird. Jedes JSON-Feld, das einen Block oder eine Transaktion benennt, kommt so heraus: der Hash aus getblockhash, die txid aus getrawtransaction, der merkleroot aus getblock, der previousblockhash, der einen Block mit seinem Vorgänger verbindet.

Eine Folge davon zeigt sich auf der Startseite jedes Explorers. Proof of Work erzeugt Hashes, die in dieser ausgegebenen Richtung mit einer langen Folge von Nullen beginnen. Diese Nullen stehen am entgegengesetzten Ende der rohen Bytes. Über Mining-Ziele lässt sich in der ausgegebenen Form leichter nachdenken, was zum Teil erklärt, warum die Konvention beibehalten statt bereinigt wurde.

Die Umkehrung betrifft nur Hashes. Öffentliche Schlüssel, Signaturen, Skripte und Witness-Elemente werden alle in ihrer tatsächlichen Reihenfolge ausgegeben, sodass ein Skript aus decodescript direkt mit der rohen Transaktion verglichen werden kann, eine txid dagegen nicht. Diese beiden Regeln zu vermischen ist der Punkt, an dem funktionierender Code meistens scheitert.

Eine einzige Antwort kann sogar beide Konventionen zugleich enthalten. Fordern Sie eine Transaktion mit ausführlicher Ausgabe an, ist das Feld txid umgekehrt, während das daneben stehende Feld hex die unveränderte Serialisierung ist, die denselben Hash in der anderen Reihenfolge enthält.

Wo Sie sie sehen

Die RPC-Byte-Reihenfolge ist die einzige Form eines Hashes, mit der die meisten Menschen je zu tun haben.

Sie ist das, was eine Börse in eine Bestätigungs-E-Mail für eine Auszahlung schreibt, was ein Block-Explorer in einer URL erwartet, worum ein Support-Mitarbeiter Sie bittet und was bitcoin-cli ausgibt. Wenn Sie einen Node mit getblockhash 0 nach dem allerersten Block fragen, erhalten Sie 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f, und wenn Sie diese Zeichenkette in einen beliebigen Explorer einfügen, landen Sie bei dem Block, der am 3. Januar 2009 gemint wurde.

Der Fehlerfall ist eng umgrenzt und gleichbleibend. Jemand berechnet einen Transaktionsbezeichner selbst, hasht die Serialisierung zweimal mit SHA-256, vergleicht das Ergebnis mit einem Explorer und findet keinerlei Ähnlichkeit. Beide Zeichenketten sind dieselben 32 Bytes, und eine davon muss umgekehrt werden. Dieselbe Korrektur gilt, wenn ein Skript eine txid aus einer rohen Eingabe zieht und sie in einer Tabelle von Bezeichnern sucht, die aus einer API gesammelt wurden.

Es gibt eine Zwei-Sekunden-Gewohnheit, die sich lohnt. Wenn ein Hash, den Ihnen jemand geschickt hat, nirgendwohin führt, versuchen Sie ihn umgekehrt, bevor Sie schließen, dass die Transaktion nicht existiert. Support-Threads sind voll von Hashes, die aus rohen Daten statt aus einer Wallet kopiert wurden, und sie sehen völlig gültig aus, bis man sie umkehrt.