<p>Take a look at <a href="https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki" rel="nofollow">BIP0016</a>.</p>

<blockquote>
  <p>This new transaction type is redeemed by a standard scriptSig:</p>
  
  <p><code>...signatures... {serialized script}</code></p>
</blockquote>

<p>And...</p>

<blockquote>
  <p>{serialized script} is popped off the initial stack, and the transaction is validated again using the popped stack and the deserialized script as the scriptPubKey.</p>
</blockquote>

<p>In this case, <code>{serialized script}</code> is <code>{m [pubkey1] [pubkey2] ... [pubkeyn] n OP_CHECKMULTISIG}</code> for a <code>m-of-n</code> transaction. When Bitcoin detects one of these special transactions, the serialized script is popped of the stack as soon as its hash is validated (you're validating the script hash! not an actual public key!) and then executed with the remaining stack intact.</p>

<p>Your payment script looks like this:</p>

<pre><code>0 /* null element because a bug pops one-too-many items */
304402205fdee0b00f5e2fa07324458fe06b47a41bb2ef4e73892343796e9f6456e378940220630b423ce14b0d5ed487da751c368d7fc0122efa21cac1a4afce7c3c017bf29f01 
304502205edb6ce77a772346b21d60a775c81f52bec9e8957f795fce7ea4fab862bc656c022100fc1376399134348fae516d6e627b1f72c094affd3ba2f458685bdbe9b6a51f5e01 
5221020678adff50855b6748e93ab03667968817363fff84306d7ffc13276191fd7f542102bff39dce7ae4c6a06104ac4e49948eb7bac9d4a82e9e16df41b1436d31b76f0052ae
</code></pre>

<p>The last part (<code>5221020678...52ae</code>) is actually your serialized script. If you decode it you get:</p>

<pre><code>2 020678adff50855b6748e93ab03667968817363fff84306d7ffc13276191fd7f54 02bff39dce7ae4c6a06104ac4e49948eb7bac9d4a82e9e16df41b1436d31b76f00 2 OP_CHECKMULTISIG
</code></pre>

<p>Which is a 2-of-2 transaction!</p>

<p>The first two parts not including the null element (the ones that look like <code>304...01</code>) are just your provided signatures which are going to validate against the serialized public keys when <code>OP_CHECKMULTISIG</code> is executed.</p>

CC BY-SA 3.0
2014-01-15T16:07:45.003Z
2014-01-15T16:07:45.003Z
kaoD
<p>I used the <a href="https://people.xiph.org/~greg/escrowexample.txt" rel="nofollow">guide</a>, how to make escrow from bitcoin console.</p>

<p>Here are my transactions in testnet: <a href="http://blockexplorer.com/testnet/tx/10d5b7f61be2fa2e5979043a7071d3dbd371bc72cefea22e43b2dd54a6e27a99" rel="nofollow">tx1</a> <a href="http://blockexplorer.com/testnet/tx/f019aff63c018ac1aaae7c4e8d408efdeb5572314645b2dcb7d35b1e7a71d431#i8171667" rel="nofollow">tx2</a></p>

<p>I am confused about ScriptPublicKey in tx1:</p>

<pre><code>OP_HASH160 a7a62637430b44c922cbce4fc8bd53d11b7c4c25 OP_EQUAL
</code></pre>

<p>So it is just calculate Hash160 of top stack value, and compare it with <code>a7a6...25</code>. 
In the ScriptSig of tx2 we can see 4 values, which will be pushed to stack for validation. But vout script uses only the top stack value:</p>

<pre><code>5221020678adff50855b6748e93ab03667968817363fff84306d7ffc13276191fd7f542102bff39dce7ae4c6a06104ac4e49948eb7bac9d4a82e9e16df41b1436d31b76f0052ae
</code></pre>

<p>Other 2 values are signatures:</p>

<pre><code>304402205fdee0b00f5e2fa07324458fe06b47a41bb2ef4e73892343796e9f6456e378940220630b423ce14b0d5ed487da751c368d7fc0122efa21cac1a4afce7c3c017bf29f01
304502205edb6ce77a772346b21d60a775c81f52bec9e8957f795fce7ea4fab862bc656c022100fc1376399134348fae516d6e627b1f72c094affd3ba2f458685bdbe9b6a51f5e01
</code></pre>

<p>As we can see, this signatures are not validating by vout script.</p>

<p>And why this functionallity does not work with OP_CHECKMULTISIG?</p>

<script><testnet><escrow><multi-signature>
Completely confused with mutisig address and scripts
Zergatul
# Completely confused with mutisig address and scripts

(Asked by: username_0 on 2014-01-15)

I used the [guide](https://people.xiph.org/~greg/escrowexample.txt), how to make escrow from bitcoin console.

Here are my transactions in testnet: [tx1](http://blockexplorer.com/testnet/tx/10d5b7f61be2fa2e5979043a7071d3dbd371bc72cefea22e43b2dd54a6e27a99) [tx2](http://blockexplorer.com/testnet/tx/f019aff63c018ac1aaae7c4e8d408efdeb5572314645b2dcb7d35b1e7a71d431#i8171667)

I am confused about ScriptPublicKey in tx1:

```
OP_HASH160 a7a62637430b44c922cbce4fc8bd53d11b7c4c25 OP_EQUAL

```

So it is just calculate Hash160 of top stack value, and compare it with `a7a6...25`.
In the ScriptSig of tx2 we can see 4 values, which will be pushed to stack for validation. But vout script uses only the top stack value:

```
5221020678adff50855b6748e93ab03667968817363fff84306d7ffc13276191fd7f542102bff39dce7ae4c6a06104ac4e49948eb7bac9d4a82e9e16df41b1436d31b76f0052ae

```

Other 2 values are signatures:

```
304402205fdee0b00f5e2fa07324458fe06b47a41bb2ef4e73892343796e9f6456e378940220630b423ce14b0d5ed487da751c368d7fc0122efa21cac1a4afce7c3c017bf29f01
304502205edb6ce77a772346b21d60a775c81f52bec9e8957f795fce7ea4fab862bc656c022100fc1376399134348fae516d6e627b1f72c094affd3ba2f458685bdbe9b6a51f5e01

```

As we can see, this signatures are not validating by vout script.

And why this functionallity does not work with OP\_CHECKMULTISIG?

**Tags:** script, testnet, escrow, multi-signature


---

## 1 answers

### Answer by username_1 on 2014-01-15. Score: 1 | Accepted answer

Take a look at [BIP0016](https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki).

> This new transaction type is redeemed by a standard scriptSig:
>
> `...signatures... {serialized script}`

And...

> {serialized script} is popped off the initial stack, and the transaction is validated again using the popped stack and the deserialized script as the scriptPubKey.

In this case, `{serialized script}` is `{m [pubkey1] [pubkey2] ... [pubkeyn] n OP_CHECKMULTISIG}` for a `m-of-n` transaction. When Bitcoin detects one of these special transactions, the serialized script is popped of the stack as soon as its hash is validated (you're validating the script hash! not an actual public key!) and then executed with the remaining stack intact.

Your payment script looks like this:

```
0 /* null element because a bug pops one-too-many items */
304402205fdee0b00f5e2fa07324458fe06b47a41bb2ef4e73892343796e9f6456e378940220630b423ce14b0d5ed487da751c368d7fc0122efa21cac1a4afce7c3c017bf29f01 
304502205edb6ce77a772346b21d60a775c81f52bec9e8957f795fce7ea4fab862bc656c022100fc1376399134348fae516d6e627b1f72c094affd3ba2f458685bdbe9b6a51f5e01 
5221020678adff50855b6748e93ab03667968817363fff84306d7ffc13276191fd7f542102bff39dce7ae4c6a06104ac4e49948eb7bac9d4a82e9e16df41b1436d31b76f0052ae

```

The last part (`5221020678...52ae`) is actually your serialized script. If you decode it you get:

```
2 020678adff50855b6748e93ab03667968817363fff84306d7ffc13276191fd7f54 02bff39dce7ae4c6a06104ac4e49948eb7bac9d4a82e9e16df41b1436d31b76f00 2 OP_CHECKMULTISIG

```

Which is a 2-of-2 transaction!

The first two parts not including the null element (the ones that look like `304...01`) are just your provided signatures which are going to validate against the serialized public keys when `OP_CHECKMULTISIG` is executed.


---

