Tengo problemas para realizar el hash double-sha256 de la transacción anterior, paso 3 de esta explicación.
La transacción anterior es:
084fb53458bda42cf906dc2608fe962667188849e51e1dc13cd291cc13c97290
Ingresé la transacción completa que quiero realizar en coinb.in como se muestra aquí , dándome una transacción completa de:
01000000019072c913cc91d23cc11d1ee5498818672696fe0826dc06f92ca4bd5834b54f08010000001976a91460077bce1849cc2a41e2ccaa6ec575b3f5b70a9d88acffffffff0120a107000000000017a9144574085e1ef5432a6b09218f3b6ab6128f8eb2a58700000000
Por lo que entiendo, el doble-sha256 del tx anterior aquí es:
9072c913cc91d23cc11d1ee5498818672696fe0826dc06f92ca4bd5834b54f08
Sin embargo, cuando ejecuto sha256 dos veces, obtengo algo completamente diferente.
Ejemplo
Transacción anterior:
084fb53458bda42cf906dc2608fe962667188849e51e1dc13cd291cc13c97290
Ronda uno sha256 ( con hexadecimal como entrada usando anyhash.com ):
9bbbb52bff2c553f84942188c87674c5b641b266baeb7ca216bebec8cd6a95bb
Ronda dos sha256 (entrada hexadecimal también):
e5a3d32d306ef94968e0f77e6b0b496bfe9d5cd0fe6246a4ba7fd2fddf11cdf1
Este valor final no coincide con el dado por la transacción de coinb.in. ¿Me estoy perdiendo de algo? Veo que la otra pregunta menciona la transacción en orden inverso , ¿qué significa esto exactamente?
Lo he descubierto.
Entonces, en este caso (y si busca una transacción anterior en sitios como blockchain.info), la identificación de la transacción ya es la transacción de doble hash. La entrada a la nueva transacción es justo lo contrario de la identificación de la transacción.
Entonces mi transacción anterior comienza:90 72 c9 13 ...
y la transacción completa creada por coinb.in termina en:... 13 c9 72 90
Error running script for input 0 referencing [transaction ID] at 0: Script was NOT verified successfully.ok, según su último comentario (24 de enero de 2018), veo "Error al ejecutar el script para la entrada 0 que hace referencia a tx ID 0". No puedo ver de dónde proviene, así que tengo que revisar el tx sin procesar. Tiene el tx anterior (084FB53458BDA42CF...) y el hash pubkey (60077BCE18...) de la dirección "19kkqPQXG5qjiiMByncH9vwkSzyeL68iCP" en la sección de entrada (índice de punto de salida 1). Por lo tanto, debe tener la clave privada correspondiente para esta dirección.
Desmontaje:
01000000019072c913cc91d23cc11d1ee5498818672696fe0826dc06f92ca4bd5834b54f08010000001976a91460077bce1849cc2a41e2ccaa6ec575b3f5b70a9d88acffffffff0120a107000000000017a9144574085e1ef5432a6b09218f3b6ab6128f8eb2a58700000000
VERSION
01000000
TX_IN COUNT [var_int]: hex=01, decimal=1
TX_IN[0]
TX_IN[0] OutPoint hash (char[32])
084FB53458BDA42CF906DC2608FE962667188849E51E1DC13CD291CC13C97290
TX_IN[0] OutPoint index (uint32_t)
hex=01000000, reversed=00000001, decimal=1
TX_IN[0] Script Length (var_int)
hex=19, decimal=25
TX_IN[0] Script Sig (uchar[])
76A91460077BCE1849CC2A41E2CCAA6EC575B3F5B70A9D88AC
TX_IN[0] Sequence (uint32_t)
FFFFFFFF
TX_OUT COUNT, hex=01, decimal=1
TX_OUT[0]
TX_OUT[0] Value (uint64_t)
hex=20A1070000000000, reversed_hex=000000000007A120, dec=500000, bitcoin=0.00500000
TX_OUT[0] PK_Script Length (var_int)
hex=17, dec=23
TX_OUT[0] pk_script (uchar[])
A9144574085E1EF5432A6B09218F3B6AB6128F8EB2A587
LOCK_TIME
00000000
Su tx ensamblado en la pregunta tiene la ID de tx anterior correcta (correctamente invertida), y también v_in outpoint index 1 es correcto. La parte tx_out gasta 0.005 bitcoin en un P2SH, lo que se traduce en la dirección de bitcoin "382FYsZ6RceiPXMZLHcyonxkVRFguBHQ5T". El doble sha256 de esta estructura es "191b851f02e588724076e513485a65d18611f7d8d8b03a2aa6a1da996fd0525d", publicaste algo diferente... Sin embargo, los ejemplos a continuación son correctos. Aquí hay un breve script para convertir en el shell de OpenBSD/OSX/Linux:
#!/bin/sh
# Bitcoin never does hashes with the hex strings,
# so need to convert it to hex codes in file:
tmp_hex_fn=tmp_file.hex
tmp_hex_sha256_fn=tmp_sha256.hex
tmp_txt_sha256_fn=tmp_sha256.txt
tmp_hex_dsha256_fn=tmp_dsha256.hex
tmp_txt_dsha256_fn=tmp_dsha256.txt
printf $( echo $1 | sed 's/[[:xdigit:]]\{2\}/\\x&/g' ) > $tmp_hex_fn
hexdump -C $tmp_hex_fn
# sha256
openssl dgst -sha256 <$tmp_hex_fn >$tmp_txt_sha256_fn
openssl dgst -sha256 -binary <$tmp_hex_fn >$tmp_hex_sha256_fn
openssl dgst -sha256 <$tmp_hex_sha256_fn >$tmp_txt_dsha256_fn
openssl dgst -sha256 -binary <$tmp_hex_sha256_fn >$tmp_hex_dsha256_fn
printf "sha256: "
cat $tmp_txt_sha256_fn
printf "dsha256: "
cat $tmp_txt_dsha256_fn
El doble sha256 tendría que firmarse. (Puede seguir el ejemplo de la página de referencia, el resultado en el paso 14 se muestra al revés).
Y la única diferencia que puedo ver está en el paso 13, donde falta el "01000000" agregado (01 invertido para SIGHASHALL) en su tx. Por cierto: la sección de ejemplos proporciona respuestas correctas al doble sha256 (aunque, como descubrió, no es necesario). Yo comprobaría esto:
la firma que proporciona proviene de la clave privada, que corresponde a esta dirección: 19kkqPQXG5qjiiMByncH9vwkSzyeL68iCP
la transacción podría necesitar el paso 13 del ejemplo (SIGHASH_ALL)
el hash doubla sha256 para esto debería resultar en 6f48882e380e945143b7a0befaf6d47326ecc2ab043100a8cc1757b53902de1c
Oh, una pista más: ¿por qué no usas testnet o regtest? Esto evita que pierda demasiadas tarifas o incluso valor, salidas no gastables :-) Al usar regtest, incluso puede publicar detalles y claves de tx, sin tener miedo de perder ningún valor... Esto permite que otros reproduzcan el proceso de firma de tx ( con sus herramientas).
pebwindkraft