Quote from: TierNolan on February 13, 2014, 09:29:02 AM

The system in this thread doesn't work at the moment due to transaction malleability.

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)

Tx2_Refund:
input: 2x BTC from Tx1 (MultiSig )
output 1: x BTC to Alice
output 2: x BTC to Bob
timelock: 24 h

Same happens on the altcoin side.

Tx1 is first signed by Bob then sent to Alice and then she signs her input.

Malleability could also happen without bad intention, but the refund tx is only needed if the normal trade does not get completed.
In that case both have an incentive to agree to a new refund tx with the changed TxID from the now published Tx1 to get back their payments.
At least Bob has no extortion advantage compared to Alice.

One other open problem is that when the price changes to the disadvantage of Alice, she might consider to not redeem the Altcoin and therefore cancel the trade.
So both trades will be refunded, but Alice has the advantage to decide to cancel the trade if the price moves against her interests.
That form of scam seems to be quite a problem on localbitcoin or bitcoin.de. With shorter time-windows that could be mitigated.

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).