Is there a set length that a signature can be?

Question

I'm reading this page which describes the following method of creating a stack:

OP_0 <A sig> <B sig> OP_2 <A pubkey> <B pubkey> <C pubkey> OP_3

Sig Stack       Pubkey Stack  (Actually a single stack)
---------       ------------
B sig           C pubkey
A sig           B pubkey
OP_0            A pubkey

1. B sig compared to C pubkey (no match)
2. B sig compared to B pubkey (match #1)
3. A sig compared to A pubkey (match #2)

Success: two matches found

My question is how does the theoretical program know where to separate the two signatures and the public keys?

Answer 1

Within the script language there are two types of instructions:

• Opcodes
• Data pushes

Data pushes are encoded by a single byte n (with value between 0 and 75 inclusive), followed by n bytes (the data to be pushed). Its effect during execution is pushing that n-byte value onto the stack.

Any other byte value (so between 76 and 255 inclusive) denotes an opcode. Most opcodes are just a single byte, except for OP_PUSHDATA1, OP_PUSHDATA2, and OP_PUSHDATA4, which are used for pushing larger data elements than 75 bytes, but are still considered opcodes.

In the notation you cite above, <X> is a shorthand for "data push of X". In the actual byte encoding, that means it is prefixed by its length. So specifically, OP_0 <A sig> <B sig> OP_2 <A pubkey> <B pubkey> <C pubkey> OP_3, e.g. when A sig is 71 bytes and B sig is 72 bytes (and the pubkeys are all 33 bytes):

• 0x00 (OP_0)
• 0x47 (data push of length 71 follows)
• A sig's 71 bytes
• 0x48 (data push of length 72 follows)
• B sig's 72 bytes
• 0x52 (OP_2)
• 0x21 (data push of length 33 follows)
• A pubkey's 33 bytes
• 0x21 (data push of length 33 follows)
• B pubkey's 33 bytes
• 0x21 (data push of length 33 follows)
• C pubkey's 33 bytes
• 0x53 (OP_3)

Note that in the example you're referring to, this whole sequence isn't actually realized as a single script. The public keys would typically be in the scriptPubKey or redeemScript (and probably followed by OP_CHECKMULTISIG), while the signatures would be in the scriptSig. It's only during spending that both get executed in order, making it equivalent to having this single script.

Note also that the script language itself does not know or care about the distinction between public keys and signatures - they're just data elements on a stack. It's the OP_CHECKMULTISIG opcode that follows which will be interpreting the data on the stack (and it's guided by the 2 and 3 pushed by OP_2 and OP_3 to know this is a 2-of-3 multisig, thus interpreting the other elements on the stack as 3 public keys and 2 signatures).

Now to answer the question in your title: since BIP66 took effect in 2015, ECDSA signatures can be at most 73 bytes.

Answer 2

The serializations of pubkeys and signatures are variable length. Their data push operations explicitly tell you how many bytes are pushed. Then, the serialization itself often includes further length instructions. The serialization of an ECDSA signature is usually 71 or 72 bytes (incl. sighash flag, not including its own length indicator, high-s signatures can be 73 bytes), Schnorr signatures are 64 bytes. Pubkeys are 33 bytes, uncompressed pubkeys are 65 bytes.