Getwork y GetMemoryPool: ¿por qué el hash de bloque anterior es diferente?

Cuando llamé:

print bitcoin.getmemorypool()
print bitcoin.getwork()

usando Python JSON para un servidor testnet BitcoinQT, obtuve las siguientes respuestas:

{'previousblockhash': '00000000032e361b246e96c4e594523b6ff42bc0527e560f203fb20a08a86185', 'transactions': ..., 'version': 1, 'coinbasevalue': 5000400000, 'time': 1329342730, 'bits': '1c2336a4'}
{... 'data': '0000000108a86185203fb20a527e560f6ff42bc0e594523b246e96c4032e361b000000004c50804820b143e1583c8c49dd43a6ddb8bc777c57c2da4a92b39ee0e709bf504f3c290b1c2336a400000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000', ...}

Comparando el hash de bloque anterior de GetMemoryPool y uno extraído del encabezado de bloque de Getwork:

00000000 032e361b 246e96c4 e594523b 6ff42bc0 527e560f 203fb20a 08a86185
08a86185 203fb20a 527e560f 6ff42bc0 e594523b 246e96c4 032e361b 00000000

Por lo que puedo ver, los datos se invierten en fragmentos de 4 bytes. ¿Por qué se realiza tal procedimiento y qué otros campos de esas dos llamadas RPC se someten a tal operación?

Como, en serio, ya es bastante malo que Bitcoin use dos endianness diferentes en bytes, ahora también tenemos un poco de endianness de palabras de endianness grande (¿supongo que eso es lo que uno llamaría un conjunto de 4 bytes?)?

Respuestas (1)

El valor de previousblockhashla getmemorypoolsalida es el hash del bloque en orden big-endian.

El valor de datala getworksalida tiene el formato que describí en esta respuesta a su pregunta sobre cómo hash1se calcula.

Esta inversión del orden de bytes en palabras de 4 bytes se realiza mediante una función llamada FormatHashBuffersen main.cpp. Solo se hace para los campos datay de la salida. No hay ningún comentario que explique por qué se hace.hash1getwork