What is the format of the standard claim script?

2

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

Martin Clemens Bloch

Posted 2014-04-28T06:52:12.320

Reputation: 137

Answers

1

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.

Martin Clemens Bloch

Posted 2014-04-28T06:52:12.320

Reputation: 137

– Martin Clemens Bloch – 2014-12-14T02:49:19.243

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 – 2014-12-14T06:05:43.717

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.
  2. The public key that hashes to the value specified by the previous output and is also used during signature verification.

Joe Amenta

Posted 2014-04-28T06:52:12.320

Reputation: 381

1Ok 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 – 2014-12-14T02:15:42.143

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 – 2014-12-14T02:43:55.623

Asked: 2014-04-28T06:52:12.320

Viewed: 214 times

Active: 2014-12-14T02:54:07.153