Недавно я пытался поиграть с командой getwork для JSON-RPC и пытаюсь понять, что из этого получилось. Согласно вики-записи API Call List , поле «данные» должно содержать данные блока, которые необходимо хэшировать.
Поле данных, которое я получил, было:
00000001a10bacc7e639d1c69a01014bc5db6f2604b3477a3f273a4e019a232700000000a5942372cc60477c8a276e59c8f1a3f58654ea2f6c4402bf1b18e48455b5b8f64f10868b1c07475200000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000
Что после небольшого вскрытия в соответствии с протоколом даст:
00000001 - version
a10bacc7e639d1c69a01014bc5db6f2604b3477a3f273a4e019a232700000000 - prev_block
a5942372cc60477c8a276e59c8f1a3f58654ea2f6c4402bf1b18e48455b5b8f6 - merkle_root
4f10868b - timestamp
1c074752 - bits
00000000 - nonce
00 - txn_count of 0?
0000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000 - ??
Что-то не так с данными, которые я получаю? Будет ли клиент реагировать по-другому, если я запущу его с параметром -gen?
Согласно спецификации количество транзакций в заголовке всегда равно нулю . Параметр -genне влияет на getworkвызов RPC.
Я не уверен, что вы считаете неправильным в этой информации, но если это просто нулевое количество транзакций, это всегда так. Если дело в том, что вы получаете только те заголовки, которые вам нужно хэшировать, так всегда и будет. Конечно, nonceэто 0, потому что клиент понятия не имеет, каким должен быть одноразовый номер. (В этом смысл майнинга .)
Пиачу