From the bitcoin developer page, the format of the scripts used in P2SH transactions are as follows:

Pubkey script: OP_HASH160 <Hash160(redeemScript)> OP_EQUAL
Redeem script: <OP_2> <pubkey> <pubkey> <pubkey> <OP_3> OP_CHECKMULTISIG
Signature script: OP_0 <sig> <sig> <redeemScript>

When coins that were previously sent to a P2SH script are spent, and so the concatenated scriptSig and scriptPubKey scripts are executed, the OP_HASH160 is calculated on the redeem script, which is part of the scriptSig. How is it denoted in the script which parts should be included in the redeemScript? That is, how is it denoted which parts should be hashed when OP_HASH160 gets executed? Obviously it can't be the whole scriptSig, because there are signatures contained, so how does the executor know what to hash? Is there some sort of a marker OP code?


1 Answer 1


Short Answer

Yes, but there's more than one.

Long Answer

Bitcoin scripts are a stack-based language. The 'separators' are the Bitcoin push-data-onto-stack instructions. There are multiple instructions to push data onto the stack:

  • OP_0, OP_1, OP_2, ...
  • 0x01-0x75 (Yes, that's their real name)
    Push opcode bytes onto the stack
    This is most common - the average piece of data in Bitcoin is shorter than 75 bytes.
  • PUSHDATA1 - Read 1 byte, convert to int, read that many bytes
  • PUSHDATA2 - Read 2 bytes, convert to int, read that many bytes
  • PUSHDATA4 ...
  • OP_1NEGATE - Pushes -1 onto the stack. Somewhat use-impaired.

There's a useful rule of thumb here, though it's not always correct. Take the first byte. Convert it to a number. Count that many bytes forward. That's a single piece of data. Repeat.

Let's work through an example. Let's find the elements of the input script for this transaction.


Break it up, find the input script:

version: 01000000
inputs: 01
hash: cce488677848b7a962f01a525d7cd78139a5be1ab75ead5b7336ba6f512d0388
vout: 01000000
input script len: 8b
input script: 483045022100b65463abe3b5f79dbe9556180e60db4b6b3a6db7c43132e1e396e73023b34d2402206a412868470f8b83dc266a364b79e0a2acd0f5642181f7d0212c7ea608271a4a0141040ab8f88b419c62dba59d2e685bd3bc07367236d841abf3068b5886cd7a6c7297e721d42a41cb1bbd69ed684cc5d5c738d611d886c4493280b26637abad5603a5
seq: ffffffff
outputs: 02
amount: 80f0fa0200000000
output script len: 19
output script: 76a914f593d5cfb3b74ac2988815cdf26c0420981385b788ac
amount: 50d2a01900000000
output script len: 19
output script: 76a9148a0c13d08a36e68aa5294ca7e6f06a9946c3f1d588ac
lock_time: 00000000

Now, we know the first piece of data is 0x48 (72) bytes long.


The second part is 0x41 (65) bytes long:


  • Thank you very much, this was a very descriptive and clear answer!
    – morsecoder
    Commented Oct 20, 2014 at 12:11
  • Just like you described, if I look into the hex of a standard scriptPubKey (such as "76a9143cfa95abbb8da05e2a597f5da9640b5ef3d39d6088ac") there is a 0x14 op code to say that we are pushing 20 bytes
    – morsecoder
    Commented Oct 20, 2014 at 12:18

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.