1

In the transaction https://blockchain.info/tx/32e8677c968981549acc25f46641c74a3055d949c90bd22c15a5236bf92a622d the first input has the following SigScript

0047304402201c45383cc6e43202ed069e36184a97bf5dd489c6bea1372629540dea154c424902200a950b3557bba9ae9531237d46e6eb1afffd01eba989c3e53adaac443e5e2a2e01473044022032a681fb77589ce1a29a84494a6f9cb19630fcd65480ff646f30d8b826980390022006dc71baba1142abb275bbf3613b2a13b347bac4d09d41ccd9b69b02c270d8c2014c69522103745aaaf364030720b2d14de50a3310eef521c91e36353dca20813713535c005a2102db8911b3989b43c43d8dd6e50459bd85c38faf3b2862eb78ef297002775a10bd210351e3f71b7cf9a5f5f86c1908fee02ebf5a1ed77b6748f7486505d155833645f253ae

Apparently this decodes to:

       00
sig1   47304402201C45383CC6E43202ED069E36184A97BF5DD489C6BEA1372629540DEA154C424902200A950B3557BBA9AE9531237D46E6EB1AFFFD01EBA989C3E53ADAAC443E5E2A2E01
sig2   473044022032A681FB77589CE1A29A84494A6F9CB19630FCD65480FF646F30D8B826980390022006DC71BABA1142ABB275BBF3613B2A13B347BAC4D09D41CCD9B69B02C270D8C201
length 4C69
OP_2   52
pk1    21 03745AAAF364030720B2D14DE50A3310EEF521C91E36353DCA20813713535C005A
pk2    21 02DB8911B3989B43C43D8DD6E50459BD85C38FAF3B2862EB78EF297002775A10BD
pk3    21 0351E3F71B7CF9A5F5F86C1908FEE02EBF5A1ED77B6748F7486505D155833645F2
OP_3   53
check  AE

I understand it is a 2-of-3 multisig but what I'm failing to wrap my head around is how we get from the raw SigScript to the thing underneath that is human readable.

user2334659
  • 313
  • 7

2 Answers2

2

I would decode this in two steps:

  1. step through the bytes and interpret each byte according to https://en.bitcoin.it/wiki/Script

  2. look at the documentation for multisig to put a name to each pushed data item.

We can do the first step by hand quite easily

Hex meaning
00 OP_FALSE or OP_ZERO, pushes 0x00 onto the stack
47 push the next 0x47 (71 decimal) bytes onto the stack
304402201c45383c c6e43202ed069e36 184a97bf5dd489c6 bea1372629540dea 154c424902200a95 0b3557bba9ae9531 237d46e6eb1afffd 01eba989c3e53ada ac443e5e2a2e01 pushed onto stack
47 push the next 0x47 (71 decimal) bytes onto the stack
3044022032a681fb 77589ce1a29a8449 4a6f9cb19630fcd6 5480ff646f30d8b8 26980390022006dc 71baba1142abb275 bbf3613b2a13b347 bac4d09d41ccd9b6 9b02c270d8c201 pushed onto stack
4c OP_PUSHDATA1, the next one byte contains the number of following bytes to be pushed onto stack
69 ... push the next 0x69 (105 decimal) bytes onto the stack
522103745aaaf364 030720b2d14de50a 3310eef521c91e36 353dca2081371353 5c005a2102db8911 b3989b43c43d8dd6 e50459bd85c38faf 3b2862eb78ef2970 02775a10bd210351 e3f71b7cf9a5f5f8 6c1908fee02ebf5a 1ed77b6748f74865 05d155833645f253 ae pushed onto stack

We can see that the two pushes of 71 bytes start with the typical byte sequences expected of a DER encoded signature.

The last push of 105 bytes is also a script (called the redeem script)

Hex meaning
52 OP_2, push 0x02 onto stack
21 push next 0x21 (33 decimal) bytes onto stack
03745aaaf3640307 20b2d14de50a3310 eef521c91e36353d ca20813713535c00 5a pushed data. The length is typical of a pubkey
21 push next 0x21 (33 decimal) bytes onto stack
02db8911b3989b43 c43d8dd6e50459bd 85c38faf3b2862eb 78ef297002775a10 bd pushed data
21 push next 0x21 (33 decimal) bytes onto stack
0351e3f71b7cf9a5 f5f86c1908fee02e bf5a1ed77b6748f7 486505d155833645 f2 pushed data
53 OP_3, push 0x03 onto stack
ae OP_CHECKMULTISIG

We know what OP_CHECKMULTISIG expects to see on the stack so we can assign those names to the data items. Alternatively you can read descriptions such as those at 2of2 multisig - redeem script required

Anyway by inspection we can easily see that the script contains two signatures and three public keys.

RedGrittyBrick
  • 26,841
  • 3
  • 25
  • 51
1

Bitcoin bases its logic of payment (locking) and spending (unlocking) funds on a scripting language and a stack. Each byte within raw sigScript has its own meaning. Bytes can be divided into two major types. Bytes that indicate which operation should be performed on the stack and bytes that indicate data. The first type represents opcodes. For example, the byte 0xae has a special meaning and indicates the OP_CHECKMULTISIG opcode. You can find a list of all opcodes here.

Looking at the example you provided, the raw scriptSig looks like this (opcodes are in bold, the rest is data):

0047304402201c45383cc6e43202ed069e36184a97bf5dd489c6bea1372629540dea154c424902200a950b3557bba9ae9531237d46e6eb1afffd01eba989c3e53adaac443e5e2a2e01473044022032a681fb77589ce1a29a84494a6f9cb19630fcd65480ff646f30d8b826980390022006dc71baba1142abb275bbf3613b2a13b347bac4d09d41ccd9b69b02c270d8c2014c69522103745aaaf364030720b2d14de50a3310eef521c91e36353dca20813713535c005a2102db8911b3989b43c43d8dd6e50459bd85c38faf3b2862eb78ef297002775a10bd210351e3f71b7cf9a5f5f86c1908fee02ebf5a1ed77b6748f7486505d155833645f253ae

Therefore, the first byte (0x00) represents one of the opcodes and indicates the operation OP_0, i.e. that it is necessary to push an empty array onto the stack. The next byte (0x47) also has a special meaning (opcode) which means that the next 71 bytes represent the data to be pushed onto the stack. After the data (the previous 71 bytes), the byte 0x47 (opcode) follows again, indicating the pushing of the next 71 bytes. This data is followed by the byte 0x4c. The given byte indicates the opcode OP_PUSHDATA1. According to that opcode, the next byte indicates the length of the data (in this case 0x69; 105 decimal), followed by the data of the given length that should be pushed onto the stack.

Based on everything previously written, scriptSig in human readable form looks like this:

OP_0
OP_PUSHBYTES_71 304402201c45383cc6e43202ed069e36184a97bf5dd489c6bea1372629540dea154c424902200a950b3557bba9ae9531237d46e6eb1afffd01eba989c3e53adaac443e5e2a2e01
OP_PUSHBYTES_71 3044022032a681fb77589ce1a29a84494a6f9cb19630fcd65480ff646f30d8b826980390022006dc71baba1142abb275bbf3613b2a13b347bac4d09d41ccd9b69b02c270d8c201
OP_PUSHDATA1
69 522103745aaaf364030720b2d14de50a3310eef521c91e36353dca20813713535c005a2102db8911b3989b43c43d8dd6e50459bd85c38faf3b2862eb78ef297002775a10bd210351e3f71b7cf9a5f5f86c1908fee02ebf5a1ed77b6748f7486505d155833645f253ae

Finally, it should be noted that since the P2SH output is consumed, the last push in scriptSig represents the redeem script. Therefore, the content of that last push (redeem script) is not only treated as data pushed onto the stack, but the content is also treated as a script with its opcodes and data.

Precisely because of this, the following content (the last push in scriptSig - redeem script)

522103745aaaf364030720b2d14de50a3310eef521c91e36353dca20813713535c005a2102db8911b3989b43c43d8dd6e50459bd85c38faf3b2862eb78ef297002775a10bd210351e3f71b7cf9a5f5f86c1908fee02ebf5a1ed77b6748f7486505d155833645f253ae

does not only indicate data, but is itself a script with opcodes and data. The way this was decoded, that is, presented in human readable format is as follows (taken from the site mempool.space):

OP_PUSHNUM_2
OP_PUSHBYTES_33
03745aaaf364030720b2d14de50a3310eef521c91e36353dca20813713535c005a
OP_PUSHBYTES_33
02db8911b3989b43c43d8dd6e50459bd85c38faf3b2862eb78ef297002775a10bd
OP_PUSHBYTES_33
0351e3f71b7cf9a5f5f86c1908fee02ebf5a1ed77b6748f7486505d155833645f2
OP_PUSHNUM_3
OP_CHECKMULTISIG

Everything previously written represents the way in which the raw scriptSig is decoded into a human readable format, and the way in which bitcoin nodes know how to properly execute the script.

dassd
  • 1,069
  • 1
  • 4
  • 21