> What I am not getting is how the operation are done.

The address encodes the hash160 of the *redeemScript*. That address was given to the sender, who used it to construct an output *scriptPubKey* of the form `OP_HASH160 <scripthash> OP_EQUAL`. The *scripthash* is really *hash160(redeemScript)*, but the sender does not know that, as they aren't given the actual *redeemScript*, just its *hash160*. The `<...>` notation here means "script opcode that pushes ... onto the stack".

The *redeemscript* is `OP_2 <pubkey1> <pubkey2> <pubkey3> OP_3 OP_CHECKMULTISIG`. This script was created by the receiver, encoding their policy for spending, and then its hash160 was given in the form of a P2SH address (3...) to the sender.

The *scriptSig* is what is created by the receiver when they want to spend the coins. In this case it consists of `OP_0 <sig1> <sig2> <redeemScript>`.

During validation, what happens is:
* First the *scriptSig* is executed, which pushes 4 items onto the stack (0, *sig1*, *sig2*, and *redeemScript*).
* Then the scriptPubKey is executed, starting with the previous execution's final stack as initial state. It contains 3 opcodes, each modifying that stack:
  * `OP_HASH160`: takes the final element of the stack (the *redeemScript*) and replaces it with *hash160(redeemScript)*.
  * `<scripthash>`: pushes the *scripthash* onto the stack, so now the stack is (0, *sig1*, *sig2*, *hash160(redeemScript)*, *scripthash*).
  * `OP_EQUALVERIFY`: removes the top two items on the stack and compares them. If they are equal, a 1 is pushed onto the stack, otherwise a zero. In our case, the *scripthash* is equal to *hash160(redeemScript*) (because the spender revealed the correct *redeemScript*) and thus a 1 is pushed. The stack is now (0, *sig1*, *sig2*, 1).
* The final stack is examined: validity rules require that the stack is not empty, and that its top element is nonzero. That is the case here: the top element is 1. If that wasn't the case, the spend would be marked invalid and execution would stop here.

That's it for the ordinary execution. However, because the *scriptSig* is **exactly** of the form `OP_HASH160 <20-byte scripthash> OP_EQUAL`, the BIP16 P2SH validation rules trigger for a secondary round of processing. This time:
* It is verified that the *scriptSig* contains only push opcodes, and no other opcodes. If this is not true, the P2SH validation marks the transaction as invalid.
* The stack we had just after executing the *scriptSig* is restored (0, *sig1*, *sig2*, *redeemScript*).
* Its top element (the *redeemScript*) is removed from the stack, and reinterpreted as a script, and executed, with all the other stack elements as input. It consists of 5 opcodes:
  * `OP_2`: pushes a 2 onto the stack, which now becomes (0, *sig1*, *sig2*, 2).
  * `<pubkey1>`: pushes *pubkey1* onto the stack, which becomes (0, *sig1*, *sig2*, 2, *pubkey1*).
  * `<pubkey2>`: pushes *pubkey2* onto the stack, which becomes (0, *sig1*, *sig2*, 2, *pubkey1*, *pubkey2*).
  * `<pubkey3>`: pushes *pubkey3* onto the stack, which becomes (0, *sig1*, *sig2*, 2, *pubkey1*, *pubkey2*, *pubkey3*).
  * `OP_3`: pushes a 2 onto the stack, which now becomes (0, *sig1*, *sig2*, 2, *pubkey1*, *pubkey2*, *pubkey3*, 3).
  * `OP_CHECKMULTISIG` inspects the stack, sees a 3 on top, removes it, as well as the 3 pubkeys that precede it. Then it encounters a 2 on top, removes, as well as the 2 signatures that precede it. Then it removes one more element (a historical bug that is very hard to fix). Then it checks those signatures against every subset of 2 of those 3 pubkeys. If matches are found, it puts a 1 on the stack, otherwise a 0. In this case, the signatures are valid for some subset of the public keys, and the stack becomes (1).
* The final stack is inspected, requiring that it is not empty, and its top element is nonzero. As it is a 1 here, that is the case.