user14475: 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

user14475: 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.

14475: <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>
 14475: <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>
