Recientemente intenté jugar con el comando getwork para JSON-RPC y estoy tratando de entender qué obtuve. De acuerdo con la entrada wiki de la Lista de llamadas de la API , el campo "datos" debe contener los datos del bloque que se van a codificar.
El campo de datos que obtuve fue:
00000001a10bacc7e639d1c69a01014bc5db6f2604b3477a3f273a4e019a232700000000a5942372cc60477c8a276e59c8f1a3f58654ea2f6c4402bf1b18e48455b5b8f64f10868b1c07475200000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000
Que después de ser disecado un poco de acuerdo con el protocolo daría como resultado:
00000001 - version
a10bacc7e639d1c69a01014bc5db6f2604b3477a3f273a4e019a232700000000 - prev_block
a5942372cc60477c8a276e59c8f1a3f58654ea2f6c4402bf1b18e48455b5b8f6 - merkle_root
4f10868b - timestamp
1c074752 - bits
00000000 - nonce
00 - txn_count of 0?
0000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000 - ??
¿Hay algún problema con los datos que estoy recibiendo? ¿Respondería el cliente de manera diferente si lo ejecuto con la opción -gen?
El número de transacciones en el encabezado siempre es cero, según la especificación . La -genopción no tiene efecto en la getworkllamada RPC.
No estoy seguro de qué cree que está mal con esa información, pero si es solo el recuento de transacciones cero, siempre es así. Si es el hecho de que solo obtiene los encabezados que necesita codificar, siempre es así. Por supuesto, noncees 0 porque el cliente no tiene idea de cuál debería ser el nonce. (Ese es el punto de la minería ).
elpiachu