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

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?

• 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)? Commented Jan 15, 2018 at 22:48

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"... Commented 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`. Commented 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.

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