<p>The steps to generate the message for signing are given in the accepted answer here:
<a href="https://bitcoin.stackexchange.com/questions/3374/how-to-redeem-a-basic-tx">How to redeem a basic Tx?</a> -
 specifically, step 1 to 14. </p>

<p>The transaction hash (txid) is not the same as the message to sign, because the hash is taken of the <strong>signed</strong> 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</p>

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

<blockquote>
  <p>0100000001b1bbfd7a3103e733b5f28fb1eef07ba683b787bcf4033a16d8791a15152a006c000000006b483045022100d52330113ccd033ccb1aaa3b759e9696c216e802922e5f1902cd5ada69c612e5022057880205319dccb05eebbe34323a852ee82653f09f81253ddccd08a810e9d42d012103e5b9f0bb669b289efb8d2826487a24ef5f3985624c8bc3a3e34f6bd54e080b27feffffff027c8d3700000000001976a91443bd19b0436db26d24c789bebaee9a3b1b73cdd388acc1bbe114000000001976a914aefaa9d79e3c62c3f0cc909a3aee327e6cd0100a88acb2480700</p>
</blockquote>

<p>You can obtain raw transaction data from blockchain using the rawtx keyword and add "format=hex": <a href="https://blockchain.info/rawtx/82d62d5f4e69ae8338c39b7ae2e1d33db59bdf62c869ded7344adc936bab8653?format=hex" rel="nofollow noreferrer">https://blockchain.info/rawtx/82d62d5f4e69ae8338c39b7ae2e1d33db59bdf62c869ded7344adc936bab8653?format=hex</a></p>

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

<blockquote>
  <p>b1bbfd7a3103e733b5f28fb1eef07ba683b787bcf4033a16d8791a15152a006c</p>
</blockquote>

<p>Which is the hash <code>6c002a15151a79d8163a03f4bc87b783a67bf0eeb18ff2b533e703317afdbbb1</code> (notice that the bytes are in reverse order) of the previous transaction whose output you are spending (<a href="https://blockchain.info/tx-index/269874933/0" rel="nofollow noreferrer">https://blockchain.info/tx-index/269874933/0</a>).</p>

<p>Then we have output index 0 from that transaction, i.e. <code>00000000</code>, 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.</p>

<p>Now for step 5 and 6, the transaction above contains the scriptSig, beginning with <code>6b</code> to denote that the scriptSig is 107 bytes long, and then the 107 byte sig itself, <code>483...27</code>. Pieter Wuille's answer here:  <a href="https://bitcoin.stackexchange.com/questions/57644/what-are-the-parts-of-a-bitcoin-transaction-input-script">What are the parts of a Bitcoin Transaction &quot;Input&quot; script?</a> 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, <strong>so we have to replace that scriptSig</strong> (delete the scriptSig data from the transaction and insert instead) <code>19</code> to denote 25 bytes and then the <code>76a9146ffdc2e9e69434a7832208db5a6148c67563e8ae88ac</code> 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.</p>

<p>In step 7, this transaction uses the bytes <code>feffffff</code> which is the hexadecimal number 0xfffffffe. This sequence number is used as per <a href="https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki" rel="nofollow noreferrer">BIP 125</a>, meaning that the transaction is not opting in to being replaceable, but still uses locktime.</p>

<p>Then we have <code>02</code> to say there are 2 outputs in this transaction:</p>

<ol>
<li><p>The first spends <code>7c8d370000000000</code>, i.e. 0x378d7c = 3640700 satoshis, has a <code>19</code> byte script, which is <code>76a91443bd19b0436db26d24c789bebaee9a3b1b73cdd388ac</code></p></li>
<li><p>The second spends <code>c1bbe11400000000</code>, i.e. 0x14e1bbc1 = 350337985 satoshis, also has a <code>19</code> byte script, which is <code>76a914aefaa9d79e3c62c3f0cc909a3aee327e6cd0100a88ac</code></p></li>
</ol>

<p>Finally, we have the locktime of <code>b2480700</code>, i.e. 0x748b2 = block number 477362.</p>

<p>For signing we must then <strong>append</strong> <code>01000000</code> for SIGHASH_ALL to the end</p>

<p>This gives</p>

<blockquote>
  <p>0100000001b1bbfd7a3103e733b5f28fb1eef07ba683b787bcf4033a16d8791a15152a006c000000001976a9146ffdc2e9e69434a7832208db5a6148c67563e8ae88acfeffffff027c8d3700000000001976a91443bd19b0436db26d24c789bebaee9a3b1b73cdd388acc1bbe114000000001976a914aefaa9d79e3c62c3f0cc909a3aee327e6cd0100a88acb248070001000000</p>
</blockquote>

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

CC BY-SA 3.0
2017-08-07T02:41:13.340Z
Comments are not for extended discussion; this conversation has been [moved to chat](http://chat.stackexchange.com/rooms/63416/discussion-on-answer-by-meshcollider-how-would-one-go-about-acquiring-the-hashof).
Nick ODell
CC BY-SA 3.0
2017-08-06T04:21:16.453Z
2017-08-07T22:50:42.937Z
2017-08-07T22:50:42.937Z
meshcollider
<p>How would one go about acquiring the HashofThingToSign that is used in the &quot;Signature Generation&quot; equation for this example transaction such that it could easily also be applied to any other given pre-existing transaction?</p>
<p>Example Transaction: 82d62d5f4e69ae8338c39b7ae2e1d33db59bdf62c869ded7344adc936bab8653</p>
<p>Found at: <a href="https://blockchain.info/tx/82d62d5f4e69ae8338c39b7ae2e1d33db59bdf62c869ded7344adc936bab8653" rel="nofollow noreferrer">https://blockchain.info/tx/82d62d5f4e69ae8338c39b7ae2e1d33db59bdf62c869ded7344adc936bab8653</a></p>
<p>This is made of the Raw Transaction:</p>
<blockquote>
<p>0100000001b1bbfd7a3103e733b5f28fb1eef07ba683b787bcf4033a16d8791a15152a006c000000006b483045022100d52330113ccd033ccb1aaa3b759e9696c216e802922e5f1902cd5ada69c612e5022057880205319dccb05eebbe34323a852ee82653f09f81253ddccd08a810e9d42d012103e5b9f0bb669b289efb8d2826487a24ef5f3985624c8bc3a3e34f6bd54e080b27feffffff027c8d3700000000001976a91443bd19b0436db26d24c789bebaee9a3b1b73cdd388acc1bbe114000000001976a914aefaa9d79e3c62c3f0cc909a3aee327e6cd0100a88acb2480700</p>
</blockquote>
<p>The input script is:</p>
<blockquote>
<p>3045022100d52330113ccd033ccb1aaa3b759e9696c216e802922e5f1902cd5ada69c612e5022057880205319dccb05eebbe34323a852ee82653f09f81253ddccd08a810e9d42d01 03e5b9f0bb669b289efb8d2826487a24ef5f3985624c8bc3a3e34f6bd54e080b27</p>
</blockquote>
<p>The Output scripts are:</p>
<blockquote>
<p>OP_DUP OP_HASH160 43bd19b0436db26d24c789bebaee9a3b1b73cdd3 OP_EQUALVERIFY OP_CHECKSIG</p>
<p>OP_DUP OP_HASH160 aefaa9d79e3c62c3f0cc909a3aee327e6cd0100a OP_EQUALVERIFY OP_CHECKSIG</p>
</blockquote>
<p>The transaction that gave this wallet the coins that we are spending in this transaction is 6c002a15151a79d8163a03f4bc87b783a67bf0eeb18ff2b533e703317afdbbb1</p>
<p>Found at <a href="https://blockchain.info/tx/82d62d5f4e69ae8338c39b7ae2e1d33db59bdf62c869ded7344adc936bab8653" rel="nofollow noreferrer">https://blockchain.info/tx/82d62d5f4e69ae8338c39b7ae2e1d33db59bdf62c869ded7344adc936bab8653</a></p>
<p>This previous transaction is made of the raw transaction:</p>
<blockquote>
<p>0100000001e9cb57de3eac7ce6c703f8525c8c7cf87b064a18d7c830bc08901f776ef81e28010000006a4730440220090e1e73bfc2f37073f80f680893013fa40833e7a9dc7ed1667f728be72a75d302200d1b20fc0f3424f2a1e95f6f9c75a09260d2c889ff179e6dc1ec23423fd329bb012102bbe30b55f53ce14af3f0e58a854941de58d91ad21da1169c6103327f4cd17ff9feffffff028af81915000000001976a9146ffdc2e9e69434a7832208db5a6148c67563e8ae88ac18176c00000000001976a91454abba8c9ffd25c9cf7c232bc3f3998a9c1fe4f388aca1470700</p>
</blockquote>
<p>The input script for this previous transaction is:</p>
<blockquote>
<p>30440220090e1e73bfc2f37073f80f680893013fa40833e7a9dc7ed1667f728be72a75d302200d1b20fc0f3424f2a1e95f6f9c75a09260d2c889ff179e6dc1ec23423fd329bb01 02bbe30b55f53ce14af3f0e58a854941de58d91ad21da1169c6103327f4cd17ff9</p>
</blockquote>
<p>The output script for this previous transaction are:</p>
<blockquote>
<p>OP_DUP OP_HASH160 6ffdc2e9e69434a7832208db5a6148c67563e8ae OP_EQUALVERIFY OP_CHECKSIG</p>
<p>OP_DUP OP_HASH160 54abba8c9ffd25c9cf7c232bc3f3998a9c1fe4f3 OP_EQUALVERIFY OP_CHECKSIG</p>
</blockquote>
<p>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?)</p>
<p>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 <a href="http://www.movable-type.co.uk/scripts/sha256.html" rel="nofollow noreferrer">http://www.movable-type.co.uk/scripts/sha256.html</a> to produce the HashofThingToSign for this transaction?</p>
<p>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)?</p>
<p>Can we even determine what the hashofthingtosign was on this transaction without the privatekey?</p>
<p>Is the &quot;hashofthingtosign&quot; used in the signature generation simply the whole raw transaction &quot;0100000001b1bbfd...7e6cd0100a88acb2480700&quot; hashed with SHA-256 twice, i.e. the same as the transaction ID?
(<code>1ecc3ee8e17966d90250cfe86a4b8e7b17a310bc18813a07b3c3e00b9c8b‌​21b8</code> for this transaction)?</p>
<p>It has been proposed that this question is a duplicate to the question and or seeking a duplicate answer from <a href="https://bitcoin.stackexchange.com/questions/32305/how-does-the-ecdsa-verification-algorithm-work-during-transaction">How does the ECDSA verification algorithm work during transaction?</a> . 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 &quot;How to redeem a basic TX?&quot;, 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.</p>

CC BY-SA 3.0
2017-08-07T20:17:53.720Z
Possible duplicate of [How does the ECDSA verification algorithm work during transaction?](https://bitcoin.stackexchange.com/questions/32305/how-does-the-ecdsa-verification-algorithm-work-during-transaction)
meshcollider
<transactions><security><script><hash><signature>
How would one go about acquiring the HashofThingtoSign from this old transaction?
Mine
# How would one go about acquiring the HashofThingtoSign from this old transaction?

(Asked by: username_0 on 2017-08-06)

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?](https://bitcoin.stackexchange.com/questions/32305/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.

**Tags:** transactions, security, script, hash, signature

> **Comments:**
> **username_1**: Possible duplicate of [How does the ECDSA verification algorithm work during transaction?](https://bitcoin.stackexchange.com/questions/32305/how-does-the-ecdsa-verification-algorithm-work-during-transaction)  

---

## 1 answers

### Answer by username_1 on 2017-08-06. Score: 2 | Accepted answer

The steps to generate the message for signing are given in the accepted answer here:
[How to redeem a basic Tx?](https://bitcoin.stackexchange.com/questions/3374/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?](https://bitcoin.stackexchange.com/questions/57644/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](https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki), 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)

> **Comments:**
> **username_2**: Comments are not for extended discussion; this conversation has been [moved to chat](http://chat.stackexchange.com/rooms/63416/discussion-on-answer-by-username_1-how-would-one-go-about-acquiring-the-hashof).  

---

