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

The previous transaction is:


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


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


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


Previous transaction:


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


Round two sha256 (hex input also):


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?

  • There is several possibilities of presenting data. For some reason bitcoin mixes them in different areas. On hashing: did you try to hash the ASCII string (wheat OS, which tools)? Jan 15, 2018 at 22:48

2 Answers 2


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

  • cool, +1 you found the solution yourself, I was just about looking data up in the system. Saves me some work :-) A good reference (next to this forum here) was this page: righto.com/2014/02/bitcoins-hard-way-using-raw-bitcoin.html, and for sure Andreas' book "Mastering Bitcoin"... Jan 15, 2018 at 23:05
  • ah thanks for this. This is helpful as I'm still having trouble at the signing stage. When I try to push a testnet transaction I get the error Error running script for input 0 referencing [transaction ID] at 0: Script was NOT verified successfully. Jan 24, 2018 at 15:42

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.




TX_IN COUNT [var_int]: hex=01, decimal=1
  TX_IN[0] OutPoint hash (char[32])
  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[])
  TX_IN[0] Sequence (uint32_t)

TX_OUT COUNT, hex=01, decimal=1
  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[])


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:

# Bitcoin never does hashes with the hex strings, 
# so need to convert it to hex codes in file:


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).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.