<p>Transaction verification requires the previous transaction outputs that the transaction spends from. The output script of the previous transaction outputs is retrieved for each input. The input script is first run through the script interpreter. It's resulting stack is then used as an initial state for the previous transaction output's output script's pass through the script interpreter.</p>

<p>For the particular transaction that you have chosen, then previous transaction output script is of the form</p>

<pre><code>&lt;pubkey&gt; OP_CHECKSIG
</code></pre>

<p>and the input is of the form</p>

<pre><code>&lt;sig&gt;
</code></pre>

<p>This means that the signature is first pushed to the stack. Then the public key is pushed to the stack and then <code>OP_CHECKSIG</code> is performed on the two stack items. The public key resides in the output script. For other output types, the public key is provided in the input script as part of the spend.</p>

<p>The hash that is signed as the message is produced from the spending transaction itself. It contains data that is provided in the spending transaction and the previous transaction output script so it can be generated on-the-fly. You can check out this question and answer <a href="https://bitcoin.stackexchange.com/questions/57848/how-to-tell-which-part-of-the-previous-tx-i-need-to-make-the-hash-to-sign-for-an/57866#57866">How to tell which part of the previous tx I need to make the hash to sign for an old given tx?</a> which breaks down how that hash is generated for non-segwit inputs.</p>

CC BY-SA 3.0
2017-09-28T00:57:12.673Z
as I understand from your answer, the unsigned transaction generates on-the-fly and then makes double sha256 Hash for Sig checking?
Denis Leonov
CC BY-SA 3.0
2017-09-28T00:58:19.127Z
Yes. The sighash preimage is created (modified version of the unsigned transaction) and that is hashed with SHA256d. That hash is either signed or verified, depending on what you want to do.
Ava Chow
CC BY-SA 3.0
2017-09-28T00:23:29.017Z
2017-09-28T00:23:29.017Z
Ava Chow
<p>Please help me to understand how bitcoind client verifying TX with Input Script which consist only from the Sig.</p>

<p>For example TX <code>6D5DF6C0D66CFFC25CC1ABA3655952D7B081ED4E9EA3B70FCD964FDBBA01E91E</code> has one input from <code>D9A9C88110775B196CDAF6FC8113B33547C8E33E68519F60D9C9FF306E096473</code> transaction (8 output) with Input Script <code>4730440220797681C6711BB3D97AE373FC5CFF47F06EEC928DD46B8A9892D92C30953C9DF3022079C36E9A4C32D4E36B9E3ACCED0D40D70D8F90890C0E9F8F4F9AC083AFFD21B301</code>.</p>

<p>This script has only the Sig (r,s) and has no any representation of Public Key or Address.</p>

<p>As I understand the <code>Sig</code> creates with <code>UnsignedTX doubleSHA256 hash</code>, <code>Random Number</code> and <code>Private Key</code>.</p>

<p><code>Sig</code> checking by using <code>UnsignedTX doubleSHA256 hash</code> and a <code>Public Key</code>, but here is no any of it.</p>

<p>Also the question is about "Where is stored <code>UnsignedTX doubleSHA256 hash</code>?". Because it is not the transaction hash, because TX hash is for the signed transaction.</p>

<transactions><bitcoin-core><bitcoin-core-development><signature>
How transaction becomes confirmed by miners if InputScript has only the Sig
Denis Leonov
# How transaction becomes confirmed by miners if InputScript has only the Sig

(Asked by: username_0 on 2017-09-28)

Please help me to understand how bitcoind client verifying TX with Input Script which consist only from the Sig.

For example TX `6D5DF6C0D66CFFC25CC1ABA3655952D7B081ED4E9EA3B70FCD964FDBBA01E91E` has one input from `D9A9C88110775B196CDAF6FC8113B33547C8E33E68519F60D9C9FF306E096473` transaction (8 output) with Input Script `4730440220797681C6711BB3D97AE373FC5CFF47F06EEC928DD46B8A9892D92C30953C9DF3022079C36E9A4C32D4E36B9E3ACCED0D40D70D8F90890C0E9F8F4F9AC083AFFD21B301`.

This script has only the Sig (r,s) and has no any representation of Public Key or Address.

As I understand the `Sig` creates with `UnsignedTX doubleSHA256 hash`, `Random Number` and `Private Key`.

`Sig` checking by using `UnsignedTX doubleSHA256 hash` and a `Public Key`, but here is no any of it.

Also the question is about "Where is stored `UnsignedTX doubleSHA256 hash`?". Because it is not the transaction hash, because TX hash is for the signed transaction.

**Tags:** transactions, bitcoin-core, bitcoin-core-development, signature


---

## 1 answers

### Answer by username_1 on 2017-09-28. Score: 2 | Accepted answer

Transaction verification requires the previous transaction outputs that the transaction spends from. The output script of the previous transaction outputs is retrieved for each input. The input script is first run through the script interpreter. It's resulting stack is then used as an initial state for the previous transaction output's output script's pass through the script interpreter.

For the particular transaction that you have chosen, then previous transaction output script is of the form

```
<pubkey> OP_CHECKSIG

```

and the input is of the form

```
<sig>

```

This means that the signature is first pushed to the stack. Then the public key is pushed to the stack and then `OP_CHECKSIG` is performed on the two stack items. The public key resides in the output script. For other output types, the public key is provided in the input script as part of the spend.

The hash that is signed as the message is produced from the spending transaction itself. It contains data that is provided in the spending transaction and the previous transaction output script so it can be generated on-the-fly. You can check out this question and answer [How to tell which part of the previous tx I need to make the hash to sign for an old given tx?](https://bitcoin.stackexchange.com/questions/57848/how-to-tell-which-part-of-the-previous-tx-i-need-to-make-the-hash-to-sign-for-an/57866#57866) which breaks down how that hash is generated for non-segwit inputs.

> **Comments:**
> **username_0**: as I understand from your answer, the unsigned transaction generates on-the-fly and then makes double sha256 Hash for Sig checking?  
> **username_1**: Yes. The sighash preimage is created (modified version of the unsigned transaction) and that is hashed with SHA256d. That hash is either signed or verified, depending on what you want to do.  

---

