RPCバイト順

ウォレットがトランザクションIDと呼ぶ64文字の文字列は、そのバイトがほかのどこかで取る順序とは異なります。Bitcoin Coreはハッシュを最上位バイトから先に表示する型で保持しており、すべてのエクスプローラーがその慣習を引き継いだため、この取り決めは今では固定しています。識別子を検索ボックスに貼り付けるときは無害ですが、コードに貼り付けるときは高くつきます。

仕組み

RPCバイト順は、ノードから出ていくときに適用される表示上の変換であり、別のハッシュではありません。

ダイジェストはSHA-256から32バイトとして出力され、それ自体に決まった向きはありません。Bitcoin Coreはそれを、これらのバイトを1つの非常に大きな数として扱うコンテナに保持しており、数を表示すると最上位の部分が左に来るため、配列が逆になります。ブロックやトランザクションを指すすべてのJSONフィールドはこの形で出力されます。getblockhashが返すハッシュ、getrawtransactionが返すtxid、getblockが返すmerkleroot、ブロックを親ブロックにつなぐpreviousblockhashがそれです。

1つの結果は、どのエクスプローラーのトップページにも現れます。プルーフ・オブ・ワークは、この表示方向では長いゼロの連続で始まるダイジェストを生成します。そのゼロは生のバイト列の反対側の端にあります。マイニングのターゲットは表示された形のほうが考えやすいため、この取り決めが修正されずに残った一因となっています。

反転が適用されるのはハッシュだけです。公開鍵、署名、スクリプト、ウィットネスの項目はすべて本来の順序で表示されるため、decodescriptで得たスクリプトは生のトランザクションと直接比較できますが、txidはそうはいきません。この2つの規則を混同することが、動作するコードがつまずく典型的な箇所です。

1つのレスポンスが両方の取り決めを同時に含むことさえあります。トランザクションを詳細出力で要求すると、txidフィールドは逆順になりますが、その隣にあるhexフィールドは手を加えていないシリアライズ結果で、同じハッシュを逆の順序で含んでいます。

目にする場面

RPCバイト順は、ほとんどの人が実際に扱うハッシュの唯一の形式です。

取引所が出金確認のメールに載せるもの、ブロックエクスプローラーがURLで期待するもの、サポート担当者が送るよう求めるもの、bitcoin-cliが表示するものがこれです。ノードにgetblockhash 0で最初のブロックを要求すると000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26fが返り、この文字列をどのエクスプローラーに貼り付けても2009年1月3日にマイニングされたブロックに解決されます。

失敗の仕方は限られており、一貫しています。ある人が自分でトランザクション識別子を計算し、シリアライズ結果をSHA-256で2回ハッシュ化し、その結果をエクスプローラーと比べると、まったく似ていないのです。どちらの文字列も同じ32バイトであり、そのうち片方を反転する必要があります。スクリプトが生の入力からtxidを取り出し、APIから集めた識別子の表でそれを探す場合も、同じ修正が当てはまります。

身につける価値のある2秒の習慣があります。誰かから送られたハッシュがどこにも解決しない場合は、トランザクションが存在しないと結論づける前に、逆順で試してください。サポートのスレッドには、ウォレットからではなく生データからコピーされたハッシュがあふれており、それらは反転するまで完全に有効に見えます。