Tx malleability fix so far seems incomplete (considering exchange's pov)

[bitcoated]

Solutions proposed for protecting exchanges from transaction malleability attacks have so far been to alter the condition the exchange uses to verify a customer's claim that a withdrawal transaction has not reached the blockchain.  AUIU the suggestion thus far is to ignore the transaction hash and instead use other data from the transaction.

If this is all we do, is there not a race condition here?

How can an exchange know that an attacker will not post the transaction to the blockchain after the exchange has determined that the withdrawal has failed?

IMO, one safe solution is as follows:

Upon a customer's claim of a failed withdrawal or upon timeout, create a new transaction to an internal exchange-owned address using the same prevtx outputs that the (allegedly failed) withdrawal tx used.  Once this transaction is sufficiently confirmed, the exchange can trust that the customer's withdrawal did indeed fail and can now safely credit the customer's account without fear that the transaction (mutated or otherwise) could ever be subsequently accepted on the blockchain.

Using this approach, the internal transaction would not confirm if any of the prevtxouts had been redeemed and therefore would be flagged for a human to intervene before re-crediting the attacker's account.

[Nagle]

IMO, one safe solution is as follows:

Upon a customer's claim of a failed withdrawal or upon timeout, create a new transaction to an internal exchange-owned address using the same prevtx outputs that the (allegedly failed) withdrawal tx used.  Once this transaction is sufficiently confirmed, the exchange can trust that the customer's withdrawal did indeed fail and can now safely credit the customer's account without fear that the transaction (mutated or otherwise) could ever be subsequently accepted on the blockchain.

Using this approach, the internal transaction would not confirm if any of the prevtxouts had been redeemed and therefore would be flagged for a human to intervene before re-crediting the attacker's account.

That seems to make sense. Or am I missing something?

[Maged]

IMO, one safe solution is as follows:

Upon a customer's claim of a failed withdrawal or upon timeout, create a new transaction to an internal exchange-owned address using the same prevtx outputs that the (allegedly failed) withdrawal tx used.  Once this transaction is sufficiently confirmed, the exchange can trust that the customer's withdrawal did indeed fail and can now safely credit the customer's account without fear that the transaction (mutated or otherwise) could ever be subsequently accepted on the blockchain.

Using this approach, the internal transaction would not confirm if any of the prevtxouts had been redeemed and therefore would be flagged for a human to intervene before re-crediting the attacker's account.

That seems to make sense. Or am I missing something?

To quote the owner of Mt.Gox:

Re-issuing of transactions should be done using the same inputs, but as of today this poses a problem as said txs won't be relayed as easily as clean txs.

https://github.com/bitcoin/bitcoin/pull/3656#issuecomment-35037503

In other words, "it's too slow to do it correctly, so we'll just give away our money instead."