How would one go about acquiring the HashofThingtoSign from this old transaction?

Question

How would one go about acquiring the HashofThingToSign that is used in the "Signature Generation" equation for this example transaction such that it could easily also be applied to any other given pre-existing transaction?

Example Transaction: 82d62d5f4e69ae8338c39b7ae2e1d33db59bdf62c869ded7344adc936bab8653

Found at: https://blockchain.info/tx/82d62d5f4e69ae8338c39b7ae2e1d33db59bdf62c869ded7344adc936bab8653

This is made of the Raw Transaction:

0100000001b1bbfd7a3103e733b5f28fb1eef07ba683b787bcf4033a16d8791a15152a006c000000006b483045022100d52330113ccd033ccb1aaa3b759e9696c216e802922e5f1902cd5ada69c612e5022057880205319dccb05eebbe34323a852ee82653f09f81253ddccd08a810e9d42d012103e5b9f0bb669b289efb8d2826487a24ef5f3985624c8bc3a3e34f6bd54e080b27feffffff027c8d3700000000001976a91443bd19b0436db26d24c789bebaee9a3b1b73cdd388acc1bbe114000000001976a914aefaa9d79e3c62c3f0cc909a3aee327e6cd0100a88acb2480700

The input script is:

3045022100d52330113ccd033ccb1aaa3b759e9696c216e802922e5f1902cd5ada69c612e5022057880205319dccb05eebbe34323a852ee82653f09f81253ddccd08a810e9d42d01 03e5b9f0bb669b289efb8d2826487a24ef5f3985624c8bc3a3e34f6bd54e080b27

The Output scripts are:

OP_DUP OP_HASH160 43bd19b0436db26d24c789bebaee9a3b1b73cdd3 OP_EQUALVERIFY OP_CHECKSIG

OP_DUP OP_HASH160 aefaa9d79e3c62c3f0cc909a3aee327e6cd0100a OP_EQUALVERIFY OP_CHECKSIG

The transaction that gave this wallet the coins that we are spending in this transaction is 6c002a15151a79d8163a03f4bc87b783a67bf0eeb18ff2b533e703317afdbbb1

Found at https://blockchain.info/tx/82d62d5f4e69ae8338c39b7ae2e1d33db59bdf62c869ded7344adc936bab8653

This previous transaction is made of the raw transaction:

0100000001e9cb57de3eac7ce6c703f8525c8c7cf87b064a18d7c830bc08901f776ef81e28010000006a4730440220090e1e73bfc2f37073f80f680893013fa40833e7a9dc7ed1667f728be72a75d302200d1b20fc0f3424f2a1e95f6f9c75a09260d2c889ff179e6dc1ec23423fd329bb012102bbe30b55f53ce14af3f0e58a854941de58d91ad21da1169c6103327f4cd17ff9feffffff028af81915000000001976a9146ffdc2e9e69434a7832208db5a6148c67563e8ae88ac18176c00000000001976a91454abba8c9ffd25c9cf7c232bc3f3998a9c1fe4f388aca1470700

The input script for this previous transaction is:

30440220090e1e73bfc2f37073f80f680893013fa40833e7a9dc7ed1667f728be72a75d302200d1b20fc0f3424f2a1e95f6f9c75a09260d2c889ff179e6dc1ec23423fd329bb01 02bbe30b55f53ce14af3f0e58a854941de58d91ad21da1169c6103327f4cd17ff9

The output script for this previous transaction are:

OP_DUP OP_HASH160 6ffdc2e9e69434a7832208db5a6148c67563e8ae OP_EQUALVERIFY OP_CHECKSIG

OP_DUP OP_HASH160 54abba8c9ffd25c9cf7c232bc3f3998a9c1fe4f3 OP_EQUALVERIFY OP_CHECKSIG

How and what would be the easiest path to determine the HashofThingtoSign in this transaction using the data supplied? (or do we need more data?)

The last step is obviously a sha-256 hashing of something. What would the full text of that something be for this transaction that could simply be pasted into something such as http://www.movable-type.co.uk/scripts/sha256.html to produce the HashofThingToSign for this transaction?

What is this transaction's actual hash supposed to be as a result of the explained process (so that one can check one's work)?

Can we even determine what the hashofthingtosign was on this transaction without the privatekey?

Is the "hashofthingtosign" used in the signature generation simply the whole raw transaction "0100000001b1bbfd...7e6cd0100a88acb2480700" hashed with SHA-256 twice, i.e. the same as the transaction ID? (1ecc3ee8e17966d90250cfe86a4b8e7b17a310bc18813a07b3c3e00b9c8b‌​21b8 for this transaction)?

It has been proposed that this question is a duplicate to the question and or seeking a duplicate answer from How does the ECDSA verification algorithm work during transaction? . I am reading it in an attempt to fully discern if that is the case. The difficulty in making sense thereof confirms it is NOT an answer I would accept as valid (as even the original person who asked that question commented they weren't sure of the answer being sufficiently clear such that they could understand it). I can confirm it has some of the information. At the very least, I can confirm, thus far, it appears to be missing the details of various steps (where pieces of data came from), uses terminologies that I cannot fully confirm their meaning as correlated with the answer I've received so far (it may be too advanced or casual terms used by someone with a very advanced understanding thereof). I'm trying to combine the information from that question, the "How to redeem a basic TX?", and the answer I've been given so far. This new answer might contain the missing pieces to the puzzle, but it is not the ultimate answer. If I can make sense of it and produce an answer, I will certainly provide that, but I am doubtful I will be successful as I still think there are too many missing pieces.

Answer 1

The steps to generate the message for signing are given in the accepted answer here: How to redeem a basic Tx? - specifically, step 1 to 14.

The transaction hash (txid) is not the same as the message to sign, because the hash is taken of the signed transaction including the scriptSig (which obviously can't sign itself), so we've got to make some small modifications to the transaction to get it into the format for signing

Let's get the raw transaction you gave in your question and break it down:

0100000001b1bbfd7a3103e733b5f28fb1eef07ba683b787bcf4033a16d8791a15152a006c000000006b483045022100d52330113ccd033ccb1aaa3b759e9696c216e802922e5f1902cd5ada69c612e5022057880205319dccb05eebbe34323a852ee82653f09f81253ddccd08a810e9d42d012103e5b9f0bb669b289efb8d2826487a24ef5f3985624c8bc3a3e34f6bd54e080b27feffffff027c8d3700000000001976a91443bd19b0436db26d24c789bebaee9a3b1b73cdd388acc1bbe114000000001976a914aefaa9d79e3c62c3f0cc909a3aee327e6cd0100a88acb2480700

You can obtain raw transaction data from blockchain using the rawtx keyword and add "format=hex": https://blockchain.info/rawtx/82d62d5f4e69ae8338c39b7ae2e1d33db59bdf62c869ded7344adc936bab8653?format=hex

Note that the following breakdown is a description of the data in that raw transaction, the only modifications needed are in bold. Steps 1 and 2 are the same, we have the 01000000 version and the 01 number of inputs. Step 3 uses:

b1bbfd7a3103e733b5f28fb1eef07ba683b787bcf4033a16d8791a15152a006c

Which is the hash 6c002a15151a79d8163a03f4bc87b783a67bf0eeb18ff2b533e703317afdbbb1 (notice that the bytes are in reverse order) of the previous transaction whose output you are spending (https://blockchain.info/tx-index/269874933/0).

Then we have output index 0 from that transaction, i.e. 00000000, for step 4. This can be seen by looking at the previous transaction we are spending and seeing the index of the output we are spending.

Now for step 5 and 6, the transaction above contains the scriptSig, beginning with 6b to denote that the scriptSig is 107 bytes long, and then the 107 byte sig itself, 483...27. Pieter Wuille's answer here: What are the parts of a Bitcoin Transaction "Input" script? is extremely good for explaining what the parts of the input script are. But for signing, bitcoin uses the scriptPubKey from the output being spent, so we have to replace that scriptSig (delete the scriptSig data from the transaction and insert instead) 19 to denote 25 bytes and then the 76a9146ffdc2e9e69434a7832208db5a6148c67563e8ae88ac scriptPubKey itself from the previous output, very similar to the bytes used in step 5 and 6 because both are P2PKH outputs. Again this scriptPubKey can be found by looking at the previous transaction we are spending.

In step 7, this transaction uses the bytes feffffff which is the hexadecimal number 0xfffffffe. This sequence number is used as per BIP 125, meaning that the transaction is not opting in to being replaceable, but still uses locktime.

Then we have 02 to say there are 2 outputs in this transaction:

1. The first spends 7c8d370000000000, i.e. 0x378d7c = 3640700 satoshis, has a 19 byte script, which is 76a91443bd19b0436db26d24c789bebaee9a3b1b73cdd388ac

2. The second spends c1bbe11400000000, i.e. 0x14e1bbc1 = 350337985 satoshis, also has a 19 byte script, which is 76a914aefaa9d79e3c62c3f0cc909a3aee327e6cd0100a88ac

Finally, we have the locktime of b2480700, i.e. 0x748b2 = block number 477362.

For signing we must then append 01000000 for SIGHASH_ALL to the end

This gives

0100000001b1bbfd7a3103e733b5f28fb1eef07ba683b787bcf4033a16d8791a15152a006c000000001976a9146ffdc2e9e69434a7832208db5a6148c67563e8ae88acfeffffff027c8d3700000000001976a91443bd19b0436db26d24c789bebaee9a3b1b73cdd388acc1bbe114000000001976a914aefaa9d79e3c62c3f0cc909a3aee327e6cd0100a88acb248070001000000

Which when hashed twice is 6823ba9770a496269a8f5368beec5ccb7b22ecd626265140be38aba1c8a25388 (note I haven't verified that this is correct yet, but it should be)