Unclear on double-hashing previous Transaction when creating a new Transaction

Question

I'm having trouble performing the double-sha256 hash of the previous transaction, Step 3 in this explanation.

The previous transaction is:

084fb53458bda42cf906dc2608fe962667188849e51e1dc13cd291cc13c97290

I've input the full transaction I want to perform into coinb.in as shown here, giving me a full transaction of:

01000000019072c913cc91d23cc11d1ee5498818672696fe0826dc06f92ca4bd5834b54f08010000001976a91460077bce1849cc2a41e2ccaa6ec575b3f5b70a9d88acffffffff0120a107000000000017a9144574085e1ef5432a6b09218f3b6ab6128f8eb2a58700000000

From what I understand, the double-sha256 of the previous tx here is:

9072c913cc91d23cc11d1ee5498818672696fe0826dc06f92ca4bd5834b54f08

However when I perform sha256 twice I get something completely different.

Example

Previous transaction:

084fb53458bda42cf906dc2608fe962667188849e51e1dc13cd291cc13c97290

Round one sha256 (with hex as input using anyhash.com):

9bbbb52bff2c553f84942188c87674c5b641b266baeb7ca216bebec8cd6a95bb

Round two sha256 (hex input also):

e5a3d32d306ef94968e0f77e6b0b496bfe9d5cd0fe6246a4ba7fd2fddf11cdf1

This final value does not match the one given by coinb.in's transaction. Am I missing something here? I see that the other question mentions the transaction in reverse order, what exactly does this mean?

Answer 1

I've figured it out.

So in this case (and if you look up a previous transaction on sites like blockchain.info) the transaction ID is already the double-hashed transaction. The input to the new transaction is just the reverse of the transaction ID.

So my previous transaction starts: 90 72 c9 13 ...

and the full transaction created by coinb.in ends in: ... 13 c9 72 90

Answer 2

ok, based on your last comment (24th of Jan 2018), I see "Error running script for input 0 referencing tx ID 0" - I can't see were it comes from, so have to review the raw tx itself. You have the previous tx (084FB53458BDA42CF...) and the pubkey hash (60077BCE18...) of address "19kkqPQXG5qjiiMByncH9vwkSzyeL68iCP" in the input section (outpoint index 1). So you need to have the corresponding privkey for this address.

Disassembly:

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

Your assembled tx in the question has the correct previous tx ID (correctly reversed), and also v_in outpoint index 1 is correct. The tx_out part spends 0.005 bitcoin to a P2SH, which translates to "382FYsZ6RceiPXMZLHcyonxkVRFguBHQ5T" bitcoin address. The double sha256 of this structure is "191b851f02e588724076e513485a65d18611f7d8d8b03a2aa6a1da996fd0525d", you posted something different... The examples below are however correct. Here is a short script to convert on the OpenBSD / OSX / Linux shell:

#!/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

The double sha256 would have to get signed. (You can follow the example from the referenced page, the result in step 14 is shown reversed).

And the only difference I can see is in step 13, where the added "01000000" (reversed 01 for SIGHASHALL) is missing in your tx. BTW: the example section provides correct responses to the double sha256 (though as you found out it is not necessary). I would check this:

1. the signature you provide comes from the privkey, which corresponds to this address: 19kkqPQXG5qjiiMByncH9vwkSzyeL68iCP

2. the transaction might need the step 13 from the example (SIGHASH_ALL)

3. the doubla sha256 hash for this should then result in 6f48882e380e945143b7a0befaf6d47326ecc2ab043100a8cc1757b53902de1c

Oh, one more hint: why don't you use testnet or regtest? This prevents you from loosing too many fees or even worth, unspendable outputs :-) When using regtest, you can even post tx details and keys, without having fear to loose any values... This allows others to replay the tx signing process (with their tools).