Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

FWIW it's an error in the BTC reference implementation so it's an easy error to make


Please stop spreading FUD.

>In the meantime, users of the reference implementation do not need to be concerned. Transactions are always tracked properly by the Bitcoin-Qt/bitcoind software.

https://bitcoinfoundation.org/blog/?p=418


Interesting. This thread on reddit states that it IS an issue in the reference implementation and includes a patch

http://www.reddit.com/r/Bitcoin/comments/1xm49o/due_to_activ...

Edit: The concern with the Bitstamp appears to be confusion due to transaction malleability and NOT actual double spend or cancellation issues. However the BTC reference client is not perfect at handling malleability and only gets it right eventually.


While it's not an issue if you're using the GUI, the official client makes it hard for API consumers to track what's going on. As far as they're concerned, the transaction they requested never succeeds and a new one with a completely different ID that they never sent appears. It's entirely up to API consumers to reliably match the new, different transaction up with what they originally requested - and the API doesn't actually expose the information they need to do this cleanly.


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=319565...


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.


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.


This is not true. It does not handle malleability in one case. See 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.


I wouldn't call it an error, exactly. But it is a design flaw that other implementations are expected to work around.


This is what you're referring to, right? https://en.bitcoin.it/wiki/Original_Bitcoin_client

I imagine that the more recent versions of the satoshi client don't have this bug, it may have a few years ago when bitstamp and mtgox may have been looking to draw inspiration from it.



Is that true? If so then significant blame goes to that in addition to the exchanges.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: