Quote from: dzimbeck on March 19, 2015, 02:24:07 PM

Hey I just wanted to make a suggestion. I know we talked earlier about AT and malleability and it was concluded it still is a problem until the update of checklocktimeverify.

However, I think I have a really good idea that may help you fully avoid malleability. In BitHalo, we use "instant refund" for preventing a malleable transaction. If you have a refund based on the TXID of the transaction in question to a multisignature account controlled by both parties then you can do AT! The amount must only slightly exceed the amount being traded. Hell, even a small refund would be a deterrent if it exceeded the probability of a successful attack.

Thus if a party deliberately changes the TXID before broadcast then he loses the refund. This can help you until checklocktimeverify is added and can make 100% sure your exchange is trustless.

This way we know that p2sh is indeed more resilient. Because we should try and attack the mercury exchange to test its resilliance to these attacks. If you want, i can give you a p2sh malleability script in python.

Please read my whitepaper on instant refunds and let me know what you think. If you have a question for me please PM me since i dont always check bitcointalk. The whitepaper is here... www.bithalo.org

Best,
David

Right, I mentioned that solution here before:

Quote from: mappum on February 07, 2015, 01:06:16 AM

Additionally, a way to solve the malleability attack is to require party A to deposit some coins into party B's initial multisig deposit. If A mutates the transaction, they are also tying up their own funds in the process. This solution is already possible today, I may implement it in the Mercury alpha.

But it turns out to not be very viable from a UX standpoint, since traders have to already have a significant balance of the coin they want to buy (so they would have to buy it on another exchange), and they could then not trade their entire balance. It's still an option if necessary, but I'd actually rather lobby for OP_CHECKLOCKTIMEVERIFY to be added to coins since it only requires a soft fork and it is also necessary for micropayment channels and some escrow protocols.