Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Databases Bitcoin

Surrogate Database Key, Not Bitcoin Protocol Flaw, To Blame For Mt Gox Problems 81

An anonymous reader writes "Bitcoin values dropped sharply over the weekend after the largest trading exchange, MtGox, revealed that an investigation into unusual trading activity turned up a flaw in the underlying Bitcoin software that allowed an attacker to double withdrawal a transaction" Not so fast according to database experts: the real problem is that Mt Gox (and other exchanges) are using a surrogate transaction id rather than a natural key in their databases: "The flaw isn't so much in Bitcoin as it is in exchange-systems. Many exchanges use the tx-id to uniquely identify transactions, but as it turns out, an attacker can change the tx-id without changing the actual transaction, rebroadcast the changed transaction (effectively creating a double-spend) and if his altered transaction gets accepted into a block instead of the legit transaction, the attacker receives his coins and can complain with the exchange that he didn't. The exchange will then check their db, fetch the tx-id from it, look it up in the blockchain and not find it. So they could conclude that the transaction indeed failed and credit the account with the coins. ... A simple workaround is to not use the tx-id to identify transactions on the exchange side, but the (amount, address, timestamp) instead."
This discussion has been archived. No new comments can be posted.

Surrogate Database Key, Not Bitcoin Protocol Flaw, To Blame For Mt Gox Problems

Comments Filter:
  • Re:Wait... (Score:5, Interesting)

    by Ritz_Just_Ritz ( 883997 ) on Monday February 10, 2014 @09:06PM (#46214171)

    Indeed. MtGox has been tainted with (at best) incompetence or (at worst) fraud for quite some time now. It could potentially be both.

    In any case, bitcoin owners/miners have voted with their feet to the extent possible and MtGox has gone from the largest to one of the smaller players in the bitcoin exchange arena. There are still quite a few unfortunate folks with their funds trapped within MtGox. We'll see if those funds are eventually released or become part of an eventual bankruptcy proceeding. That might be great in the longer term since the courts will eventually sort out the role of BTC in the world of finance, but it might be bad for people who put their trust in one of the early exchanges.

    Time will tell.

  • by Anonymous Coward on Monday February 10, 2014 @09:32PM (#46214333)

    A bitcoin transaction comprises 3 parts:
    Transaction data - Source, destination, amount and timestamp
    An ECDSA signature signed with the private key of the source
    A transaction ID.

    The transaction ID is generated as the cryptographic hash of the transaction data and signature.

    The problem comes with how ECDSA signatures are formatted. A signature is essentially a large integer of undefined length. Industry standards are that the signature should be written with no zero padding - i.e. the first byte should be non-zero. In practice, many software implementations would define a fixed length field and zero-pad signature.

    The signature would still be valid even if zero padded. However, the transaction ID which is a hash of the transaction data and signature would change.

    Early versions of the bitcoin daemon would accept padded signatures, but this bug was fixed a couple of years ago, and transactions submitted to the network with excessive signature padding would be rejected as invalid.

    Mt Gox used in-house bitcoin client software which for a long time continued to pad their transaction signatures, even after the bitcoin developers issued an alert to users, resulting in failed or delayed (if the first node to receive the transaction broadcast was running on old daemon which would accept the transaction, the transaction would be validated and accepted; therefore a semi-invalid transaction may succeed after a number of retries) withdrawal transactions.

    Finally, the thing that really screwed things up was that 3rd parties (possibly early adopters with large amounts of bitcoin at Mt Gox) recognised the bug, and provided a workaround for Gox's broken software. Their software acted as transaction relay nodes, and when it received a broken transaction from Gox would rewrite the signature in the correct form, and compute a new transaction ID, before re-broadcasting the transaction.

    The result was that Gox's withdrawral problems disappeared for a number of months - until Gox's client went out of sync with the bitcoin network, as it was trying to spend coins that had previously been spent by transactions that it thought had failed.

    Captcha: bugged

8 Catfish = 1 Octo-puss

Working...