Transaction Recast - No good deed goes unpunished?

[LarryLiu]

I call those who exploit Bitcoin's transaction malleability "feature" recasters. By no means I'm here to defend their actions. But despite the blames they got in light of Mt.Gox's recent withdrawal debacle I happen to think transaction recasters can actually help accelerate the inter-node relays, granted services such as Mt. Gox knows how to take an advantage of it. See my suggestion to Gox at: https://bitcointalk.org/index.php?topic=459000.0

    

[Elo]

Transaction recasters are a good thing. They make plainly visible an aspect of the protocol that was thus far obscure, and highlight implementations that don't cope with it properly. As long as transactions remain malleable, transaction recasting should be a permanent feature of the network, done by default for all transactions, so that people don't write software that relies on unconfirmed transaction IDs.

Apparently, even the reference client is affected, to the extent that it allows spending of a previous transaction's change based on an unconfirmed transaction ID. This has to be fixed, or else the reference client does not handle malleable transactions as properly as the developers supposed in their replies to MtGox.

[optimator]

Apparently, even the reference client is affected, to the extent that it allows spending of a previous transaction's change based on an unconfirmed transaction ID. This has to be fixed, or else the reference client does not handle malleable transactions as properly as the developers supposed in their replies to MtGox.

Please explain how change address can be affected by exploiting malleable transactions.

If you create 2 transactions T1 and T2, where T2 is a malleable script change for T1, it seems that you control the change address and no harm is done, no?