This is a P2SH script (pay to script hash), defined in BIP 16.
The scriptPubKey
itself is very uninteresting: it takes an element from the scriptSig
, hashes it with OP_HASH160
, and then compares it with 0b49fe...f1. In other words, ostensibly the only thing needed in order to spend is knowing some piece of data whose hash is 0b49fe....f1.
Now, BIP 16 changed this. If a scriptPubKey
has exactly the form OP_HASH160 + 20 byte hash + OP_EQUAL, then the special P2SH validation rules trigger:
- All operations in the
scriptSig
must be pushes.
- The final push in the
scriptSig
(the one whose hash we know is 0b49fe...f1) is taken to again be a Script (called the redeemScript
).
- That Script is executed, with as inputs all but the final push in the
scriptSig
.
So, semantically, the whole operation is equivalent to just using the redeemScript
as scriptPubKey
, but without needing to reveal this to the sender. Instead, the sender can just be given a short P2SH (3...) address that encodes the hash of the redeemScript
, and the real one is only revealed at spending time.
In your example, the redeemScript
appears to encode a 2-of-3 multisig policy: OP_2 <pubkey1> <pubkey2> <pubkey3> OP_3 OP_CHECKMULTISIG
, and the additional stack items in the scriptSig
are OP_0 (a workaround for a bug that OP_CHECKMULTISIG
pops off one item too many from the stack) plus 2 signatures.