It is not the transaction hash, I’ve tested this multiple times. The block hash contains multiple transaction, correct? If so, multiple transactions would be confirmed when taking the block hash, so don’t think this is it.
I don’t have any code because i make it with MEW or parity.

The issue here is that you are confusing the transaction hash with the “operation hash”. The commandh = wallet.execute(eth.accounts[2], web3.toWei(5, “ether”), web3.toHex(‘send some money’), { from: eth.accounts[0]});
is actually returning the transaction hash, whereas the contract wants you to refer to the pending operation by its “operation hash”, which the contract defines separately (contracts do not know tx hashes).

What you need to do is set up a listener for the event that the contract will emit, which is called ConfirmationNeeded.
This should work:wallet.ConfirmationNeeded({address:eth.accounts[2]}, function(err, res){if(!err){wallet.confirm(res.args.operation, {from: eth.accounts[0]});}});
Set that listener before using the execute method, and it will automatocally authorize any transaction. That’s obviously not what you want in a production environment, but it shows what the process should look like.

But as said I’m not familiar with coding.
This is quite a basic function and I don’t think I’m the only one performing such multisig interactions?

I was able to raise the daily spend limit, so no confirmation is necessary now. The transaction still does not work and nothing is transferred although the daily spend amount is raising. How do I figure out if my wallet is frozen and impacted by the parity hack?