<p>In short the answer is this:</p>

<pre><code>InScript length                               : VarInt (1-9 bytes)
PushData operation of R/S/Hash_all/DER bytes  : OP_PUSH (1-9 bytes)
DER sequence type byte                        : 0x30
DER sequence length                           : 0x44-0x46
DER integer type                              : 0x02
DER integer length                            : 0x20-0x21
32 R bytes, left padded with 0x00 IF leftmost byte &gt;= 0x80 - hence varying lengths above.
DER integer type                              : 0x02
DER integer length                            : 0x20-0x21
32 S bytes, left padded with 0x00 IF leftmost byte &gt;= 0x80 - hence varying lengths above.
Sighash_All type byte                         : 0x01
PushData operation of publickey bytes         : OP_PUSH (1-9 bytes)
PubKey version/type byte                      : 0x04
Public key in 64 bytes of data - X and Y 32 bytes each
</code></pre>

<p>Answer taken from here:
<a href="https://bitcointalk.org/index.php?topic=653313.0" rel="nofollow">https://bitcointalk.org/index.php?topic=653313.0</a></p>

<p>After looking at it becomes pretty obvious that DER was a mistake on Satoshis part and something provided to him by OpenSSL.</p>

<p>I mean why encode unsigned integers as signed - then pad them to make them unsigned again.</p>

<p>Why these sequence and length definitions when we already know the length from the push byte op - why DER encode at all when its ALWAYS 32 bytes R followed by 32 bytes S?</p>

<p>Clearly its pretty silly.</p>

CC BY-SA 3.0
2014-12-14T02:49:19.243Z
More about OP_Push:
http://bitcoin.stackexchange.com/questions/29591/i-cannot-see-the-expected-op-code-in-transactions

More about VarInt:
https://en.bitcoin.it/wiki/Protocol_specification#Variable_length_integer
Martin Clemens Bloch
CC BY-SA 3.0
2014-12-14T06:05:43.717Z
I think Satoshi used this DER-encoding just to pass the value to standard ECDSA_* methods from openSSL without any additional actions. And this allow changing (hard-fork) algorithm in future: we still have 255 prefixes (0x30 is in use for current).
amaclin
CC BY-SA 3.0
2014-12-14T02:35:07.357Z
2014-12-14T02:54:07.153Z
2014-12-14T02:54:07.153Z
Martin Clemens Bloch
<p>For Pay-to-Pubkey Hash, the standard claim script is two "push data" operations:</p>

<ol>
<li>Signature: Approximately 71-bytes of DER-encoded sequence of R followed by S, then one additional byte for the <a href="https://en.bitcoin.it/wiki/OP_CHECKSIG#Hashtype_SIGHASH_ALL_.28default.29" rel="nofollow">hashtype</a>.</li>
<li>The public key that hashes to the value specified by the previous output and is also used during signature verification.</li>
</ol>

CC BY-SA 3.0
2014-12-14T02:15:42.143Z
Ok so "DER encoded" is woefully inadequate. Its not a function people can call, but a certain pre-established encoding scheme.
I have to mark your question as a non-answer and post my own.
Martin Clemens Bloch
CC BY-SA 3.0
2014-12-14T02:43:55.623Z
In my answer you can see for instance that it has been chosen to encode R and S as integers. Yes its DER encoded, but HOW? Someone who didn't know would have used the DER type for byte data!
I asked for details and I did not get it - hence this is a non answer.
Martin Clemens Bloch
CC BY-SA 3.0
2014-04-28T10:06:11.253Z
2014-04-28T10:06:11.253Z
Joe Amenta
<p>With reference to this:
<a href="https://en.bitcoin.it/wiki/Transactions#Pay-to-PubkeyHash" rel="nofollow">https://en.bitcoin.it/wiki/Transactions#Pay-to-PubkeyHash</a></p>

<p>It would seem the claim script is simply the signature consisting of S and R and the public key.</p>

<p>However I know at least the signature gets DER encoded, which is fine I found a library for that, but I don't know the details. For instance is it:
DER(S,R)+pubkey, DER(R,S)+pubkey or DER(S+R+pubkey) and so on, there are many permutations etc.?</p>

<p>I'm looking for something like this where you can see what each byte is supposed to be:
<a href="https://en.bitcoin.it/wiki/Protocol_specification" rel="nofollow">https://en.bitcoin.it/wiki/Protocol_specification</a></p>

<transactions><script><raw-transaction>
What is the format of the standard claim script?
Martin Clemens Bloch
# What is the format of the standard claim script?

(Asked by: username_0 on 2014-04-28)

With reference to this:
<https://en.bitcoin.it/wiki/Transactions#Pay-to-PubkeyHash>

It would seem the claim script is simply the signature consisting of S and R and the public key.

However I know at least the signature gets DER encoded, which is fine I found a library for that, but I don't know the details. For instance is it:
DER(S,R)+pubkey, DER(R,S)+pubkey or DER(S+R+pubkey) and so on, there are many permutations etc.?

I'm looking for something like this where you can see what each byte is supposed to be:
<https://en.bitcoin.it/wiki/Protocol_specification>

**Tags:** transactions, script, raw-transaction


---

## 2 answers

### Answer by username_0 on 2014-12-14. Score: 1 | Accepted answer

In short the answer is this:

```
InScript length                               : VarInt (1-9 bytes)
PushData operation of R/S/Hash_all/DER bytes  : OP_PUSH (1-9 bytes)
DER sequence type byte                        : 0x30
DER sequence length                           : 0x44-0x46
DER integer type                              : 0x02
DER integer length                            : 0x20-0x21
32 R bytes, left padded with 0x00 IF leftmost byte >= 0x80 - hence varying lengths above.
DER integer type                              : 0x02
DER integer length                            : 0x20-0x21
32 S bytes, left padded with 0x00 IF leftmost byte >= 0x80 - hence varying lengths above.
Sighash_All type byte                         : 0x01
PushData operation of publickey bytes         : OP_PUSH (1-9 bytes)
PubKey version/type byte                      : 0x04
Public key in 64 bytes of data - X and Y 32 bytes each

```

Answer taken from here:
<https://bitcointalk.org/index.php?topic=653313.0>

After looking at it becomes pretty obvious that DER was a mistake on Satoshis part and something provided to him by OpenSSL.

I mean why encode unsigned integers as signed - then pad them to make them unsigned again.

Why these sequence and length definitions when we already know the length from the push byte op - why DER encode at all when its ALWAYS 32 bytes R followed by 32 bytes S?

Clearly its pretty silly.

> **Comments:**
> **username_0**: More about OP_Push: http://bitcoin.stackexchange.com/questions/29591/i-cannot-see-the-expected-op-code-in-transactions  More about VarInt: https://en.bitcoin.it/wiki/Protocol_specification#Variable_length_integer  
> **username_1**: I think Satoshi used this DER-encoding just to pass the value to standard ECDSA_* methods from openSSL without any additional actions. And this allow changing (hard-fork) algorithm in future: we still have 255 prefixes (0x30 is in use for current).  

---

### Answer by username_2 on 2014-04-28. Score: 0

For Pay-to-Pubkey Hash, the standard claim script is two "push data" operations:

1. Signature: Approximately 71-bytes of DER-encoded sequence of R followed by S, then one additional byte for the [hashtype](https://en.bitcoin.it/wiki/OP_CHECKSIG#Hashtype_SIGHASH_ALL_.28default.29).
2. The public key that hashes to the value specified by the previous output and is also used during signature verification.

> **Comments:**
> **username_0**: Ok so "DER encoded" is woefully inadequate. Its not a function people can call, but a certain pre-established encoding scheme. I have to mark your question as a non-answer and post my own.  
> **username_0**: In my answer you can see for instance that it has been chosen to encode R and S as integers. Yes its DER encoded, but HOW? Someone who didn't know would have used the DER type for byte data! I asked for details and I did not get it - hence this is a non answer.  

---

