<p>Within the script language there are two types of instructions:</p>
<ul>
<li>Opcodes</li>
<li>Data pushes</li>
</ul>
<p>Data pushes are encoded by a single byte <code>n</code> (with value between 0 and 75 inclusive), followed by <em>n</em> bytes (the data to be pushed). Its effect during execution is pushing that n-byte value onto the stack.</p>
<p>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.</p>
<p>In the notation you cite above, <code>&lt;X&gt;</code> is a shorthand for &quot;data push of X&quot;. In the actual byte encoding, that means it is prefixed by its length. So specifically, <code>OP_0 &lt;A sig&gt; &lt;B sig&gt; OP_2 &lt;A pubkey&gt; &lt;B pubkey&gt; &lt;C pubkey&gt; OP_3</code>, e.g. when <code>A sig</code> is 71 bytes and <code>B sig</code> is 72 bytes (and the pubkeys are all 33 bytes):</p>
<ul>
<li><code>0x00</code> (OP_0)</li>
<li><code>0x47</code> (data push of length 71 follows)</li>
<li><code>A sig</code>'s 71 bytes</li>
<li><code>0x48</code> (data push of length 72 follows)</li>
<li><code>B sig</code>'s 72 bytes</li>
<li><code>0x52</code> (OP_2)</li>
<li><code>0x21</code> (data push of length 33 follows)</li>
<li><code>A pubkey</code>'s 33 bytes</li>
<li><code>0x21</code> (data push of length 33 follows)</li>
<li><code>B pubkey</code>'s 33 bytes</li>
<li><code>0x21</code> (data push of length 33 follows)</li>
<li><code>C pubkey</code>'s 33 bytes</li>
<li><code>0x53</code> (OP_3)</li>
</ul>
<p>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 <code>OP_CHECKMULTISIG</code>), 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.</p>
<p>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 <code>OP_CHECKMULTISIG</code> 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).</p>
<p>Now to answer the question in your title: since <a href="https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki" rel="nofollow noreferrer">BIP66</a> took effect in 2015, ECDSA signatures can be at most 73 bytes.</p>

CC BY-SA 4.0
2023-03-07T15:13:53.327Z
2023-03-07T15:23:55.910Z
2023-03-07T15:23:55.910Z
Pieter Wuille
<p>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.</p>

CC BY-SA 4.0
2023-03-07T15:18:39.807Z
2023-03-07T15:34:51.980Z
2023-03-07T15:34:51.980Z
Murch
<p>I'm reading <a href="https://developer.bitcoin.org/reference/transactions.html#raw-transaction-format" rel="nofollow noreferrer">this page</a> which describes the following method of creating a stack:</p>
<pre><code>OP_0 &lt;A sig&gt; &lt;B sig&gt; OP_2 &lt;A pubkey&gt; &lt;B pubkey&gt; &lt;C pubkey&gt; 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
</code></pre>
<p>My question is how does the theoretical program know where to separate the two signatures and the public keys?</p>

CC BY-SA 4.0
2023-03-07T15:20:27.237Z
Related: https://bitcoin.stackexchange.com/q/77191/5406
Murch
<transactions><multi-signature><signature><serialization>
Is there a set length that a signature can be?
bitcoinluvr6969
# Is there a set length that a signature can be?

(Asked by: username_0 on 2023-03-07)

I'm reading [this page](https://developer.bitcoin.org/reference/transactions.html#raw-transaction-format) 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?

**Tags:** transactions, multi-signature, signature, serialization

> **Comments:**
> **username_1**: Related: https://bitcoin.stackexchange.com/q/77191/5406  

---

## 2 answers

### Answer by username_2 on 2023-03-07. Score: 3 | Accepted answer

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](https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki) took effect in 2015, ECDSA signatures can be at most 73 bytes.


---

### Answer by username_1 on 2023-03-07. Score: 1

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.


---

