1

From BIP62 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, the link to 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 1s). 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

Improve this question

1 Answer 1

Reset to default
2

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.

Improve this answer
3
  • 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
    Commented Aug 18, 2022 at 21:12
  • 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
    Commented Aug 18, 2022 at 21:53
  • 1
    Yes, the length of a script is not part of the script itself, and thus can't use script opcodes.
    – Pieter Wuille
    Commented Aug 19, 2022 at 11:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.