sha256 - (比特币)从 getwork 函数计算哈希 - 怎么做？

Question

当我在我的 bitcoind 服务器上调用 getwork 时，我得到以下信息:

./bitcoind getwork
{
    "midstate" : "695d56ae173bbd0fd5f51d8f7753438b940b7cdd61eb62039036acd1af5e51e3",
    "data" : "000000013d9dcbbc2d120137c5b1cb1da96bd45b249fd1014ae2c2b400001511000000009726fba001940ebb5c04adc4450bdc0c20b50db44951d9ca22fc5e75d51d501f4deec2711a1d932f00000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000",
    "hash1" : "00000000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000010000",
    "target" : "00000000000000000000000000000000000000000000002f931d000000000000"
}

该协议(protocol)似乎没有记录。如何从这些数据中计算哈希值。我认为这些数据是小端的。那么第一步是将所有内容都转换为大端？完成后，我计算数据的 sha256。数据可以分成两 block ，每 block 64 字节。第一个卡盘的哈希由 midstate 给出，因此不必计算。

因此，我必须使用 sha256 对 block #2 进行散列，使用中间状态作为初始散列值。完成后，我最终得到了 block 2 的散列，即 32 个字节。我再次计算这个 block 的哈希以获得最终的哈希。

然后，我是否将所有内容都转换为小端并提交工作？

hash1 是做什么用的？

Answer 1

哈希计算记录在 Block hashing algorithm .
从相对简单的基础开始。基本数据结构记录在 Protocol specification - Bitcoin Wiki .请注意，协议(protocol)定义(和工作定义)或多或少假设 SHA-256 哈希是 256 位小端值，而不是标准所暗示的大端值。也可以看看

Getwork 更复杂，并且会遇到更严重的字节序/字节顺序困惑。

首先请注意，getwork API 经过优化以加快挖掘的初始步骤。
midstate 和 hash1 值用于这些性能优化，可以忽略。只看“数据”。
并且当使用标准 sha256 实现时，只有“数据”的前 80 个字节(160 个十六进制字符)被散列。

不幸的是，getwork 数据结构中呈现的 JSON 数据与上面的 block 示例中散列所需的字节序特征不同。

他们都说去源头寻找答案，但是 C++ 源代码可能很大而且令人困惑。一个简单的替代方法是 poold.py代码。这里有讨论:New mining pool for testing .您只需要查看“checkwork”例程的前几行，以及“bufreverse”和“bytereverse”函数，即可获得正确的字节顺序。最后，只需对数据的每个 32 位段中的字节进行反转即可。是的——很奇怪。但是字节序问题很棘手，可能会以这种方式结束......

有关“getwork”工作方式的其他一些有用信息可以在以下讨论中找到:

Do I understand header hashing?

Stupid newbie question about the nonce

请注意，在原始比特币论坛中找到信噪比变得非常困难，目前有一个 Area51 提议 StackExchange site for Bitcoin and Crypto Currency in general .来加入我们吧!