<p>As you have found out correctly, the length field describes the following script length. Then the SigScript follows:</p>

<pre><code>004730440220762CE7BCA626942975BFD5B130ED3470B9F538EB2AC120C2043B445709369628022051D73C80328B543F744AA64B7E9EBEFA7ADE3E5C716EAB4A09B408D2C307CCD701483045022100ABF740B58D79CAB000F8B0D328C2FFF7EB88933971D1B63F8B99E89CA3F2DAE602203354770DB3CC2623349C87DEA7A50CEE1F78753141A5052B2D58AEB592BCF50F014CC9524104A882D414E478039CD5B52A92FFB13DD5E6BD4515497439DFFD691A0F12AF9575FA349B5694ED3155B136F09E63975A1700C9F4D4DF849323DAC06CF3BD6458CD41046CE31DB9BDD543E72FE3039A1F1C047DAB87037C36A669FF90E28DA1848F640DE68C2FE913D363A51154A0C62D7ADEA1B822D05035077418267B1A1379790187410411FFD36C70776538D079FBAE117DC38EFFAFB33304AF83CE4894589747AEE1EF992F63280567F52F5BA870678B4AB4FF6C8EA600BD217870A8B4F1F09F3A8E8353AE
</code></pre>

<p>The script starts with a hex "0", which compensates for a very early "off by one error" in the execution routines of the checksig routines. An element too much was popped off the stack. This "bug" is so long in the system, that everyone got accustomed to it, and removing it requires an enormous effort. So it became a feature :-) Even more, if there are tx, which have an execution time in the future, they wouldn't work anymore...</p>

<blockquote>
  <p>how did the explorer find out that it is 2-3 multisig. In the
  first place how to identify a multisig?</p>
</blockquote>

<p>The explorer finds this in the script sig. There is the two signatures, and the part for the multisig:</p>

<pre><code>&lt;sig1&gt; &lt;sig2&gt; &lt;length&gt; OP2 &lt;pubkey1&gt; &lt;pubkey2&gt; &lt;pubkey3&gt; OP3 AE
</code></pre>

<p>to be better able to view, I have decoded the script a bit. The sigs start with hex 0x47 or 0x48, and end with 0x01. They are ASN1-DER encoded, providing a view into the R and S fields, and have surrounding length information. After the second 0x01, follows the length field, and then the multisig OPcode (0x02) and the 3 pubkeys.</p>

<pre><code>00: OP_0, OP_FALSE:      an empty array is pushed onto the stack.
&lt;sig1&gt;
47: OP_DATA_0x47:        push hex 47 (decimal 71) bytes on stack
30: OP_SEQUENCE_0x30:    type tag indicating SEQUENCE, begin sigscript
44: OP_LENGTH_0x44:      length of R + S
02: OP_INT_0x02:         type tag INTEGER indicating length
20: OP_LENGTH_0x20:      this is SIG R (32 Bytes)
02: OP_INT_0x02:         type tag INTEGER indicating length
20: OP_LENGTH_0x20:      this is SIG S (32 Bytes)
01: OP_SIGHASHALL:       this terminates the ECDSA signature (ASN1-DER structure)
&lt;sig2&gt;
48: OP_DATA_0x48:        push hex 48 (decimal 72) bytes on stack
30: OP_SEQUENCE_0x30:    type tag indicating SEQUENCE, begin sigscript
45: OP_LENGTH_0x45:      length of R + S
02: OP_INT_0x02:         type tag INTEGER indicating length
21: OP_LENGTH_0x21:      this is SIG R (33 Bytes)
02: OP_INT_0x02:         type tag INTEGER indicating length
20: OP_LENGTH_0x20:      this is SIG S (32 Bytes)
01: OP_SIGHASHALL:       this terminates the ECDSA signature (ASN1-DER structure)

4C: OP_PUSHDATA1:        next byte is # of bytes that go onto stack
C9: OP_Int(0x01-0xff):   201 bytes onto the stack
52: OP_2:                the number 2 is pushed onto stack
    ################### we go multisig ####################################
41: OP_DATA_0x41:        uncompressed pub key (65 Bytes)
41: OP_DATA_0x41:        uncompressed pub key (65 Bytes)
41: OP_DATA_0x41:        uncompressed pub key (65 Bytes)
53: OP_3:                the number 3 is pushed onto stack
    ################### 2-of-3 Multisig ###################################
AE: OP_CHECKMULTISIG:    terminating multisig
</code></pre>

<p>You find a very good explanation in chapter 6 "Transactions" and 7 "Advanced Transactions and Scripting" of Andreas' wonderful book "Mastering Bitcoin", which is also <a href="http://chimera.labs.oreilly.com/books/1234000001802/index.html" rel="nofollow noreferrer">online available.</a> </p>

CC BY-SA 3.0
2018-03-13T03:30:19.437Z
I didn't completely understand how you are able to find that tx has 2 signatures. When parsing the script, first we encountered 0x47 (71 Bytes). As script starts with signature, next 71 bytes must be SigA (understood till here). Now we got 0x48 (72 Bytes). Did you consider this 72 Bytes as SigB just because it is bigger than standard length of compressed/uncompressed pubkey? or do you some other logic to consider this 72 Bytes as SigB
lch
CC BY-SA 3.0
2018-03-13T06:13:49.477Z
Correct. Sigs are encoded by the ASN1 standard. Sig1 is the first 0x47, ending with "01". The second hex 0x48 defines a length, at this point in time it is unclear, what will follow - could be anything (e.g. redeemscript). Then follows 0x30 and 0x45, defining length of R+S, and ending with 0x01 - so it must be a signature again, cause it follows ASN1 DER encoding scheme.
pebwindkraft
CC BY-SA 3.0
2018-03-12T08:12:58.360Z
2018-03-13T06:08:44.433Z
2018-03-13T06:08:44.433Z
pebwindkraft
<p>01000000013dcd7d87904c9cb7f4b79f36b5a03f96e2e729284c09856238d5353e1182b00200000000<strong>fd5d01</strong>004730440220762ce7bca626942975bfd5b130ed3470b9f538eb2ac120c2043b445709369628022051d73c80328b543f744aa64b7e9ebefa7ade3e5c716eab4a09b408d2c307ccd701483045022100abf740b58d79cab000f8b0d328c2fff7eb88933971d1b63f8b99e89ca3f2dae602203354770db3cc2623349c87dea7a50cee1f78753141a5052b2d58aeb592bcf50f014cc9524104a882d414e478039cd5b52a92ffb13dd5e6bd4515497439dffd691a0f12af9575fa349b5694ed3155b136f09e63975a1700c9f4d4df849323dac06cf3bd6458cd41046ce31db9bdd543e72fe3039a1f1c047dab87037c36a669ff90e28da1848f640de68c2fe913d363a51154a0c62d7adea1b822d05035077418267b1a1379790187410411ffd36c70776538d079fbae117dc38effafb33304af83ce4894589747aee1ef992f63280567f52f5ba870678b4ab4ff6c8ea600bd217870a8b4f1f09f3a8e8353aeffffffff0130d90000000000001976a914569076ba39fc4ff6a2291d9ea9196d8c08f9c7ab88ac00000000</p>

<p>you can decode above tx at <a href="http://chainquery.com/bitcoin-api/decoderawtransaction" rel="nofollow noreferrer">http://chainquery.com/bitcoin-api/decoderawtransaction</a></p>

<p>From bitcoin explorer, I found that above transaction is 2-3 multisig tx. I understood that bolded part <code>fd5d01</code> is script-length. its value is 349 Bytes. In a normal tx, Within the ScriptSig, the first byte which tells us how long the signature is. followed by the size of the second element and then the second element which is pubkey. Now, how to identify the number of signatures involved in a multisig tx like above example. I mean how did the explorer find out that it is 2-3 multisig. In the first place how to identify a multisig? And what is the significance os OP_0 at the beginnning of scriptsig?</p>

<transactions><script><input-script>
Ho to identify a multisig transaction?
lch
# Ho to identify a multisig transaction?

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

01000000013dcd7d87904c9cb7f4b79f36b5a03f96e2e729284c09856238d5353e1182b00200000000**fd5d01**004730440220762ce7bca626942975bfd5b130ed3470b9f538eb2ac120c2043b445709369628022051d73c80328b543f744aa64b7e9ebefa7ade3e5c716eab4a09b408d2c307ccd701483045022100abf740b58d79cab000f8b0d328c2fff7eb88933971d1b63f8b99e89ca3f2dae602203354770db3cc2623349c87dea7a50cee1f78753141a5052b2d58aeb592bcf50f014cc9524104a882d414e478039cd5b52a92ffb13dd5e6bd4515497439dffd691a0f12af9575fa349b5694ed3155b136f09e63975a1700c9f4d4df849323dac06cf3bd6458cd41046ce31db9bdd543e72fe3039a1f1c047dab87037c36a669ff90e28da1848f640de68c2fe913d363a51154a0c62d7adea1b822d05035077418267b1a1379790187410411ffd36c70776538d079fbae117dc38effafb33304af83ce4894589747aee1ef992f63280567f52f5ba870678b4ab4ff6c8ea600bd217870a8b4f1f09f3a8e8353aeffffffff0130d90000000000001976a914569076ba39fc4ff6a2291d9ea9196d8c08f9c7ab88ac00000000

you can decode above tx at <http://chainquery.com/bitcoin-api/decoderawtransaction>

From bitcoin explorer, I found that above transaction is 2-3 multisig tx. I understood that bolded part `fd5d01` is script-length. its value is 349 Bytes. In a normal tx, Within the ScriptSig, the first byte which tells us how long the signature is. followed by the size of the second element and then the second element which is pubkey. Now, how to identify the number of signatures involved in a multisig tx like above example. I mean how did the explorer find out that it is 2-3 multisig. In the first place how to identify a multisig? And what is the significance os OP\_0 at the beginnning of scriptsig?

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


---

## 1 answers

### Answer by username_1 on 2018-03-12. Score: 2 | Accepted answer

As you have found out correctly, the length field describes the following script length. Then the SigScript follows:

```
004730440220762CE7BCA626942975BFD5B130ED3470B9F538EB2AC120C2043B445709369628022051D73C80328B543F744AA64B7E9EBEFA7ADE3E5C716EAB4A09B408D2C307CCD701483045022100ABF740B58D79CAB000F8B0D328C2FFF7EB88933971D1B63F8B99E89CA3F2DAE602203354770DB3CC2623349C87DEA7A50CEE1F78753141A5052B2D58AEB592BCF50F014CC9524104A882D414E478039CD5B52A92FFB13DD5E6BD4515497439DFFD691A0F12AF9575FA349B5694ED3155B136F09E63975A1700C9F4D4DF849323DAC06CF3BD6458CD41046CE31DB9BDD543E72FE3039A1F1C047DAB87037C36A669FF90E28DA1848F640DE68C2FE913D363A51154A0C62D7ADEA1B822D05035077418267B1A1379790187410411FFD36C70776538D079FBAE117DC38EFFAFB33304AF83CE4894589747AEE1EF992F63280567F52F5BA870678B4AB4FF6C8EA600BD217870A8B4F1F09F3A8E8353AE

```

The script starts with a hex "0", which compensates for a very early "off by one error" in the execution routines of the checksig routines. An element too much was popped off the stack. This "bug" is so long in the system, that everyone got accustomed to it, and removing it requires an enormous effort. So it became a feature :-) Even more, if there are tx, which have an execution time in the future, they wouldn't work anymore...

> how did the explorer find out that it is 2-3 multisig. In the
> first place how to identify a multisig?

The explorer finds this in the script sig. There is the two signatures, and the part for the multisig:

```
<sig1> <sig2> <length> OP2 <pubkey1> <pubkey2> <pubkey3> OP3 AE

```

to be better able to view, I have decoded the script a bit. The sigs start with hex 0x47 or 0x48, and end with 0x01. They are ASN1-DER encoded, providing a view into the R and S fields, and have surrounding length information. After the second 0x01, follows the length field, and then the multisig OPcode (0x02) and the 3 pubkeys.

```
00: OP_0, OP_FALSE:      an empty array is pushed onto the stack.
<sig1>
47: OP_DATA_0x47:        push hex 47 (decimal 71) bytes on stack
30: OP_SEQUENCE_0x30:    type tag indicating SEQUENCE, begin sigscript
44: OP_LENGTH_0x44:      length of R + S
02: OP_INT_0x02:         type tag INTEGER indicating length
20: OP_LENGTH_0x20:      this is SIG R (32 Bytes)
02: OP_INT_0x02:         type tag INTEGER indicating length
20: OP_LENGTH_0x20:      this is SIG S (32 Bytes)
01: OP_SIGHASHALL:       this terminates the ECDSA signature (ASN1-DER structure)
<sig2>
48: OP_DATA_0x48:        push hex 48 (decimal 72) bytes on stack
30: OP_SEQUENCE_0x30:    type tag indicating SEQUENCE, begin sigscript
45: OP_LENGTH_0x45:      length of R + S
02: OP_INT_0x02:         type tag INTEGER indicating length
21: OP_LENGTH_0x21:      this is SIG R (33 Bytes)
02: OP_INT_0x02:         type tag INTEGER indicating length
20: OP_LENGTH_0x20:      this is SIG S (32 Bytes)
01: OP_SIGHASHALL:       this terminates the ECDSA signature (ASN1-DER structure)

4C: OP_PUSHDATA1:        next byte is # of bytes that go onto stack
C9: OP_Int(0x01-0xff):   201 bytes onto the stack
52: OP_2:                the number 2 is pushed onto stack
    ################### we go multisig ####################################
41: OP_DATA_0x41:        uncompressed pub key (65 Bytes)
41: OP_DATA_0x41:        uncompressed pub key (65 Bytes)
41: OP_DATA_0x41:        uncompressed pub key (65 Bytes)
53: OP_3:                the number 3 is pushed onto stack
    ################### 2-of-3 Multisig ###################################
AE: OP_CHECKMULTISIG:    terminating multisig

```

You find a very good explanation in chapter 6 "Transactions" and 7 "Advanced Transactions and Scripting" of Andreas' wonderful book "Mastering Bitcoin", which is also [online available.](http://chimera.labs.oreilly.com/books/1234000001802/index.html)

> **Comments:**
> **username_0**: I didn't completely understand how you are able to find that tx has 2 signatures. When parsing the script, first we encountered 0x47 (71 Bytes). As script starts with signature, next 71 bytes must be SigA (understood till here). Now we got 0x48 (72 Bytes). Did you consider this 72 Bytes as SigB just because it is bigger than standard length of compressed/uncompressed pubkey? or do you some other logic to consider this 72 Bytes as SigB  
> **username_1**: Correct. Sigs are encoded by the ASN1 standard. Sig1 is the first 0x47, ending with "01". The second hex 0x48 defines a length, at this point in time it is unclear, what will follow - could be anything (e.g. redeemscript). Then follows 0x30 and 0x45, defining length of R+S, and ending with 0x01 - so it must be a signature again, cause it follows ASN1 DER encoding scheme.  

---

