<p>To be clear, what you list is both the locking and unlocking script:</p>
<ul>
<li>The locking script: <code>DUP HASH160 &lt;recipient address&gt; EQUALVERIFY CHECKSIG</code></li>
<li>The unlocking script: <code>&lt;signature&gt; &lt;pubkey&gt;</code></li>
</ul>
<p>The locking script (<code>scriptPubKey</code>) is part of the transaction where the sender S pays the recipient R. The unlocking script is part of any transaction where R uses their received money to send it further to a destination D.</p>
<p>So to be clear, in the example I'm describing there are two transactions: one from S to R, and later one from R to D.</p>
<ul>
<li>In the first step, R gives their address to S. S constructs a transaction with some of their own inputs, along with an output to R, in the form of the locking script above.</li>
<li>In the second step, D gives their address to R. R constructs a transaction with as input the funds sent by S and the unlocking script above to authorize spending it, and an output which has a locking script based on D's address.</li>
</ul>
<p>That R-&gt;D transaction (the one with <code>&lt;signature&gt; &lt;pubkey&gt;</code> in) undergoes the following steps:</p>
<ul>
<li>It is created by R's wallet which likely does some basic safety check on it</li>
<li>It is sent out by R's wallet, and then relayed further to other nodes. If those are full nodes, they will validate the script, by executing the <code>scriptSig</code>, yielding <code>[sig pubkey]</code>, and feeding that as input to the previous transaction's <code>scriptPubKey</code> (which will, if the signature and public key are valid, evaluate to true). If this evaluation returns failure, the transaction is ignored. Not all nodes are full nodes, and some may skip the full checking.</li>
<li>At some point the transaction reaches its destination D, which is a node like any other, and may or may not do full validation on it, depending on the software used.</li>
<li>At some point the transaction reaches one or more miners, who will hopefully include it in their next attempt to construct a block. Miners ought to perform full validation on the transaction, because if they don't, and include the transaction in a block despite being invalid, then that entire block will be invalid, and ignored by the network's full nodes.</li>
</ul>

CC BY-SA 4.0
2022-07-01T12:47:57.023Z
2022-07-01T12:47:57.023Z
Pieter Wuille
<blockquote>
<p>Does a node such as a mining node push this data into the stack and verify it using the opcodes or is it the wallet software?</p>
</blockquote>
<p>The wallet will construct a transaction that provides the unlocking script and transfers to the new locking condition. Then this transaction will be propagated to the rest of the network typically by the full node associated with that wallet. When other nodes receive this transaction they verify that the unlocking script meets the conditions needed to transfer those Bitcoin (and it is a valid transaction). If it does they accept into their mempool. Miners should also verify that the transaction is valid before considering whether to include that transaction in a block that they are attempting to mine.</p>

CC BY-SA 4.0
2022-07-01T12:35:10.883Z
2022-07-01T12:35:10.883Z
Michael Folkson
<p>I am familiar with the many ways an unlocking script is created. But in this scenario, lets use P2PKH. When we generate the unlocking script (excuse the simplicity):</p>
<pre><code>&lt;dup&gt; &lt;hash160&gt; &lt;wallet address&gt; &lt;equalverify&gt; &lt;checksig&gt; |&lt;signature&gt; &lt;Public Key&gt;
</code></pre>
<p><strong>Does a node such as a mining node push this data into the stack and verify it using the opcodes or is it the wallet software?</strong></p>

<wallet><mining-theory><nodes><transaction-verification><p2pkh>
When The Unlocking Script Is Created, Who Verifies The Script?
Jamo
# When The Unlocking Script Is Created, Who Verifies The Script?

(Asked by: username_0 on 2022-07-01)

I am familiar with the many ways an unlocking script is created. But in this scenario, lets use P2PKH. When we generate the unlocking script (excuse the simplicity):

```
<dup> <hash160> <wallet address> <equalverify> <checksig> |<signature> <Public Key>

```

**Does a node such as a mining node push this data into the stack and verify it using the opcodes or is it the wallet software?**

**Tags:** wallet, mining-theory, nodes, transaction-verification, p2pkh


---

## 2 answers

### Answer by username_1 on 2022-07-01. Score: 3 | Accepted answer

To be clear, what you list is both the locking and unlocking script:

* The locking script: `DUP HASH160 <recipient address> EQUALVERIFY CHECKSIG`
* The unlocking script: `<signature> <pubkey>`

The locking script (`scriptPubKey`) is part of the transaction where the sender S pays the recipient R. The unlocking script is part of any transaction where R uses their received money to send it further to a destination D.

So to be clear, in the example I'm describing there are two transactions: one from S to R, and later one from R to D.

* In the first step, R gives their address to S. S constructs a transaction with some of their own inputs, along with an output to R, in the form of the locking script above.
* In the second step, D gives their address to R. R constructs a transaction with as input the funds sent by S and the unlocking script above to authorize spending it, and an output which has a locking script based on D's address.

That R->D transaction (the one with `<signature> <pubkey>` in) undergoes the following steps:

* It is created by R's wallet which likely does some basic safety check on it
* It is sent out by R's wallet, and then relayed further to other nodes. If those are full nodes, they will validate the script, by executing the `scriptSig`, yielding `[sig pubkey]`, and feeding that as input to the previous transaction's `scriptPubKey` (which will, if the signature and public key are valid, evaluate to true). If this evaluation returns failure, the transaction is ignored. Not all nodes are full nodes, and some may skip the full checking.
* At some point the transaction reaches its destination D, which is a node like any other, and may or may not do full validation on it, depending on the software used.
* At some point the transaction reaches one or more miners, who will hopefully include it in their next attempt to construct a block. Miners ought to perform full validation on the transaction, because if they don't, and include the transaction in a block despite being invalid, then that entire block will be invalid, and ignored by the network's full nodes.


---

### Answer by username_2 on 2022-07-01. Score: 1

> Does a node such as a mining node push this data into the stack and verify it using the opcodes or is it the wallet software?

The wallet will construct a transaction that provides the unlocking script and transfers to the new locking condition. Then this transaction will be propagated to the rest of the network typically by the full node associated with that wallet. When other nodes receive this transaction they verify that the unlocking script meets the conditions needed to transfer those Bitcoin (and it is a valid transaction). If it does they accept into their mempool. Miners should also verify that the transaction is valid before considering whether to include that transaction in a block that they are attempting to mine.


---

