Author

Topic: Transaction Recast - No good deed goes unpunished? (Read 619 times)

sr. member
Activity: 351
Merit: 250

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?
Elo
newbie
Activity: 14
Merit: 0
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.
newbie
Activity: 56
Merit: 0
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://bitcointalksearch.org/topic/recommended-fix-for-mt-goxs-withdrawal-problem-caused-by-transaction-malleabil-459000

    
Jump to: