How to denote script in P2SH transaction?

Question

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?

Thanks!

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.

0100000001cce488677848b7a962f01a525d7cd78139a5be1ab75ead5b7336ba6f512d0388010000008b483045022100b65463abe3b5f79dbe9556180e60db4b6b3a6db7c43132e1e396e73023b34d2402206a412868470f8b83dc266a364b79e0a2acd0f5642181f7d0212c7ea608271a4a0141040ab8f88b419c62dba59d2e685bd3bc07367236d841abf3068b5886cd7a6c7297e721d42a41cb1bbd69ed684cc5d5c738d611d886c4493280b26637abad5603a5ffffffff0280f0fa02000000001976a914f593d5cfb3b74ac2988815cdf26c0420981385b788ac50d2a019000000001976a9148a0c13d08a36e68aa5294ca7e6f06a9946c3f1d588ac00000000

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.

48...3045022100b65463abe3b5f79dbe9556180e60db4b6b3a6db7c43132e1e396e73023b34d2402206a412868470f8b83dc266a364b79e0a2acd0f5642181f7d0212c7ea608271a4a01...41040ab8f88b419c62dba59d2e685bd3bc07367236d841abf3068b5886cd7a6c7297e721d42a41cb1bbd69ed684cc5d5c738d611d886c4493280b26637abad5603a5

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

48...3045022100b65463abe3b5f79dbe9556180e60db4b6b3a6db7c43132e1e396e73023b34d2402206a412868470f8b83dc266a364b79e0a2acd0f5642181f7d0212c7ea608271a4a01...41...040ab8f88b419c62dba59d2e685bd3bc07367236d841abf3068b5886cd7a6c7297e721d42a41cb1bbd69ed684cc5d5c738d611d886c4493280b26637abad5603a5...