<p>Bitcoin Script opcodes, and P2P variable-length integers are distinct concepts.</p>
<p>To push a 254-byte element in Bitcoin Script, use <code>OP_PUSHDATA1 0xfe</code> (followed by the 254 bytes to be pushed).</p>
<p>To encode e.g. that a transaction has 254 inputs, its varint encoding <code>0xfd 0xfe 0x00</code> would be used.</p>

CC BY-SA 4.0
2022-08-18T21:12:14.013Z
Thank you very much. I tried using `4cfe` but I'm not getting the transaction to parse. I added a concrete example to the question with a dummy scriptSig.
Darius
CC BY-SA 4.0
2022-08-18T21:53:23.437Z
Ah okay I got it, I guess what goes at the start of the scriptSig is not a OP_PUSHDATA operation but is instead a varint encoding of the scriptSig length. I put `0xfd` `0xfe` `0x00` in the length field instead and it works now I'm updating the question.
Darius
CC BY-SA 4.0
2022-08-19T11:53:46.117Z
Yes, the length of a script is not part of the script itself, and thus can't use script opcodes.
Pieter Wuille
CC BY-SA 4.0
2022-08-18T20:35:57.303Z
2022-08-18T20:35:57.303Z
Pieter Wuille
<p>From <a href="https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki#push-operators" rel="nofollow noreferrer">BIP62</a> I would expect to use <code>OP_PUSHDATA1</code> followed by uint8_t:</p>
<blockquote>
<p>Pushing 76 to 255 bytes must use OP_PUSHDATA1.</p>
</blockquote>
<p>But then from <a href="https://bitcoin.stackexchange.com/questions/101817/is-there-a-difference-between-op-pushbytes-and-op-pushdata">this answer</a>, the link to <a href="https://en.bitcoin.it/wiki/Protocol_documentation#Variable_length_integer" rel="nofollow noreferrer">variable-length integer</a> makes it seem that a value of 253 (0xfd) should be encoded by 0xFD followed by the length as uint16_t.</p>
<p><strong>EDIT-1</strong>: Here is a dummy transaction I am trying to get to parse.</p>
<p>Here I have a tx with 252-byte scriptSig (all <code>1</code>s). I have <code>fc</code> to encode its length and it parses:
<code>0200000001517adf7ba2ab9fd2c514687b0774c93d87d3e959d202b66fed76782d832a94f800000000fc111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111ffffffff0280d1f008000000001976a9143bc28d6d92d9073fb5e3adf481795eaf446bceed88ac80f0fa02000000001976a914cc1b07838e387deacd0e5232e1e8b49f4c29e48488ac00000000</code></p>
<p>Then I tried adding two bytes to the start of the scriptSig (<code>2222</code>) to make it 254 bytes long, and replaced the length <code>fc</code> with <code>4cfe</code> (<code>OP_PUSHDATA1</code> <code>fe</code>), but it's not parsing anymore:</p>
<p><code>0200000001517adf7ba2ab9fd2c514687b0774c93d87d3e959d202b66fed76782d832a94f8000000004cfe2222111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111ffffffff0280d1f008000000001976a9143bc28d6d92d9073fb5e3adf481795eaf446bceed88ac80f0fa02000000001976a914cc1b07838e387deacd0e5232e1e8b49f4c29e48488ac00000000</code></p>
<p><strong>EDIT-2</strong>: The answer is that encoding the length of the scriptSig is a varint rather than a push OP_CODE. So the correct way to get this to parse was to set the sigScript length to <code>0xfd</code> <code>0xfe</code> <code>0x00</code>:</p>
<p><code>0200000001517adf7ba2ab9fd2c514687b0774c93d87d3e959d202b66fed76782d832a94f800000000fdfe002222111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111ffffffff0280d1f008000000001976a9143bc28d6d92d9073fb5e3adf481795eaf446bceed88ac80f0fa02000000001976a914cc1b07838e387deacd0e5232e1e8b49f4c29e48488ac00000000</code></p>

<script><op-pushdata>
What OP_CODEs would push 254 bytes of data?
Darius
# What OP_CODEs would push 254 bytes of data?

(Asked by: username_0 on 2022-08-18)

From [BIP62](https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki#push-operators) I would expect to use `OP_PUSHDATA1` followed by uint8\_t:

> Pushing 76 to 255 bytes must use OP\_PUSHDATA1.

But then from [this answer](https://bitcoin.stackexchange.com/questions/101817/is-there-a-difference-between-op-pushbytes-and-op-pushdata), the link to [variable-length integer](https://en.bitcoin.it/wiki/Protocol_documentation#Variable_length_integer) makes it seem that a value of 253 (0xfd) should be encoded by 0xFD followed by the length as uint16\_t.

**EDIT-1**: Here is a dummy transaction I am trying to get to parse.

Here I have a tx with 252-byte scriptSig (all `1`s). I have `fc` to encode its length and it parses:
`0200000001517adf7ba2ab9fd2c514687b0774c93d87d3e959d202b66fed76782d832a94f800000000fc111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111ffffffff0280d1f008000000001976a9143bc28d6d92d9073fb5e3adf481795eaf446bceed88ac80f0fa02000000001976a914cc1b07838e387deacd0e5232e1e8b49f4c29e48488ac00000000`

Then I tried adding two bytes to the start of the scriptSig (`2222`) to make it 254 bytes long, and replaced the length `fc` with `4cfe` (`OP_PUSHDATA1` `fe`), but it's not parsing anymore:

`0200000001517adf7ba2ab9fd2c514687b0774c93d87d3e959d202b66fed76782d832a94f8000000004cfe2222111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111ffffffff0280d1f008000000001976a9143bc28d6d92d9073fb5e3adf481795eaf446bceed88ac80f0fa02000000001976a914cc1b07838e387deacd0e5232e1e8b49f4c29e48488ac00000000`

**EDIT-2**: The answer is that encoding the length of the scriptSig is a varint rather than a push OP\_CODE. So the correct way to get this to parse was to set the sigScript length to `0xfd` `0xfe` `0x00`:

`0200000001517adf7ba2ab9fd2c514687b0774c93d87d3e959d202b66fed76782d832a94f800000000fdfe002222111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111ffffffff0280d1f008000000001976a9143bc28d6d92d9073fb5e3adf481795eaf446bceed88ac80f0fa02000000001976a914cc1b07838e387deacd0e5232e1e8b49f4c29e48488ac00000000`

**Tags:** script, op-pushdata


---

## 1 answers

### Answer by username_1 on 2022-08-18. Score: 2 | Accepted answer

Bitcoin Script opcodes, and P2P variable-length integers are distinct concepts.

To push a 254-byte element in Bitcoin Script, use `OP_PUSHDATA1 0xfe` (followed by the 254 bytes to be pushed).

To encode e.g. that a transaction has 254 inputs, its varint encoding `0xfd 0xfe 0x00` would be used.

> **Comments:**
> **username_0**: Thank you very much. I tried using `4cfe` but I'm not getting the transaction to parse. I added a concrete example to the question with a dummy scriptSig.  
> **username_0**: Ah okay I got it, I guess what goes at the start of the scriptSig is not a OP_PUSHDATA operation but is instead a varint encoding of the scriptSig length. I put `0xfd` `0xfe` `0x00` in the length field instead and it works now I'm updating the question.  
> **username_1**: Yes, the length of a script is not part of the script itself, and thus can't use script opcodes.  

---

