4 ms·

This is NOT the case. To quote gmaxwell on the bitcoin-development mailing list: "Not that Bitcoin-QT handles Malleability fantastically— but because it tracks

by Judson 13y ago

This is NOT the case. To quote gmaxwell on the bitcoin-development mailing list: "Not that Bitcoin-QT handles Malleability fantastically— but because it tracks inputs it will still detect the mutant transactions." http://sourceforge.net/mailarchive/message.php?msg_id=31956576 http://sourceforge.net/mailarchive/message.php?msg_id=319565...

mason55 13y ago
Right... so I believe what's happening is that the client handles them correctly.... eventually. But from what people are saying it's causing confusion in the accounting with the effected exchanges, not necessarily cancellation or double spend issues.
- Judson 13y ago
  I'll explain it to the best of my understanding, at least in a narrow scope. A user on an exchange requests to withdraw btc. MtGox creates a transaction with a tx hash of abc1234cdf... and sends it to the blockchain, polling for the status of tx hash "abc1234cdf...". Due to tx malleability, the tx hash can change by changing some of the tx data (in insignificant ways), which doesn't invalidate the tx signatures. A malicious user could wait for MtGox to create a tx, flip a bit and resubmit the tx and try to get it confirmed under a different hash, invalidating Gox's tx as a double spend. Which leaves Gox polling for the status of tx hash "abc1234cdf...", which will never confirm. A user then submits a support request and says their tx is "Stuck". MtGox then creates a new tx, Which doesn't respend the same coins, and thus, the user is paid 2x.
yetfeo 13y ago
This is not true. It does not handle malleability in one case. See http://www.reddit.com/r/Bitcoin/comments/1xm49o/due_to_active_malleable_transaction_relayers_it/ http://www.reddit.com/r/Bitcoin/comments/1xm49o/due_to_activ... This is why many sites are having issues. It is in fact a problem with the reference client.

by Judson 13y ago

mason55 13y ago

Right... so I believe what's happening is that the client handles them correctly.... eventually. But from what people are saying it's causing confusion in the accounting with the effected exchanges, not necessarily cancellation or double spend issues.

Judson 13y ago
I'll explain it to the best of my understanding, at least in a narrow scope. A user on an exchange requests to withdraw btc. MtGox creates a transaction with a tx hash of abc1234cdf... and sends it to the blockchain, polling for the status of tx hash "abc1234cdf...". Due to tx malleability, the tx hash can change by changing some of the tx data (in insignificant ways), which doesn't invalidate the tx signatures. A malicious user could wait for MtGox to create a tx, flip a bit and resubmit the tx and try to get it confirmed under a different hash, invalidating Gox's tx as a double spend. Which leaves Gox polling for the status of tx hash "abc1234cdf...", which will never confirm. A user then submits a support request and says their tx is "Stuck". MtGox then creates a new tx, Which doesn't respend the same coins, and thus, the user is paid 2x.

yetfeo 13y ago

This is not true. It does not handle malleability in one case. See http://www.reddit.com/r/Bitcoin/comments/1xm49o/due_to_active_malleable_transaction_relayers_it/ http://www.reddit.com/r/Bitcoin/comments/1xm49o/due_to_activ... This is why many sites are having issues. It is in fact a problem with the reference client.