<p>There are quite a lot of things going on there, so let's break it down bit by bit. </p>

<p><strong>Transaction structure</strong></p>

<p>A transaction can be seen as a collection of inputs and outputs. Inputs refer to previously created UTXOs, while outputs generate new ones. Therefore, when creating a transaction each input spends a UTXO and each outputs creates one.</p>

<p><a href="https://i.sstatic.net/2cGGk.png" rel="noreferrer"><img src="https://i.sstatic.net/2cGGk.png" alt="enter image description here"></a></p>

<p><strong>Outputs structure</strong></p>

<p>Outputs is what contains the so called locking script, or how it is normally referred in a transaction, the <code>scriptPubKey</code>. Such an script contains the condition required to spend such a UTXO.</p>

<p><strong>Inputs structure</strong></p>

<p>Inputs contain references to previously created UTXOs (through the <code>prev_tx_id</code> and <code>prev_out_index</code> fields). Moreover, inputs contain the so called unlocking scripts, or how they are normally referred, <code>scriptSig</code>. Such scripts require the proof of fulfilment of the conditions specified in the UTXO each input is trying to redeem.</p>

<p><strong>Examples</strong></p>

<p>The most commonly used transactions in Bitcoin, and therefore the most common example of this, are <strong>Pay-to-PubKey-Hash (P2PKH)</strong> transactions, or transactions that pay to a Bitcoin address. A script "paying to a Bitcoin address" will require that you can proof to be the "owner" of such an address. Let's see how this works:</p>

<p><em>P2PKH transaction</em></p>

<p>A transaction creating a P2PKH UTXO will have a <code>scriptPubKey</code> looking as follows:</p>

<p><code>ScriptPubKey = OP_DUP OP_HASH160 &lt;hash160(pubKey)&gt; OP_EQUAL OP_CHECKSIG</code></p>

<p>Whereas a transaction tying to redeem such an UTXO as an input, will have a <code>scriptSig</code> looking as follows:</p>

<p><code>ScriptSig = &lt;sig&gt; &lt;pubKey&gt;</code></p>

<p>If we put both scripts together in a stack, like Bitcoin does, what we get is the following script:</p>

<p><code>&lt;sig&gt; &lt;pubKey&gt; OP_DUP OP_HASH160 &lt;hash160(pubKey)&gt; OP_EQUAL OP_CHECKSIG</code></p>

<p>In order to analyze the script you should have two things in mind. There are two types of clauses, opcodes and data (represented between <code>&lt; &gt;</code>). Moreover, scripts are read left to right, and data is used as input to opcodes. </p>

<p>The execution of the script will first duplicate the public key (since is the first operation of the script), and compute the <code>hash160</code> of it. Then it will check if the computed hash160 matches with the one provided in the UTXO the input is trying to redeem, and finally it will use the remaining public key (recall that we have duplicated it) and the signature to check the correctness of the signature.</p>

<p>You can find more info about the validation of P2PKH in the <a href="https://bitcoin.org/en/developer-guide#p2pkh-script-validation" rel="noreferrer">Bitcoin dev guide</a>. Moreover, there are several other examples of this. You can find the standard types of transactions also in the <a href="https://bitcoin.org/en/developer-guide#standard-transactions" rel="noreferrer">dev guide</a>. An extensive list of Bitcoin Script opcodes can be found in the <a href="https://en.bitcoin.it/wiki/Script" rel="noreferrer">Bitcoin wiki</a>.</p>

CC BY-SA 4.0
2018-05-15T08:48:31.633Z
2018-11-13T09:15:56.997Z
2018-11-13T09:15:56.997Z
sr_gi
<p>There isn't a difference between a 'locking script' and an 'unlocking script'. A script is simply a set of instructions that specifies how a UTXO is able to be spent, this locks or encumbers (to use the official terminology) the future spending of the bitcoin. Unlocking the bitcoin requires satisfying the script. </p>

<p>The simplest transaction contains a script which asks for </p>

<ol>
<li>a public key that, when hashed, yields destination address D
embedded in the script, and </li>
<li>a signature to prove ownership of the
private key corresponding to the public key just provided.</li>
</ol>

<p>You can encumber a UTXO with more complex requirements such using the OPCODE 'OP_CHECKLOCKTIMEVERIFY' which doesn't allow the bitcoin to be spent until a point in the future. </p>

<p>You can read more about Script here:</p>

<p><a href="https://en.bitcoin.it/wiki/Script" rel="nofollow noreferrer">https://en.bitcoin.it/wiki/Script</a></p>

CC BY-SA 4.0
2018-05-15T06:05:43.913Z
2018-05-15T06:05:43.913Z
timothyylim
<p>The locking script on an UTXO and the unlocking script are written in bitcoin scripting language. When a transaction is validated, the unlocking script in each input is executed alongside the corresponding locking script to see if it satisfies the spending condition.
Can someone explain the nitty gritty of Bitcoin script with locking and unlocking script?</p>

CC BY-SA 4.0
2018-05-15T06:06:37.517Z
Wasn't completely sure what you wanted to know as there is a lot of information regarding Script. I've added a preliminary answer and a link to the official documentation. Hope that helps!
timothyylim
CC BY-SA 4.0
2018-05-15T08:53:59.030Z
Same here, not completely sure so I've tried to make it as complete as possible.
sr_gi
<script><transaction-input>
What is Bitcoin locking and unlocking script?
user2203937
# What is Bitcoin locking and unlocking script?

(Asked by: username_0 on 2018-05-15)

The locking script on an UTXO and the unlocking script are written in bitcoin scripting language. When a transaction is validated, the unlocking script in each input is executed alongside the corresponding locking script to see if it satisfies the spending condition.
Can someone explain the nitty gritty of Bitcoin script with locking and unlocking script?

**Tags:** script, transaction-input

> **Comments:**
> **username_1**: Wasn't completely sure what you wanted to know as there is a lot of information regarding Script. I've added a preliminary answer and a link to the official documentation. Hope that helps!  
> **username_2**: Same here, not completely sure so I've tried to make it as complete as possible.  

---

## 2 answers

### Answer by username_2 on 2018-05-15. Score: 15

There are quite a lot of things going on there, so let's break it down bit by bit.

**Transaction structure**

A transaction can be seen as a collection of inputs and outputs. Inputs refer to previously created UTXOs, while outputs generate new ones. Therefore, when creating a transaction each input spends a UTXO and each outputs creates one.

[![enter image description here](https://i.sstatic.net/2cGGk.png)](https://i.sstatic.net/2cGGk.png)

**Outputs structure**

Outputs is what contains the so called locking script, or how it is normally referred in a transaction, the `scriptPubKey`. Such an script contains the condition required to spend such a UTXO.

**Inputs structure**

Inputs contain references to previously created UTXOs (through the `prev_tx_id` and `prev_out_index` fields). Moreover, inputs contain the so called unlocking scripts, or how they are normally referred, `scriptSig`. Such scripts require the proof of fulfilment of the conditions specified in the UTXO each input is trying to redeem.

**Examples**

The most commonly used transactions in Bitcoin, and therefore the most common example of this, are **Pay-to-PubKey-Hash (P2PKH)** transactions, or transactions that pay to a Bitcoin address. A script "paying to a Bitcoin address" will require that you can proof to be the "owner" of such an address. Let's see how this works:

*P2PKH transaction*

A transaction creating a P2PKH UTXO will have a `scriptPubKey` looking as follows:

`ScriptPubKey = OP_DUP OP_HASH160 <hash160(pubKey)> OP_EQUAL OP_CHECKSIG`

Whereas a transaction tying to redeem such an UTXO as an input, will have a `scriptSig` looking as follows:

`ScriptSig = <sig> <pubKey>`

If we put both scripts together in a stack, like Bitcoin does, what we get is the following script:

`<sig> <pubKey> OP_DUP OP_HASH160 <hash160(pubKey)> OP_EQUAL OP_CHECKSIG`

In order to analyze the script you should have two things in mind. There are two types of clauses, opcodes and data (represented between `< >`). Moreover, scripts are read left to right, and data is used as input to opcodes.

The execution of the script will first duplicate the public key (since is the first operation of the script), and compute the `hash160` of it. Then it will check if the computed hash160 matches with the one provided in the UTXO the input is trying to redeem, and finally it will use the remaining public key (recall that we have duplicated it) and the signature to check the correctness of the signature.

You can find more info about the validation of P2PKH in the [Bitcoin dev guide](https://bitcoin.org/en/developer-guide#p2pkh-script-validation). Moreover, there are several other examples of this. You can find the standard types of transactions also in the [dev guide](https://bitcoin.org/en/developer-guide#standard-transactions). An extensive list of Bitcoin Script opcodes can be found in the [Bitcoin wiki](https://en.bitcoin.it/wiki/Script).


---

### Answer by username_1 on 2018-05-15. Score: 3

There isn't a difference between a 'locking script' and an 'unlocking script'. A script is simply a set of instructions that specifies how a UTXO is able to be spent, this locks or encumbers (to use the official terminology) the future spending of the bitcoin. Unlocking the bitcoin requires satisfying the script.

The simplest transaction contains a script which asks for

1. a public key that, when hashed, yields destination address D
   embedded in the script, and
2. a signature to prove ownership of the
   private key corresponding to the public key just provided.

You can encumber a UTXO with more complex requirements such using the OPCODE 'OP\_CHECKLOCKTIMEVERIFY' which doesn't allow the bitcoin to be spent until a point in the future.

You can read more about Script here:

<https://en.bitcoin.it/wiki/Script>


---

