<p>I would decode this in two steps:</p>
<ol>
<li><p>step through the bytes and interpret each byte according to <a href="https://en.bitcoin.it/wiki/Script" rel="nofollow noreferrer">https://en.bitcoin.it/wiki/Script</a></p>
</li>
<li><p>look at the documentation for multisig to put a name to each pushed data item.</p>
</li>
</ol>
<hr />
<p>We can do the first step by hand quite easily</p>
<div class="s-table-container">
<table class="s-table">
<thead>
<tr>
<th>Hex</th>
<th>meaning</th>
</tr>
</thead>
<tbody>
<tr>
<td><code>00</code></td>
<td>OP_FALSE or OP_ZERO, pushes 0x00 onto the stack</td>
</tr>
<tr>
<td><code>47</code></td>
<td>push the next 0x47 (71 decimal) bytes onto the stack</td>
</tr>
<tr>
<td><code>304402201c45383c</code> <code>c6e43202ed069e36</code> <code>184a97bf5dd489c6</code> <code>bea1372629540dea</code> <code>154c424902200a95</code> <code>0b3557bba9ae9531</code> <code>237d46e6eb1afffd</code> <code>01eba989c3e53ada</code> <code>ac443e5e2a2e01</code></td>
<td>pushed onto stack</td>
</tr>
<tr>
<td><code>47</code></td>
<td>push the next 0x47 (71 decimal) bytes onto the stack</td>
</tr>
<tr>
<td><code>3044022032a681fb</code> <code>77589ce1a29a8449</code> <code>4a6f9cb19630fcd6</code> <code>5480ff646f30d8b8</code> <code>26980390022006dc</code> <code>71baba1142abb275</code> <code>bbf3613b2a13b347</code> <code>bac4d09d41ccd9b6</code> <code>9b02c270d8c201</code></td>
<td>pushed onto stack</td>
</tr>
<tr>
<td><code>4c</code></td>
<td>OP_PUSHDATA1, the next one byte contains the number of following bytes to be pushed onto stack</td>
</tr>
<tr>
<td><code>69</code></td>
<td>... push the next 0x69 (105 decimal) bytes onto the stack</td>
</tr>
<tr>
<td><code>522103745aaaf364</code> <code>030720b2d14de50a</code> <code>3310eef521c91e36</code> <code>353dca2081371353</code> <code>5c005a2102db8911</code> <code>b3989b43c43d8dd6</code> <code>e50459bd85c38faf</code> <code>3b2862eb78ef2970</code> <code>02775a10bd210351</code> <code>e3f71b7cf9a5f5f8</code> <code>6c1908fee02ebf5a</code> <code>1ed77b6748f74865</code> <code>05d155833645f253</code> <code>ae</code></td>
<td>pushed onto stack</td>
</tr>
</tbody>
</table>
</div>
<p>We can see that the two pushes of 71 bytes start with the typical byte sequences expected of a <a href="https://bitcoin.stackexchange.com/q/24948/13866">DER encoded signature</a>.</p>
<p>The last push of 105 bytes is also a script (called the redeem script)</p>
<div class="s-table-container">
<table class="s-table">
<thead>
<tr>
<th>Hex</th>
<th>meaning</th>
</tr>
</thead>
<tbody>
<tr>
<td><code>52</code></td>
<td>OP_2, push 0x02 onto stack</td>
</tr>
<tr>
<td><code>21</code></td>
<td>push next 0x21 (33 decimal) bytes onto stack</td>
</tr>
<tr>
<td><code>03745aaaf3640307</code> <code>20b2d14de50a3310</code> <code>eef521c91e36353d</code> <code>ca20813713535c00</code> <code>5a</code></td>
<td>pushed data. The length is typical of a pubkey</td>
</tr>
<tr>
<td><code>21</code></td>
<td>push next 0x21 (33 decimal) bytes onto stack</td>
</tr>
<tr>
<td><code>02db8911b3989b43</code> <code>c43d8dd6e50459bd</code> <code>85c38faf3b2862eb</code> <code>78ef297002775a10</code> <code>bd</code></td>
<td>pushed data</td>
</tr>
<tr>
<td><code>21</code></td>
<td>push next 0x21 (33 decimal) bytes onto stack</td>
</tr>
<tr>
<td><code>0351e3f71b7cf9a5</code> <code>f5f86c1908fee02e</code> <code>bf5a1ed77b6748f7</code> <code>486505d155833645</code> <code>f2</code></td>
<td>pushed data</td>
</tr>
<tr>
<td><code>53</code></td>
<td>OP_3, push 0x03 onto stack</td>
</tr>
<tr>
<td><code>ae</code></td>
<td>OP_CHECKMULTISIG</td>
</tr>
</tbody>
</table>
</div>
<p>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 <a href="https://bitcoin.stackexchange.com/q/51498/13866">2of2 multisig - redeem script required</a></p>
<p>Anyway by inspection we can easily see that the script contains two signatures and three public keys.</p>

CC BY-SA 4.0
2023-10-07T10:39:18.437Z
2023-10-07T11:06:19.910Z
2023-10-07T11:06:19.910Z
RedGrittyBrick
<p>Bitcoin bases its logic of payment (locking) and spending (unlocking) funds on a <code>scripting language</code> and a <code>stack</code>. 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 <code>0xae</code> has a special meaning and indicates the OP_CHECKMULTISIG opcode. You can find a list of all opcodes <a href="https://en.bitcoin.it/wiki/Script" rel="nofollow noreferrer">here</a>.</p>
<p>Looking at the example you provided, the raw scriptSig looks like this (opcodes are in bold, the rest is data):</p>
<blockquote>
<p><strong>0047</strong>304402201c45383cc6e43202ed069e36184a97bf5dd489c6bea1372629540dea154c424902200a950b3557bba9ae9531237d46e6eb1afffd01eba989c3e53adaac443e5e2a2e01<strong>47</strong>3044022032a681fb77589ce1a29a84494a6f9cb19630fcd65480ff646f30d8b826980390022006dc71baba1142abb275bbf3613b2a13b347bac4d09d41ccd9b69b02c270d8c201<strong>4c</strong>69522103745aaaf364030720b2d14de50a3310eef521c91e36353dca20813713535c005a2102db8911b3989b43c43d8dd6e50459bd85c38faf3b2862eb78ef297002775a10bd210351e3f71b7cf9a5f5f86c1908fee02ebf5a1ed77b6748f7486505d155833645f253ae</p>
</blockquote>
<p>Therefore, the first byte (<code>0x00</code>) represents one of the opcodes and indicates the operation <code>OP_0</code>, i.e. that it is necessary to push an empty array onto the stack. The next byte (<code>0x47</code>) 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 <code>0x47</code> (opcode) follows again, indicating the pushing of the next 71 bytes. This data is followed by the byte <code>0x4c</code>. The given byte indicates the opcode <code>OP_PUSHDATA1</code>. According to that opcode, the next byte indicates the length of the data (in this case <code>0x69</code>; 105 decimal), followed by the data of the given length that should be pushed onto the stack.</p>
<p>Based on everything previously written, scriptSig in human readable form looks like this:</p>
<blockquote>
<p><strong>OP_0</strong><br />
<strong>OP_PUSHBYTES_71</strong>
304402201c45383cc6e43202ed069e36184a97bf5dd489c6bea1372629540dea154c424902200a950b3557bba9ae9531237d46e6eb1afffd01eba989c3e53adaac443e5e2a2e01<br />
<strong>OP_PUSHBYTES_71</strong>
3044022032a681fb77589ce1a29a84494a6f9cb19630fcd65480ff646f30d8b826980390022006dc71baba1142abb275bbf3613b2a13b347bac4d09d41ccd9b69b02c270d8c201<br />
<strong>OP_PUSHDATA1</strong><br />
69
522103745aaaf364030720b2d14de50a3310eef521c91e36353dca20813713535c005a2102db8911b3989b43c43d8dd6e50459bd85c38faf3b2862eb78ef297002775a10bd210351e3f71b7cf9a5f5f86c1908fee02ebf5a1ed77b6748f7486505d155833645f253ae</p>
</blockquote>
<p>Finally, it should be noted that since the P2SH output is consumed, the last push in scriptSig represents the <code>redeem script</code>. Therefore, the content of that last push (<code>redeem script</code>) is not only treated as data pushed onto the stack, but the content is also treated as a script with its opcodes and data.</p>
<p>Precisely because of this, the following content (the last push in scriptSig - redeem script)</p>
<blockquote>
<p>522103745aaaf364030720b2d14de50a3310eef521c91e36353dca20813713535c005a2102db8911b3989b43c43d8dd6e50459bd85c38faf3b2862eb78ef297002775a10bd210351e3f71b7cf9a5f5f86c1908fee02ebf5a1ed77b6748f7486505d155833645f253ae</p>
</blockquote>
<p>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 <a href="https://mempool.space/tx/32e8677c968981549acc25f46641c74a3055d949c90bd22c15a5236bf92a622d" rel="nofollow noreferrer">mempool.space</a>):</p>
<blockquote>
<p><strong>OP_PUSHNUM_2</strong><br />
<strong>OP_PUSHBYTES_33</strong><br />
03745aaaf364030720b2d14de50a3310eef521c91e36353dca20813713535c005a<br />
<strong>OP_PUSHBYTES_33</strong><br />
02db8911b3989b43c43d8dd6e50459bd85c38faf3b2862eb78ef297002775a10bd<br />
<strong>OP_PUSHBYTES_33</strong><br />
0351e3f71b7cf9a5f5f86c1908fee02ebf5a1ed77b6748f7486505d155833645f2<br />
<strong>OP_PUSHNUM_3</strong><br />
<strong>OP_CHECKMULTISIG</strong></p>
</blockquote>
<p>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.</p>

CC BY-SA 4.0
2023-10-07T10:31:03.400Z
2023-10-07T10:37:08.970Z
2023-10-07T10:37:08.970Z
dassd
<p>In the transaction <a href="https://blockchain.info/tx/32e8677c968981549acc25f46641c74a3055d949c90bd22c15a5236bf92a622d" rel="nofollow noreferrer">https://blockchain.info/tx/32e8677c968981549acc25f46641c74a3055d949c90bd22c15a5236bf92a622d</a> the first input has the following SigScript</p>
<pre><code>0047304402201c45383cc6e43202ed069e36184a97bf5dd489c6bea1372629540dea154c424902200a950b3557bba9ae9531237d46e6eb1afffd01eba989c3e53adaac443e5e2a2e01473044022032a681fb77589ce1a29a84494a6f9cb19630fcd65480ff646f30d8b826980390022006dc71baba1142abb275bbf3613b2a13b347bac4d09d41ccd9b69b02c270d8c2014c69522103745aaaf364030720b2d14de50a3310eef521c91e36353dca20813713535c005a2102db8911b3989b43c43d8dd6e50459bd85c38faf3b2862eb78ef297002775a10bd210351e3f71b7cf9a5f5f86c1908fee02ebf5a1ed77b6748f7486505d155833645f253ae
</code></pre>
<p>Apparently this decodes to:</p>
<pre><code>       00
sig1   47304402201C45383CC6E43202ED069E36184A97BF5DD489C6BEA1372629540DEA154C424902200A950B3557BBA9AE9531237D46E6EB1AFFFD01EBA989C3E53ADAAC443E5E2A2E01
sig2   473044022032A681FB77589CE1A29A84494A6F9CB19630FCD65480FF646F30D8B826980390022006DC71BABA1142ABB275BBF3613B2A13B347BAC4D09D41CCD9B69B02C270D8C201
length 4C69
OP_2   52
pk1    21 03745AAAF364030720B2D14DE50A3310EEF521C91E36353DCA20813713535C005A
pk2    21 02DB8911B3989B43C43D8DD6E50459BD85C38FAF3B2862EB78EF297002775A10BD
pk3    21 0351E3F71B7CF9A5F5F86C1908FEE02EBF5A1ED77B6748F7486505D155833645F2
OP_3   53
check  AE
</code></pre>
<p>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.</p>

<signature>
Can someone explain how to get from SigScript to something readable
user2334659
# Can someone explain how to get from SigScript to something readable

(Asked by: username_0 on 2023-10-07)

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.

**Tags:** signature


---

## 2 answers

### Answer by username_1 on 2023-10-07. Score: 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](https://bitcoin.stackexchange.com/q/24948/13866).

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](https://bitcoin.stackexchange.com/q/51498/13866)

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


---

### Answer by username_2 on 2023-10-07. Score: 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](https://en.bitcoin.it/wiki/Script).

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

> **0047**304402201c45383cc6e43202ed069e36184a97bf5dd489c6bea1372629540dea154c424902200a950b3557bba9ae9531237d46e6eb1afffd01eba989c3e53adaac443e5e2a2e01**47**3044022032a681fb77589ce1a29a84494a6f9cb19630fcd65480ff646f30d8b826980390022006dc71baba1142abb275bbf3613b2a13b347bac4d09d41ccd9b69b02c270d8c201**4c**69522103745aaaf364030720b2d14de50a3310eef521c91e36353dca20813713535c005a2102db8911b3989b43c43d8dd6e50459bd85c38faf3b2862eb78ef297002775a10bd210351e3f71b7cf9a5f5f86c1908fee02ebf5a1ed77b6748f7486505d155833645f253ae

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](https://mempool.space/tx/32e8677c968981549acc25f46641c74a3055d949c90bd22c15a5236bf92a622d)):

> **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.


---

