This is a P2SH script (pay to script hash), defined in BIP 16.
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
- That Script is executed, with as inputs all but the final push in the
So, semantically, the whole operation is equivalent to just using the
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.