Mt. Gox Official Statement

Mt. Gox have just released their official statement regarding their recent decision to halt all Bitcoin withdrawals.

Essentially, they are claiming they can’t release customers’ funds until a known bug in the Bitcoin protocol is resolved.

Greg Maxwell Responds

I spoke with Bitcoin core developer, Greg Maxwell, about this highly technical issue. Greg Maxwell and Peter Wuille are the core developers in consultation with Mt. Gox, as per their press release.

<gmaxwell> The Gox press release seems a little ‘spun’ to me. They portray characteristics of the Bitcoin system well known since at least 2011 (which even have their own wiki page ) as something new.

These characteristics are annoying but don’t inhibit basic operation. They are slowly being fixed – but fixing them completely will likely take years as they require changing all wallet software. Correctly-written wallet software can cope with the consequences, and I cannot understand why they would gate their withdraws on external changes.

<GG> Andreas Antonopoulus has examined Gox’s code to some degree, and remarked that they are using a strange “hodgepodge of technologies that are really not suitable for running an exchange.” Do you believe the problem lies in their code rather than the Bitcoin protocol?

<gmaxwell> Oh there is a “problem” in the Bitcoin protocol, known since at least 2011 (see the link I gave). But for normal applications, not involving unconfirmed transactions, it shouldn’t cause any severe problems because wallets can handle it locally.

Basically, third parties can change the transaction IDs of transactions. This means what wallet software must be written to accomodate that and still recognize them when that happens.

What the press release talks about is adding a second kind of transaction ID, which is robust against changes, which would be helpful for tech support purposes. Though it doesn’t resolve all of the issues that being able to modify transactions presents.

<GG> So in other words, Gox should be able to account for this known problem by modifying their internal systems?

<gmaxwell> Yes, internal-only changes should account for it. The only remaining issue for Mt. Gox’s application would be some tech support problems, where if a user’s transaction is mutated by a malicious party the txid [“transaction ID”] Mt. Gox told them to expect wouldn’t be the one that ultimately showed up in the blockchain.

<GG> It seems the market is reacting very negatively to the news. What advice would you give to the average Bitcoiner regarding this situation?

<gmaxwell> The challenge for me in offering something here is that this isn’t news to me – for years – and it’s never been a particularly large concern. This wouldn’t make the top ten list of dangers in the Bitcoin technology.

<GG> Thanks for your comments.

–

Update 1: Market Stabilising

As of 13:35 GMT+2, the market has retraced about 60% of the recent loss as the news is digested.

In my personal opinion, Gox have done more harm to the Bitcoin community than good to themselves through their statement. This situation should have been handled in such a way as to minimize the market impact.

Update 2: Further technical details.

In a BitcoinTalk thread relating to Mt. Gox’s statement, Rannasha offers this concise summary of the situation:

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 set of (amount, address, timestamp) instead. If a user complains about not receiving their withdrawal, support can look it up using these 3 variables. It takes a little bit more work from support, but it prevents this attack from succeeding.

While it’d be nice if the tx-id isn’t malleable, blaming this problem on a flaw in the protocol is quite a stretch.

I asked Greg Maxwell whether he agreed with this summary. His reply:

I don’t disagree but it’s actually missing a critical point on that subject that I posted about on Bitcoin-development just now.

As per the above link, Drak posed the following question:

On Mon, Feb 10, 2014 at 3:28 AM, Drak <drak@…> wrote: What is the official response from the Bitcoin Core developers about MtGox’ assertion that their problems are due to a fault of bitcoin, as opposed to a fault of their own?

The technical analysis preluding this mess, was that MtGox was at fault for their faulty wallet implementation.

Gmaxwell replied: