RPC 字节序

您的钱包称为交易 ID 的64个字符的字符串，其字节顺序与这些字节在其他任何地方的顺序并不相同。Bitcoin Core 将哈希保存在一种以最高有效字节在前的方式打印的类型中，所有区块浏览器都沿用了这一习惯，这一约定如今已成定局。把标识符粘贴到搜索框时，它无伤大雅；把它粘贴到代码中时，代价却很高。

运作方式

RPC 字节序是节点输出时应用的一种显示转换，并不是另一种哈希。

摘要从 SHA-256输出时是32个字节，本身没有固有的方向。Bitcoin Core 把它存放在一个容器中，该容器将这些字节视为一个极大的数字，而打印数字时最高有效部分在左，这就使字节数组发生了反转。每个指代区块或交易的 JSON 字段都以这种方式输出：getblockhash 返回的 hash、getrawtransaction 返回的 txid、getblock 返回的 merkleroot，以及将区块与其父区块相连的 previousblockhash。

每个区块浏览器的首页上都能看到一个后果。工作量证明产生的摘要，在这种打印方向上以一长串零开头。这些零位于原始字节的另一端。挖矿目标在打印形式下更容易推理，这也是这一约定得以保留、而没有被整理修正的部分原因。

这种反转仅适用于哈希。公钥、签名、脚本和见证项都按其真实顺序打印，因此可以将 decodescript 得到的脚本直接与原始交易比对，而 txid 则不能。混淆这两条规则，正是可正常运行的代码通常出错的地方。

同一个响应中甚至可以同时包含两种约定。以详细输出请求一笔交易时，txid 字段是反转的，而紧挨着它的 hex 字段是未经改动的序列化数据，其中包含的是顺序相反的同一个哈希。

在哪里会遇到它

对大多数人而言，RPC 字节序是他们接触到的唯一一种哈希形式。

交易所在提币确认邮件中写的是它，区块浏览器的网址中要求的是它，客服人员请您发送的是它，bitcoin-cli 打印的也是它。用 getblockhash 0向节点请求第一个区块，返回000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f，把这个字符串粘贴到任何区块浏览器中，都会指向2009年1月3日挖出的区块。

这种失败情形范围很窄，表现也很一致。有人自行计算交易标识符，对序列化数据做两次 SHA-256哈希，再与区块浏览器比对，发现两者毫无相似之处。两个字符串是同样的32个字节，其中一个需要反转。当脚本从原始输入中提取 txid，并在从 API 收集的标识符表中查找它时，同样的修正方法也适用。

有一个只需两秒的习惯值得养成。如果别人发给您的哈希无法查到任何结果，在断定该交易不存在之前，请先把它反过来试一试。支持类的讨论帖中充斥着从原始数据而非钱包中复制的哈希，它们看上去完全有效，直到被反转为止。