I created a
thread about a similar method. You method is simpler.
I think the extortion problem due malleability could be solved in the way that Bob pays in a deposit so there is a balanced risk situation.
So both pay in the same amount, Alice payment move over to Bob and he gets his deposit back after the trade:
Tx1:
input 1: x BTC from Alice
input 2: x BTC from Bob
output:
if clause: MultiSig
else clause: 2x BTC to Bobs address and redeemer needs to solve H(x)
Tx1 is first signed by Bob then sent to Alice and then she signs her input.
Alice selects a transaction output of value x that she owns as input 1 and sends it to Bob.
Bob creates the transaction, as above, signs it and sends it back to Alice.
Alice signs the transaction and gets it hash.
Alice creates the refund transaction.
Input
2x from TX1 signed by Alice, locked 24 hours in the future
Output
x to Bob
x to Alice
Bob signs and sends it back to Alice.
Alice now has a refund transaction.
She is then supposed to publish TX1.
If Alice stops here, then she can hold Bob's money to ransom.
Worst case, she gets her money back after 24 hours.
OTOH, her hand is weakened, since her x BTC is tied up in the process.
The fact that Alice is the redeemer who reveals the secret and therefore control if the trade will executed or be canceled (refund), might need additional protection (offer fees, reputation system?).
Automated trades with micropayments might be another option (break down a bigger volume to smaller chunks).
This might be a general solution, especially with malleability. If you have traded with someone before, you are willing to trust them for up to 1% of the trade or 1% of the total trades that you have done with that person before.