<p>the signature: 483045022100d52330113ccd033ccb1aaa3b759e9696c216e802922e5f1902cd5ada69c612e5022057880205319dccb05eebbe34323a852ee82653f09f81253ddccd08a810e9d42d01</p>

<p>and it's decomposition:</p>

<pre><code>  ##################################################################
  ### tcls_in_sig_script.sh: decode SIG_script OPCODES from a TX ###
  ##################################################################
    48: OP_DATA_0x48:     push hex 48 (decimal 72) bytes as data
    30: OP_SEQUENCE_0x30: type tag indicating SEQUENCE, begin sigscript
    45: OP_LENGTH_0x45:   length of R + S
    02: OP_INT_0x02:      type tag indicating INTEGER
    21: OP_LENGTH_0x21:   this is SIG R
        00D52330113CCD03:3CCB1AAA3B759E96
        96C216E802922E5F:1902CD5ADA69C612
        E5
    02: OP_INT_0x02:      type tag indicating INTEGER
    20: OP_LENGTH_0x20:   this is SIG S
        57880205319DCCB0:5EEBBE34323A852E
        E82653F09F81253D:DCCD08A810E9D42D
    01: OP_SIGHASHALL:    this terminates the ECDSA signature (ASN1-DER structure)
</code></pre>

CC BY-SA 3.0
2017-08-06T07:40:51.363Z
2017-08-06T07:40:51.363Z
pebwindkraft
<blockquote>
  <p>3045022100d52330113ccd033ccb1aaa3b759e9696c216e802922e5f1902cd5ada69c612e5022057880205319dccb05eebbe34323a852ee82653f09f81253ddccd08a810e9d42d01 </p>
</blockquote>

<p>is an ECDSA signature with the sender's key.</p>

<blockquote>
  <p>03e5b9f0bb669b289efb8d2826487a24ef5f3985624c8bc3a3e34f6bd54e080b27</p>
</blockquote>

<p>is the sender's public key (whose hash is stored in the address the coins were previously sent to).</p>

<p>However, in order to interpret these, you need to look at the output being spent, which is:</p>

<blockquote>
  <p>OP_DUP OP_HASH160 6ffdc2e9e69434a7832208db5a6148c67563e8ae OP_EQUALVERIFY OP_CHECKSIG </p>
</blockquote>

<p>Which is a script that takes as input a public key and a signature, checks whether the hash of the public key is <code>6ffdc2e9e69434a7832208db5a6148c67563e8ae</code>, and then verifies the signature against that public key.</p>

<p>In general, in order to know what is what in a scriptSig, you need to look at the output being spent. The output gives the conditions under which it can be spent (in the form of a script), and the input just contains the "variables" passed into the output's verification routine.</p>

CC BY-SA 3.0
2017-08-05T21:15:21.453Z
Thank you, that does help some, but aren't like the first certain number of numbers referencing something in particular, and then there are like 2-3 other parts within that? That's what I'm curious about in this question.  You said the input just contains "variables", which parts of it are the variables and what variables are they?
Mine
CC BY-SA 3.0
2017-08-05T21:22:00.777Z
I'll add another answer for that.
Pieter Wuille
CC BY-SA 3.0
2017-08-05T20:43:55.063Z
2017-08-05T20:43:55.063Z
Pieter Wuille
<blockquote>
  <p>3045022100d52330113ccd033ccb1aaa3b759e9696c216e802922e5f1902cd5ada69c612e5022057880205319dccb05eebbe34323a852ee82653f09f81253ddccd08a810e9d42d01</p>
</blockquote>

<p>Is a DER encoded ECDSA signature. I'll break it down:</p>

<blockquote>
  <p>30</p>
</blockquote>

<p>indicates that a compound structure follows (ECDSA signatures are treated as a compound of 2 integers, r and s)</p>

<blockquote>
  <p>45</p>
</blockquote>

<p>is the total length of the compound structure (excluding the 2 header bytes, 30 45), 69.</p>

<blockquote>
  <p>02</p>
</blockquote>

<p>the start of the contents of the compound structure, 02 indicates an integer (the signature's r value)</p>

<blockquote>
  <p>21</p>
</blockquote>

<p>of 33 bytes</p>

<blockquote>
  <p>00d52330113ccd033ccb1aaa3b759e9696c216e802922e5f1902cd5ada69c612e5</p>
</blockquote>

<p>the integer's value encoded in 33 big-endian bytes. The first byte is zero, as without it, it would be interpreted as a negative number (see 2's complement notation).</p>

<blockquote>
  <p>02</p>
</blockquote>

<p>another integer follows (s)</p>

<blockquote>
  <p>20</p>
</blockquote>

<p>of 32 bytes</p>

<blockquote>
  <p>57880205319dccb05eebbe34323a852ee82653f09f81253ddccd08a810e9d42d</p>
</blockquote>

<p>the 32 bytes encoding the s value</p>

<blockquote>
  <p>01</p>
</blockquote>

<p>this is a sighash byte appended by Bitcoin, and is not technically part of the ECDSA signature. As such, it's not counted as part of the length 69 (byte 45) at the start. It indicates what fields of the transaction are signed. 01 means "all".</p>

CC BY-SA 3.0
2017-08-05T22:13:16.450Z
That was fantastic!  Just one last part; are are these values always the same number of hex characters?  IE: are the "02"'s that indicate an integer always represented in the input scripts in bitcoin transactions by a two digit number?  Can I basically look at other Bitcoin input scrypts for transactions and just count the number of hex numbers/letters to determine which part is which?  The r and s values in this example appear to be 64 hex characters each is that always the case?
Mine
CC BY-SA 3.0
2017-08-05T22:30:57.513Z
Yes, only the length bytes may differ slightly.
Pieter Wuille
CC BY-SA 3.0
2017-08-05T22:42:45.517Z
What is the "length bytes" compared to the actual number of hex characters?
Mine
CC BY-SA 3.0
2017-08-06T00:25:58.553Z
+1 on both your answers for a very clear and detailed explanation :)
meshcollider
CC BY-SA 3.0
2017-08-06T02:02:23.177Z
The 45, 21, and 20 are length descriptors.
Pieter Wuille
CC BY-SA 3.0
2017-08-05T21:31:19.293Z
2017-08-05T21:31:19.293Z
Pieter Wuille
<p>All the terminologies I find seem rather confusing about what explains what and they usually miss a few steps.  </p>

<p>Example: Transaction 82d62d5f4e69ae8338c39b7ae2e1d33db59bdf62c869ded7344adc936bab8653</p>

<p>Found at <a href="https://blockchain.info/tx/82d62d5f4e69ae8338c39b7ae2e1d33db59bdf62c869ded7344adc936bab8653" rel="nofollow noreferrer">https://blockchain.info/tx/82d62d5f4e69ae8338c39b7ae2e1d33db59bdf62c869ded7344adc936bab8653</a></p>

<p>Shows an "Input Script" of:</p>

<p>3045022100d52330113ccd033ccb1aaa3b759e9696c216e802922e5f1902cd5ada69c612e5022057880205319dccb05eebbe34323a852ee82653f09f81253ddccd08a810e9d42d01
03e5b9f0bb669b289efb8d2826487a24ef5f3985624c8bc3a3e34f6bd54e080b27</p>

<p>So, what parts of that are what, and how can I tell which parts are what in this transaction's "input script" as well as others?</p>

<transactions><script><input>
What are the parts of a Bitcoin Transaction "Input" script?
Mine
# What are the parts of a Bitcoin Transaction "Input" script?

(Asked by: username_0 on 2017-08-05)

All the terminologies I find seem rather confusing about what explains what and they usually miss a few steps.

Example: Transaction 82d62d5f4e69ae8338c39b7ae2e1d33db59bdf62c869ded7344adc936bab8653

Found at <https://blockchain.info/tx/82d62d5f4e69ae8338c39b7ae2e1d33db59bdf62c869ded7344adc936bab8653>

Shows an "Input Script" of:

3045022100d52330113ccd033ccb1aaa3b759e9696c216e802922e5f1902cd5ada69c612e5022057880205319dccb05eebbe34323a852ee82653f09f81253ddccd08a810e9d42d01
03e5b9f0bb669b289efb8d2826487a24ef5f3985624c8bc3a3e34f6bd54e080b27

So, what parts of that are what, and how can I tell which parts are what in this transaction's "input script" as well as others?

**Tags:** transactions, script, input


---

## 3 answers

### Answer by username_2 on 2017-08-05. Score: 6 | Accepted answer

> 3045022100d52330113ccd033ccb1aaa3b759e9696c216e802922e5f1902cd5ada69c612e5022057880205319dccb05eebbe34323a852ee82653f09f81253ddccd08a810e9d42d01

Is a DER encoded ECDSA signature. I'll break it down:

> 30

indicates that a compound structure follows (ECDSA signatures are treated as a compound of 2 integers, r and s)

> 45

is the total length of the compound structure (excluding the 2 header bytes, 30 45), 69.

> 02

the start of the contents of the compound structure, 02 indicates an integer (the signature's r value)

> 21

of 33 bytes

> 00d52330113ccd033ccb1aaa3b759e9696c216e802922e5f1902cd5ada69c612e5

the integer's value encoded in 33 big-endian bytes. The first byte is zero, as without it, it would be interpreted as a negative number (see 2's complement notation).

> 02

another integer follows (s)

> 20

of 32 bytes

> 57880205319dccb05eebbe34323a852ee82653f09f81253ddccd08a810e9d42d

the 32 bytes encoding the s value

> 01

this is a sighash byte appended by Bitcoin, and is not technically part of the ECDSA signature. As such, it's not counted as part of the length 69 (byte 45) at the start. It indicates what fields of the transaction are signed. 01 means "all".

> **Comments:**
> **username_0**: That was fantastic!  Just one last part; are are these values always the same number of hex characters?  IE: are the "02"'s that indicate an integer always represented in the input scripts in bitcoin transactions by a two digit number?  Can I basically look at other Bitcoin input scrypts for transactions and just count the number of hex numbers/letters to determine which part is which?  The r and s values in this example appear to be 64 hex characters each is that always the case?  
> **username_2**: Yes, only the length bytes may differ slightly.  
> **username_0**: What is the "length bytes" compared to the actual number of hex characters?  
> **username_3**: +1 on both your answers for a very clear and detailed explanation :)  
> **username_2**: The 45, 21, and 20 are length descriptors.  

---

### Answer by username_1 on 2017-08-06. Score: 3

the signature: 483045022100d52330113ccd033ccb1aaa3b759e9696c216e802922e5f1902cd5ada69c612e5022057880205319dccb05eebbe34323a852ee82653f09f81253ddccd08a810e9d42d01

and it's decomposition:

```
  ##################################################################
  ### tcls_in_sig_script.sh: decode SIG_script OPCODES from a TX ###
  ##################################################################
    48: OP_DATA_0x48:     push hex 48 (decimal 72) bytes as data
    30: OP_SEQUENCE_0x30: type tag indicating SEQUENCE, begin sigscript
    45: OP_LENGTH_0x45:   length of R + S
    02: OP_INT_0x02:      type tag indicating INTEGER
    21: OP_LENGTH_0x21:   this is SIG R
        00D52330113CCD03:3CCB1AAA3B759E96
        96C216E802922E5F:1902CD5ADA69C612
        E5
    02: OP_INT_0x02:      type tag indicating INTEGER
    20: OP_LENGTH_0x20:   this is SIG S
        57880205319DCCB0:5EEBBE34323A852E
        E82653F09F81253D:DCCD08A810E9D42D
    01: OP_SIGHASHALL:    this terminates the ECDSA signature (ASN1-DER structure)

```


---

### Answer by username_2 on 2017-08-05. Score: 3

> 3045022100d52330113ccd033ccb1aaa3b759e9696c216e802922e5f1902cd5ada69c612e5022057880205319dccb05eebbe34323a852ee82653f09f81253ddccd08a810e9d42d01

is an ECDSA signature with the sender's key.

> 03e5b9f0bb669b289efb8d2826487a24ef5f3985624c8bc3a3e34f6bd54e080b27

is the sender's public key (whose hash is stored in the address the coins were previously sent to).

However, in order to interpret these, you need to look at the output being spent, which is:

> OP\_DUP OP\_HASH160 6ffdc2e9e69434a7832208db5a6148c67563e8ae OP\_EQUALVERIFY OP\_CHECKSIG

Which is a script that takes as input a public key and a signature, checks whether the hash of the public key is `6ffdc2e9e69434a7832208db5a6148c67563e8ae`, and then verifies the signature against that public key.

In general, in order to know what is what in a scriptSig, you need to look at the output being spent. The output gives the conditions under which it can be spent (in the form of a script), and the input just contains the "variables" passed into the output's verification routine.

> **Comments:**
> **username_0**: Thank you, that does help some, but aren't like the first certain number of numbers referencing something in particular, and then there are like 2-3 other parts within that? That's what I'm curious about in this question.  You said the input just contains "variables", which parts of it are the variables and what variables are they?  
> **username_2**: I'll add another answer for that.  

---

