<p>This is ASN.1 DER encoding. This is NOT the public key, but the ECDSA signature.</p>

<p>30 45 means set of data with 0x45 bytes following</p>

<p>02 20 means big integer with 0x20 bytes (this is big endian value "r")</p>

<p>Skip 0x20 bytes...</p>

<p>02 21 means big integer with 0x21 bytes ("s")</p>

<p>In other words:</p>

<pre><code>r = 0x7fc09b1c29548feceb349aa1450874f97e7e9b9c0084e5917380151258236633,
s = 0x808b8ca131480afcdef328c961131be389489fdc07e5201a807c47a6b94b18f2
</code></pre>

<p>The final byte 0x01 means SIGHASH_ALL (default)</p>

CC BY-SA 3.0
2014-03-09T03:50:15.343Z
This is technically correct.  ASM is not "encryption" like the OP writes, as such it can't be decrypted.  It is the binary (ones an zeros) of a file that is converted to letters and numbers for humans to read.  The main purpose of this ASM is to be read by a computer.
makerofthings7
CC BY-SA 3.0
2014-03-09T03:50:43.400Z
Note: reason "s" takes 0x21 bytes is that leading byte 0x80 has bit 7 set to 1, so an extra leading 0x00 byte is added to indicate positive sign, for interoperability with OpenSSL.
uminatsu
CC BY-SA 3.0
2014-03-09T03:58:10.867Z
Is the encoding of s really 21 bytes for the DER encoded signature, or is it variable based on the value of the second-to-last bit?  If s is variable, I'd say it fluctuates between 21 and 20 bytes.  R should be the same way at least 1 in every 1,000,000 random signatures (in my experience)
makerofthings7
CC BY-SA 3.0
2014-03-09T04:03:08.290Z
Yes it is variable based on the most significant bit. Both r and s can be 0x20 or 0x21 bytes.
uminatsu
CC BY-SA 3.0
2014-03-09T04:05:08.103Z
You may be interested in these test cases for the recoverable signature format that may be less than 32 bytes http://bitcoin.stackexchange.com/a/22881/1878
makerofthings7
CC BY-SA 3.0
2014-03-09T03:27:12.307Z
2014-03-09T03:39:47.330Z
2014-03-09T03:39:47.330Z
uminatsu
<p>I suppose you are talking about the scripts. The <code>scriptPubKey</code> script in the output is indeed more readable because it contains OpCodes like <code>OP_HASH160</code> and <code>OP_CHECKSIG</code>. However, the input scripts are in their original form as well.</p>

<p>As you can see in <a href="https://en.bitcoin.it/wiki/Transactions#Pay-to-PubkeyHash" rel="nofollow">the specification of the pay-to-pubkey-hash</a> transactions scripts (the regular scripts to pay to Bitcoin address), the input input script only consists of two data elements, the signature and the public key. So what you see in the input fields "hex" and "asm" are the signature and the public key of the address the input spends funds from. The reason that these two values vary slightly is because they are encoded differently, but that doesn't matter all that much.</p>

<p>Basically, they are not encrypted or so, they just contain little to no relevant information.</p>

CC BY-SA 3.0
2014-03-08T02:17:42.430Z
2014-03-08T02:17:42.430Z
Steven Roose
<p>Here's what I get from Mintcoin client for some transaction. I have decoded output, but 
how can I decrypt <strong>asm</strong> in transaction input? I know it's a public key. Here it is: </p>

<pre><code>304502207fc09b1c29548feceb349aa1450874f97e7e9b9c0084e5917380151258236633022100808b8ca131480afcdef328c961131be389489fdc07e5201a807c47a6b94b18f201
</code></pre>

<p><img src="https://i.sstatic.net/zstd2.png" alt="enter image description here"></p>

CC BY-SA 3.0
2014-03-15T15:17:19.420Z
I merged your previous question with the almost exact same text into this one. Please edit questions if you want to improve them instead of just asking them again.
Murch
<transactions>
How to decrypt asm?
user13993
# How to decrypt asm?

(Asked by: username_0 on 2014-03-09)

Here's what I get from Mintcoin client for some transaction. I have decoded output, but
how can I decrypt **asm** in transaction input? I know it's a public key. Here it is:

```
304502207fc09b1c29548feceb349aa1450874f97e7e9b9c0084e5917380151258236633022100808b8ca131480afcdef328c961131be389489fdc07e5201a807c47a6b94b18f201

```

![enter image description here](https://i.sstatic.net/zstd2.png)

**Tags:** transactions

> **Comments:**
> **username_1**: I merged your previous question with the almost exact same text into this one. Please edit questions if you want to improve them instead of just asking them again.  

---

## 2 answers

### Answer by username_2 on 2014-03-09. Score: 1

This is ASN.1 DER encoding. This is NOT the public key, but the ECDSA signature.

30 45 means set of data with 0x45 bytes following

02 20 means big integer with 0x20 bytes (this is big endian value "r")

Skip 0x20 bytes...

02 21 means big integer with 0x21 bytes ("s")

In other words:

```
r = 0x7fc09b1c29548feceb349aa1450874f97e7e9b9c0084e5917380151258236633,
s = 0x808b8ca131480afcdef328c961131be389489fdc07e5201a807c47a6b94b18f2

```

The final byte 0x01 means SIGHASH\_ALL (default)

> **Comments:**
> **username_3**: This is technically correct.  ASM is not "encryption" like the OP writes, as such it can't be decrypted.  It is the binary (ones an zeros) of a file that is converted to letters and numbers for humans to read.  The main purpose of this ASM is to be read by a computer.  
> **username_2**: Note: reason "s" takes 0x21 bytes is that leading byte 0x80 has bit 7 set to 1, so an extra leading 0x00 byte is added to indicate positive sign, for interoperability with OpenSSL.  
> **username_3**: Is the encoding of s really 21 bytes for the DER encoded signature, or is it variable based on the value of the second-to-last bit?  If s is variable, I'd say it fluctuates between 21 and 20 bytes.  R should be the same way at least 1 in every 1,000,000 random signatures (in my experience)  
> **username_2**: Yes it is variable based on the most significant bit. Both r and s can be 0x20 or 0x21 bytes.  
> **username_3**: You may be interested in these test cases for the recoverable signature format that may be less than 32 bytes http://bitcoin.stackexchange.com/a/22881/1878  

---

### Answer by username_4 on 2014-03-08. Score: 0

I suppose you are talking about the scripts. The `scriptPubKey` script in the output is indeed more readable because it contains OpCodes like `OP_HASH160` and `OP_CHECKSIG`. However, the input scripts are in their original form as well.

As you can see in [the specification of the pay-to-pubkey-hash](https://en.bitcoin.it/wiki/Transactions#Pay-to-PubkeyHash) transactions scripts (the regular scripts to pay to Bitcoin address), the input input script only consists of two data elements, the signature and the public key. So what you see in the input fields "hex" and "asm" are the signature and the public key of the address the input spends funds from. The reason that these two values vary slightly is because they are encoded differently, but that doesn't matter all that much.

Basically, they are not encrypted or so, they just contain little to no relevant information.


---

