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:
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
[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.