Ich habe kürzlich versucht, mit dem getwork-Befehl für JSON-RPC herumzuspielen, und ich versuche zu verstehen, was ich davon habe. Laut dem Wiki-Eintrag der API-Aufrufliste sollte das Feld "Daten" die zu hashenden Blockdaten enthalten.
Das Datenfeld, das ich bekam, war:
00000001a10bacc7e639d1c69a01014bc5db6f2604b3477a3f273a4e019a232700000000a5942372cc60477c8a276e59c8f1a3f58654ea2f6c4402bf1b18e48455b5b8f64f10868b1c07475200000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000
Was, nachdem es gemäß dem Protokoll ein wenig seziert wurde, ergeben würde:
00000001 - version
a10bacc7e639d1c69a01014bc5db6f2604b3477a3f273a4e019a232700000000 - prev_block
a5942372cc60477c8a276e59c8f1a3f58654ea2f6c4402bf1b18e48455b5b8f6 - merkle_root
4f10868b - timestamp
1c074752 - bits
00000000 - nonce
00 - txn_count of 0?
0000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000 - ??
Stimmt etwas mit den Daten nicht, die ich erhalte? Würde der Client anders reagieren, wenn ich ihn mit der Option -gen ausführe?
Die Anzahl der Transaktionen im Header ist gemäß der Spezifikation immer null . Die -genOption hat keine Auswirkung auf den getworkRPC-Aufruf.
Ich bin mir nicht sicher, was Ihrer Meinung nach an dieser Information falsch ist, aber wenn es nur die Transaktionszahl von null ist, ist das immer so. Wenn es die Tatsache ist, dass Sie nur die Header erhalten, die Sie hashen müssen, ist es immer so. Natürlich nonceist das 0, weil der Client keine Ahnung hat, was die Nonce sein sollte. (Das ist der Sinn des Minings .)
DerPiachu