<blockquote>
<p>What I am not getting is how the operation are done.</p>
</blockquote>
<p>The address encodes the hash160 of the <em>redeemScript</em>. That address was given to the sender, who used it to construct an output <em>scriptPubKey</em> of the form <code>OP_HASH160 &lt;scripthash&gt; OP_EQUAL</code>. The <em>scripthash</em> is really <em>hash160(redeemScript)</em>, but the sender does not know that, as they aren't given the actual <em>redeemScript</em>, just its <em>hash160</em>. The <code>&lt;...&gt;</code> notation here means &quot;script opcode that pushes ... onto the stack&quot;.</p>
<p>The <em>redeemscript</em> is <code>OP_2 &lt;pubkey1&gt; &lt;pubkey2&gt; &lt;pubkey3&gt; OP_3 OP_CHECKMULTISIG</code>. This script was created by the receiver, encoding their policy for spending, and then its hash160 was given in the form of a P2SH address (3...) to the sender.</p>
<p>The <em>scriptSig</em> is what is created by the receiver when they want to spend the coins. In this case it consists of <code>OP_0 &lt;sig1&gt; &lt;sig2&gt; &lt;redeemScript&gt;</code>.</p>
<p>During validation, what happens is:</p>
<ul>
<li>First the <em>scriptSig</em> is executed, which pushes 4 items onto the stack (0, <em>sig1</em>, <em>sig2</em>, and <em>redeemScript</em>).</li>
<li>Then the scriptPubKey is executed, starting with the previous execution's final stack as initial state. It contains 3 opcodes, each modifying that stack:
<ul>
<li><code>OP_HASH160</code>: takes the final element of the stack (the <em>redeemScript</em>) and replaces it with <em>hash160(redeemScript)</em>.</li>
<li><code>&lt;scripthash&gt;</code>: pushes the <em>scripthash</em> onto the stack, so now the stack is (0, <em>sig1</em>, <em>sig2</em>, <em>hash160(redeemScript)</em>, <em>scripthash</em>).</li>
<li><code>OP_EQUALVERIFY</code>: removes the top two items on the stack and compares them. If they are equal, a 1 is pushed onto the stack, otherwise a zero. In our case, the <em>scripthash</em> is equal to <em>hash160(redeemScript</em>) (because the spender revealed the correct <em>redeemScript</em>) and thus a 1 is pushed. The stack is now (0, <em>sig1</em>, <em>sig2</em>, 1).</li>
</ul>
</li>
<li>The final stack is examined: validity rules require that the stack is not empty, and that its top element is nonzero. That is the case here: the top element is 1. If that wasn't the case, the spend would be marked invalid and execution would stop here.</li>
</ul>
<p>That's it for the ordinary execution. However, because the <em>scriptSig</em> is <strong>exactly</strong> of the form <code>OP_HASH160 &lt;20-byte scripthash&gt; OP_EQUAL</code>, the BIP16 P2SH validation rules trigger for a secondary round of processing. This time:</p>
<ul>
<li>It is verified that the <em>scriptSig</em> contains only push opcodes, and no other opcodes. If this is not true, the P2SH validation marks the transaction as invalid.</li>
<li>The stack we had just after executing the <em>scriptSig</em> is restored (0, <em>sig1</em>, <em>sig2</em>, <em>redeemScript</em>).</li>
<li>Its top element (the <em>redeemScript</em>) is removed from the stack, and reinterpreted as a script, and executed, with all the other stack elements as input. It consists of 6 opcodes:
<ul>
<li><code>OP_2</code>: pushes a 2 onto the stack, which now becomes (0, <em>sig1</em>, <em>sig2</em>, 2).</li>
<li><code>&lt;pubkey1&gt;</code>: pushes <em>pubkey1</em> onto the stack, which becomes (0, <em>sig1</em>, <em>sig2</em>, 2, <em>pubkey1</em>).</li>
<li><code>&lt;pubkey2&gt;</code>: pushes <em>pubkey2</em> onto the stack, which becomes (0, <em>sig1</em>, <em>sig2</em>, 2, <em>pubkey1</em>, <em>pubkey2</em>).</li>
<li><code>&lt;pubkey3&gt;</code>: pushes <em>pubkey3</em> onto the stack, which becomes (0, <em>sig1</em>, <em>sig2</em>, 2, <em>pubkey1</em>, <em>pubkey2</em>, <em>pubkey3</em>).</li>
<li><code>OP_3</code>: pushes a 2 onto the stack, which now becomes (0, <em>sig1</em>, <em>sig2</em>, 2, <em>pubkey1</em>, <em>pubkey2</em>, <em>pubkey3</em>, 3).</li>
<li><code>OP_CHECKMULTISIG</code> inspects the stack, sees a 3 on top, removes it, as well as the 3 pubkeys that precede it. Then it encounters a 2 on top, removes, as well as the 2 signatures that precede it. Then it removes one more element (a historical bug that is very hard to fix). Then it checks those signatures against every subset of 2 of those 3 pubkeys. If matches are found, it puts a 1 on the stack, otherwise a 0. In this case, the signatures are valid for some subset of the public keys, and the stack becomes (1).</li>
</ul>
</li>
<li>The final stack is inspected, requiring that it is not empty, and its top element is nonzero. As it is a 1 here, that is the case.</li>
</ul>

CC BY-SA 4.0
2021-01-24T01:07:53.943Z
This is super clear, thank Pieter!
fraccaman
CC BY-SA 4.0
2021-01-24T01:03:31.173Z
2021-01-24T01:14:28.357Z
2021-01-24T01:14:28.357Z
Pieter Wuille
<p>So, I was looking into how P2SH transactions are working and by looking at different blog post and in particular to <a href="https://bitcoin.stackexchange.com/questions/101740/what-does-this-pubkey-mean">this answer</a>, I have the following question.</p>
<p>So, let's take the same transaction:</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>What I am not getting is how the operation are done.</p>
<ul>
<li>Is the scriptSig executed first?</li>
<li>What is checked to be equal to <code>0b49fe...df1</code>? How is it calculated ?</li>
</ul>

CC BY-SA 4.0
2021-01-24T00:22:43.410Z
Does this answer your question? [Full list of "special cases" during Bitcoin Script execution (p2sh, p2wsh, etc.)?](https://bitcoin.stackexchange.com/questions/101142/full-list-of-special-cases-during-bitcoin-script-execution-p2sh-p2wsh-etc)
Pieter Wuille
CC BY-SA 4.0
2021-01-24T00:33:29.910Z
Well, it for sure help. What I dont get is that since the address `32ihz...QT` is the result of base58(prefix + sha256(locking-script)), and the pkscript is checking just the ripemd160, there has to be the sha256 inside the sigscript right? or am I missing something?
fraccaman
CC BY-SA 4.0
2021-01-24T00:38:51.483Z
No, it's base58(prefix + hash160(redeemscript)). hash160(x) = ripemd160(hash160(x)). And it's what OP_HASH160 does.
Pieter Wuille
CC BY-SA 4.0
2021-01-24T00:52:40.153Z
So, is the redeemscript part of the scriptSig? If yes, how can you tell which part of the scriptSig is the redeemscript and which are the "inputs" to "solve" it?
fraccaman
CC BY-SA 4.0
2021-01-24T00:53:17.240Z
The rule for P2SH is that the final stack element is the redeemScript, and everything before it are inputs to it.
Pieter Wuille
CC BY-SA 4.0
2021-01-24T01:01:33.013Z
Okay make sense. So, I have one last question. Hypothetically speaking, as this is not feasible, finding a redeemscript with a ripemd160 output equal to the address and a return value True would make that specific output spendable?
fraccaman
<p2sh>
How are p2sh address spent
fraccaman
# How are p2sh address spent

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

So, I was looking into how P2SH transactions are working and by looking at different blog post and in particular to [this answer](https://bitcoin.stackexchange.com/questions/101740/what-does-this-pubkey-mean), I have the following question.

So, let's take the same transaction:

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

What I am not getting is how the operation are done.

* Is the scriptSig executed first?
* What is checked to be equal to `0b49fe...df1`? How is it calculated ?

**Tags:** p2sh

> **Comments:**
> **username_1**: Does this answer your question? [Full list of "special cases" during Bitcoin Script execution (p2sh, p2wsh, etc.)?](https://bitcoin.stackexchange.com/questions/101142/full-list-of-special-cases-during-bitcoin-script-execution-p2sh-p2wsh-etc)  
> **username_0**: Well, it for sure help. What I dont get is that since the address `32ihz...QT` is the result of base58(prefix + sha256(locking-script)), and the pkscript is checking just the ripemd160, there has to be the sha256 inside the sigscript right? or am I missing something?  
> **username_1**: No, it's base58(prefix + hash160(redeemscript)). hash160(x) = ripemd160(hash160(x)). And it's what OP_HASH160 does.  
> **username_0**: So, is the redeemscript part of the scriptSig? If yes, how can you tell which part of the scriptSig is the redeemscript and which are the "inputs" to "solve" it?  
> **username_1**: The rule for P2SH is that the final stack element is the redeemScript, and everything before it are inputs to it.  
> **username_0**: Okay make sense. So, I have one last question. Hypothetically speaking, as this is not feasible, finding a redeemscript with a ripemd160 output equal to the address and a return value True would make that specific output spendable?  

---

## 1 answers

### Answer by username_1 on 2021-01-24. Score: 2 | Accepted answer

> What I am not getting is how the operation are done.

The address encodes the hash160 of the *redeemScript*. That address was given to the sender, who used it to construct an output *scriptPubKey* of the form `OP_HASH160 <scripthash> OP_EQUAL`. The *scripthash* is really *hash160(redeemScript)*, but the sender does not know that, as they aren't given the actual *redeemScript*, just its *hash160*. The `<...>` notation here means "script opcode that pushes ... onto the stack".

The *redeemscript* is `OP_2 <pubkey1> <pubkey2> <pubkey3> OP_3 OP_CHECKMULTISIG`. This script was created by the receiver, encoding their policy for spending, and then its hash160 was given in the form of a P2SH address (3...) to the sender.

The *scriptSig* is what is created by the receiver when they want to spend the coins. In this case it consists of `OP_0 <sig1> <sig2> <redeemScript>`.

During validation, what happens is:

* First the *scriptSig* is executed, which pushes 4 items onto the stack (0, *sig1*, *sig2*, and *redeemScript*).
* Then the scriptPubKey is executed, starting with the previous execution's final stack as initial state. It contains 3 opcodes, each modifying that stack:
  + `OP_HASH160`: takes the final element of the stack (the *redeemScript*) and replaces it with *hash160(redeemScript)*.
  + `<scripthash>`: pushes the *scripthash* onto the stack, so now the stack is (0, *sig1*, *sig2*, *hash160(redeemScript)*, *scripthash*).
  + `OP_EQUALVERIFY`: removes the top two items on the stack and compares them. If they are equal, a 1 is pushed onto the stack, otherwise a zero. In our case, the *scripthash* is equal to *hash160(redeemScript*) (because the spender revealed the correct *redeemScript*) and thus a 1 is pushed. The stack is now (0, *sig1*, *sig2*, 1).
* The final stack is examined: validity rules require that the stack is not empty, and that its top element is nonzero. That is the case here: the top element is 1. If that wasn't the case, the spend would be marked invalid and execution would stop here.

That's it for the ordinary execution. However, because the *scriptSig* is **exactly** of the form `OP_HASH160 <20-byte scripthash> OP_EQUAL`, the BIP16 P2SH validation rules trigger for a secondary round of processing. This time:

* It is verified that the *scriptSig* contains only push opcodes, and no other opcodes. If this is not true, the P2SH validation marks the transaction as invalid.
* The stack we had just after executing the *scriptSig* is restored (0, *sig1*, *sig2*, *redeemScript*).
* Its top element (the *redeemScript*) is removed from the stack, and reinterpreted as a script, and executed, with all the other stack elements as input. It consists of 6 opcodes:
  + `OP_2`: pushes a 2 onto the stack, which now becomes (0, *sig1*, *sig2*, 2).
  + `<pubkey1>`: pushes *pubkey1* onto the stack, which becomes (0, *sig1*, *sig2*, 2, *pubkey1*).
  + `<pubkey2>`: pushes *pubkey2* onto the stack, which becomes (0, *sig1*, *sig2*, 2, *pubkey1*, *pubkey2*).
  + `<pubkey3>`: pushes *pubkey3* onto the stack, which becomes (0, *sig1*, *sig2*, 2, *pubkey1*, *pubkey2*, *pubkey3*).
  + `OP_3`: pushes a 2 onto the stack, which now becomes (0, *sig1*, *sig2*, 2, *pubkey1*, *pubkey2*, *pubkey3*, 3).
  + `OP_CHECKMULTISIG` inspects the stack, sees a 3 on top, removes it, as well as the 3 pubkeys that precede it. Then it encounters a 2 on top, removes, as well as the 2 signatures that precede it. Then it removes one more element (a historical bug that is very hard to fix). Then it checks those signatures against every subset of 2 of those 3 pubkeys. If matches are found, it puts a 1 on the stack, otherwise a 0. In this case, the signatures are valid for some subset of the public keys, and the stack becomes (1).
* The final stack is inspected, requiring that it is not empty, and its top element is nonzero. As it is a 1 here, that is the case.

> **Comments:**
> **username_0**: This is super clear, thank username_1!  

---

