<p>This is a P2SH script (pay to script hash), defined in <a href="https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki" rel="nofollow noreferrer">BIP 16</a>.</p>
<p>The <code>scriptPubKey</code> itself is very uninteresting: it takes an element from the <code>scriptSig</code>, hashes it with <code>OP_HASH160</code>, and then compares it with 0b49fe...f1. In other words, ostensibly the only thing needed in order to spend is knowing some piece of data whose hash is 0b49fe....f1.</p>
<p>Now, BIP 16 changed this. If a <code>scriptPubKey</code> has <em>exactly</em> the form OP_HASH160 + 20 byte hash + OP_EQUAL, then the special P2SH validation rules trigger:</p>
<ul>
<li>All operations in the <code>scriptSig</code> must be pushes.</li>
<li>The final push in the <code>scriptSig</code> (the one whose hash we know is 0b49fe...f1) is taken to again be a Script (called the <code>redeemScript</code>).</li>
<li>That Script is executed, with as inputs all but the final push in the <code>scriptSig</code>.</li>
</ul>
<p>So, semantically, the whole operation is equivalent to just using the <code>redeemScript</code> as <code>scriptPubKey</code>, but without needing to reveal this to the sender. Instead, the sender can just be given a short P2SH (3...) address that encodes the hash of the <code>redeemScript</code>, and the real one is only revealed at spending time.</p>
<p>In your example, the <code>redeemScript</code> appears to encode a 2-of-3 multisig policy: <code>OP_2 &lt;pubkey1&gt; &lt;pubkey2&gt; &lt;pubkey3&gt; OP_3 OP_CHECKMULTISIG</code>, and the additional stack items in the <code>scriptSig</code> are OP_0 (a workaround for a bug that <code>OP_CHECKMULTISIG</code> pops off one item too many from the stack) plus 2 signatures.</p>

CC BY-SA 4.0
2021-01-23T00:16:48.597Z
2021-01-23T00:16:48.597Z
Pieter Wuille
<p>I just started learning about Bitcoin, and am sorta familiar with p2pk and p2pkh. I just found this input on a Bitcoin blockchain explorer:</p>
<p><a href="https://i.sstatic.net/QhCLD.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/QhCLD.png" alt="enter image description here" /></a></p>
<p>It looks like the Pkscript can be &quot;solved&quot; (I'm not super familiar with terminology) by something thats hash160 is the 0b49fe...</p>
<p>The ScriptSig looks a little more intimidating :)</p>
<p>What exactly is the ScriptSig doing? How does this sort of paying mechanism work?</p>
<p>Thanks</p>

<transactions><script><transaction-input><input-script>
What does this Pubkey mean?
yoyobigmanyo
# What does this Pubkey mean?

(Asked by: username_0 on 2021-01-22)

I just started learning about Bitcoin, and am sorta familiar with p2pk and p2pkh. I just found this input on a Bitcoin blockchain explorer:

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

It looks like the Pkscript can be "solved" (I'm not super familiar with terminology) by something thats hash160 is the 0b49fe...

The ScriptSig looks a little more intimidating :)

What exactly is the ScriptSig doing? How does this sort of paying mechanism work?

Thanks

**Tags:** transactions, script, transaction-input, input-script


---

## 1 answers

### Answer by username_1 on 2021-01-23. Score: 1

This is a P2SH script (pay to script hash), defined in [BIP 16](https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki).

The `scriptPubKey` itself is very uninteresting: it takes an element from the `scriptSig`, hashes it with `OP_HASH160`, and then compares it with 0b49fe...f1. In other words, ostensibly the only thing needed in order to spend is knowing some piece of data whose hash is 0b49fe....f1.

Now, BIP 16 changed this. If a `scriptPubKey` has *exactly* the form OP\_HASH160 + 20 byte hash + OP\_EQUAL, then the special P2SH validation rules trigger:

* All operations in the `scriptSig` must be pushes.
* The final push in the `scriptSig` (the one whose hash we know is 0b49fe...f1) is taken to again be a Script (called the `redeemScript`).
* That Script is executed, with as inputs all but the final push in the `scriptSig`.

So, semantically, the whole operation is equivalent to just using the `redeemScript` as `scriptPubKey`, but without needing to reveal this to the sender. Instead, the sender can just be given a short P2SH (3...) address that encodes the hash of the `redeemScript`, and the real one is only revealed at spending time.

In your example, the `redeemScript` appears to encode a 2-of-3 multisig policy: `OP_2 <pubkey1> <pubkey2> <pubkey3> OP_3 OP_CHECKMULTISIG`, and the additional stack items in the `scriptSig` are OP\_0 (a workaround for a bug that `OP_CHECKMULTISIG` pops off one item too many from the stack) plus 2 signatures.


---

