<p>There is a nice <a href="https://en.bitcoin.it/wiki/Script" rel="nofollow noreferrer">introduction to script</a> and already another answer explaining what these <em>specific commands</em> do, but I will try to explain what these <em>scripts</em> actually do.</p>

<p>They implement a very standard bitcoin transaction called <em>pay-to-pubkey-hash transaction</em>.</p>

<p>The idea is roughly the following. Let's call this transaction <code>A</code>. To spend the output of transaction <code>A</code>, another transaction will be created and broadcasted, let's call it <code>B</code>. In order to verify the validity of transaction <code>B</code>, one should:</p>

<ol>
<li>combine the input script of <code>B</code> with the output script of <code>A</code>,</li>
<li>execute the combined script and verify that it returns <code>True</code>.</li>
</ol>

<p>In this type of transactions, transaction <code>B</code> should provide an input script that puts two elements to the stack: the signature <code>sig</code> of the transaction and a corresponding public key <code>pubKey</code>. Note how the input script of transaction <code>A</code> is also doing exactly that.</p>

<p>Then the output script of transaction <code>A</code> will do the following (in your question you actually provide two output scripts merged together, because there are two outputs, I will focus on the first one):</p>

<ol>
<li>Duplicate <code>pubKey</code> on the stack;</li>
<li>Hash one <code>pubKey</code> from the stack and verify that it is equal to <code>264cf7a09b68a436bafc4d7281743d7f1c721ded</code></li>
<li>Take <code>sig</code> and the  remaining <code>pubKey</code> from the stack and verify the validity of the signature.</li>
</ol>

CC BY-SA 4.0
2019-03-14T19:59:38.823Z
1st thank you. 2nd I think i understand what your saying. So basically for the balance to be spendable, another transaction has to take place to verify it spendable?
gReigns
CC BY-SA 4.0
2019-03-16T10:14:15.893Z
@gReigns roughly, yes, depending on what you mean by “spendable”. Transaction A dictates the conditions under which the balance (or rather UTXO is a better term) can be spend. But until transaction B appears and spends these outputs by providing the right signature, no one really knows if these conditions are possible to meet.
Dmitry Laptev
CC BY-SA 4.0
2019-03-12T21:57:21.797Z
2019-03-12T21:57:21.797Z
Dmitry Laptev
<ul>
<li>PUSHDATA(71): Pushes the next 71 bytes onto the top of stack</li>
<li>PUSHDATA(33): Pushes the next 33 bytes onto the top of stack</li>
<li>DUP: Pushes a duplicate of the top stack item onto the top of the stack</li>
<li>HASH160: Pop the top stack item off of the stack, hash it using SHA256 then that hash with RIPEMD160, and push the resulting hash to the top of the stack</li>
<li>PUSHDATA(20): Push the next 20 bytes onto the top of the stack</li>
<li>EQUALVERIFY: Check that the top two stack items are equal. If they are, do nothing. If they are not, immediately fail execution</li>
<li>CHECKSIG:Pop the top stack item and interpret it as a public key. Pop the next stack item and interpret it as a signature. Check that the signature verifies to that public key when the message that is signed is a modified version of the transaction containing the signature. If the signature is valid, push OP_TRUE to the top of the stack. If it is false, push OP_FALSE to the top of the stack.</li>
</ul>

<p>A full description of all script opcodes and their actual byte values can be found <a href="https://en.bitcoin.it/wiki/Script" rel="nofollow noreferrer">on the Bitcoin wiki</a>.</p>

CC BY-SA 4.0
2019-03-12T21:50:05.537Z
Can't believe that this was not a duplicate. I will add a link to a video in which I dissect a pay2pkh tx: https://youtu.be/1n4g3eYX1UI that should help to understand how these op codes work
Rene Pickhardt
CC BY-SA 4.0
2019-03-12T21:32:05.557Z
2019-03-12T21:32:05.557Z
Ava Chow
<p>Could someone explain what the commands i have in <strong>bold</strong> do? if possible. Thank you.</p>

<p><a href="https://www.blockchain.com/btc/tx/d5660360c401e17e5f0f0fbcabc3c369002bf2a58a6eaeaf1d8242dd01da3f72" rel="nofollow noreferrer">Transaction URL www.blockchain.com/btc/tx
</a></p>

<p>Input Scripts-
ScriptSig: <strong>PUSHDATA(71)</strong>[3044022069f0c9da12ce7b002c68d25e4445191b149627987367fdec4e4b80e442379f3902202109994c46d8c6afd8e94542d07fa8a07da234f7537c4a1d639d2dcdd32f9c5b01] <strong>PUSHDATA(33)</strong>[03c26e5ff8c75d6272b2d9cd3a882c20315d440251deb79873b75b690d0b71f4cf]</p>

<p>Output Scripts-
<strong>DUP HASH160 PUSHDATA</strong>(20)[264cf7a09b68a436bafc4d7281743d7f1c721ded] <strong>EQUALVERIFY CHECKSIG
HASH160 PUSHDATA</strong>(20)[72cf56ba8b7312ae658debf033d88e4370b9a8f5] <strong>EQUAL</strong></p>

CC BY-SA 4.0
2019-03-12T22:00:04.987Z
Note that you have two separate output scripts merged together in your question. There are two outputs and therefore two output scripts.
Dmitry Laptev
<script>
Can someone help me understand what these scripts mean?
gReigns
# Can someone help me understand what these scripts mean?

(Asked by: username_0 on 2019-03-12)

Could someone explain what the commands i have in **bold** do? if possible. Thank you.

[Transaction URL www.blockchain.com/btc/tx](https://www.blockchain.com/btc/tx/d5660360c401e17e5f0f0fbcabc3c369002bf2a58a6eaeaf1d8242dd01da3f72)

Input Scripts-
ScriptSig: **PUSHDATA(71)**[3044022069f0c9da12ce7b002c68d25e4445191b149627987367fdec4e4b80e442379f3902202109994c46d8c6afd8e94542d07fa8a07da234f7537c4a1d639d2dcdd32f9c5b01] **PUSHDATA(33)**[03c26e5ff8c75d6272b2d9cd3a882c20315d440251deb79873b75b690d0b71f4cf]

Output Scripts-
**DUP HASH160 PUSHDATA**(20)[264cf7a09b68a436bafc4d7281743d7f1c721ded] **EQUALVERIFY CHECKSIG
HASH160 PUSHDATA**(20)[72cf56ba8b7312ae658debf033d88e4370b9a8f5] **EQUAL**

**Tags:** script

> **Comments:**
> **username_1**: Note that you have two separate output scripts merged together in your question. There are two outputs and therefore two output scripts.  

---

## 2 answers

### Answer by username_1 on 2019-03-12. Score: 0 | Accepted answer

There is a nice [introduction to script](https://en.bitcoin.it/wiki/Script) and already another answer explaining what these *specific commands* do, but I will try to explain what these *scripts* actually do.

They implement a very standard bitcoin transaction called *pay-to-pubkey-hash transaction*.

The idea is roughly the following. Let's call this transaction `A`. To spend the output of transaction `A`, another transaction will be created and broadcasted, let's call it `B`. In order to verify the validity of transaction `B`, one should:

1. combine the input script of `B` with the output script of `A`,
2. execute the combined script and verify that it returns `True`.

In this type of transactions, transaction `B` should provide an input script that puts two elements to the stack: the signature `sig` of the transaction and a corresponding public key `pubKey`. Note how the input script of transaction `A` is also doing exactly that.

Then the output script of transaction `A` will do the following (in your question you actually provide two output scripts merged together, because there are two outputs, I will focus on the first one):

1. Duplicate `pubKey` on the stack;
2. Hash one `pubKey` from the stack and verify that it is equal to `264cf7a09b68a436bafc4d7281743d7f1c721ded`
3. Take `sig` and the remaining `pubKey` from the stack and verify the validity of the signature.

> **Comments:**
> **username_0**: 1st thank you. 2nd I think i understand what your saying. So basically for the balance to be spendable, another transaction has to take place to verify it spendable?  
> **username_1**: @username_0 roughly, yes, depending on what you mean by “spendable”. Transaction A dictates the conditions under which the balance (or rather UTXO is a better term) can be spend. But until transaction B appears and spends these outputs by providing the right signature, no one really knows if these conditions are possible to meet.  

---

### Answer by username_2 on 2019-03-12. Score: 0

* PUSHDATA(71): Pushes the next 71 bytes onto the top of stack
* PUSHDATA(33): Pushes the next 33 bytes onto the top of stack
* DUP: Pushes a duplicate of the top stack item onto the top of the stack
* HASH160: Pop the top stack item off of the stack, hash it using SHA256 then that hash with RIPEMD160, and push the resulting hash to the top of the stack
* PUSHDATA(20): Push the next 20 bytes onto the top of the stack
* EQUALVERIFY: Check that the top two stack items are equal. If they are, do nothing. If they are not, immediately fail execution
* CHECKSIG:Pop the top stack item and interpret it as a public key. Pop the next stack item and interpret it as a signature. Check that the signature verifies to that public key when the message that is signed is a modified version of the transaction containing the signature. If the signature is valid, push OP\_TRUE to the top of the stack. If it is false, push OP\_FALSE to the top of the stack.

A full description of all script opcodes and their actual byte values can be found [on the Bitcoin wiki](https://en.bitcoin.it/wiki/Script).

> **Comments:**
> **username_3**: Can't believe that this was not a duplicate. I will add a link to a video in which I dissect a pay2pkh tx: https://youtu.be/1n4g3eYX1UI that should help to understand how these op codes work  

---

