1

01000000013dcd7d87904c9cb7f4b79f36b5a03f96e2e729284c09856238d5353e1182b00200000000fd5d01004730440220762ce7bca626942975bfd5b130ed3470b9f538eb2ac120c2043b445709369628022051d73c80328b543f744aa64b7e9ebefa7ade3e5c716eab4a09b408d2c307ccd701483045022100abf740b58d79cab000f8b0d328c2fff7eb88933971d1b63f8b99e89ca3f2dae602203354770db3cc2623349c87dea7a50cee1f78753141a5052b2d58aeb592bcf50f014cc9524104a882d414e478039cd5b52a92ffb13dd5e6bd4515497439dffd691a0f12af9575fa349b5694ed3155b136f09e63975a1700c9f4d4df849323dac06cf3bd6458cd41046ce31db9bdd543e72fe3039a1f1c047dab87037c36a669ff90e28da1848f640de68c2fe913d363a51154a0c62d7adea1b822d05035077418267b1a1379790187410411ffd36c70776538d079fbae117dc38effafb33304af83ce4894589747aee1ef992f63280567f52f5ba870678b4ab4ff6c8ea600bd217870a8b4f1f09f3a8e8353aeffffffff0130d90000000000001976a914569076ba39fc4ff6a2291d9ea9196d8c08f9c7ab88ac00000000

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?

1 Answer 1

2

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.

2
  • 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
    Commented Mar 13, 2018 at 3:30
  • 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. Commented Mar 13, 2018 at 6:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.