Watching the drama surround MtGox in recent days has been like watching a slow motion train wreck. It’s put a lot of strain on the community and has been causing the Bitcoin price to tank. If you’re not up to date on this story, basically MtGox has been experiencing severe Bitcoin withdraw issues with numerous customers claiming they never received their bitcoins. Apparently upwards of $38 million worth of bitcoin withdrawals have gone unfulfilled causing MtGox to freeze withdrawals altogether.
You can add this to the long list of problems MtGox has had over the last couple years. A trading platform that couldn’t handle high volume trades, operating without a license in the US and having a large amount of customer funds stolen by the US government, USD withdrawals taking months to clear, and strong suspicion it’s operating on fractional reserves.
Now this morning MtGox comes out and announces its problems aren’t its fault, but rather a bug in Bitcoin itself! News of this potentially catastrophic bug has sent the markets into a tizzy.
So what bug are they talking about exactly? It has to to do with something called transaction malleability. Now, this isn’t some kind of zero-day exploit. It has been known since at least 2011. Fixing it has never been high priority for the developers because, as we’ll see, it hasn’t been considered that big of a deal. Which is why it’s a bit odd that that MtGox would claim this is the source of their problems.
So what is this attack specifically? Basically it amounts to altering a transaction after it has been broadcast. A Bitcoin transaction has a number of parts:
|version||01 00 00 00|
|input||previous output hash
|48 4d 40 d4 5b 9e a0 d6 52 fc a8 25 8a b7 ca a4 25 41 eb 52 97 58 57 f9 6f b5 0c d7 32 c8 b4 81|
|previous output index||00 00 00 00|
|scriptSig||47 30 44 02 20 2c b2 65 bf 10 70 7b f4 93 46 c3 51 5d d3 d1 6f c4 54 61 8c 58 ec 0a 0f f4 48 a6 76 c5 4f f7 13 02 20 6c 66 24 d7 62 a1 fc ef 46 18 28 4e ad 8f 08 67 8a c0 5b 13 c8 42 35 f1 65 4e 6a d1 68 23 3e 82 01 41 04 14 e3 01 b2 32 8f 17 44 2c 0b 83 10 d7 87 bf 3d 8a 40 4c fb d0 70 4f 13 5b 6a d4 b2 d3 ee 75 13 10 f9 81 92 6e 53 a6 e8 c3 9b d7 d3 fe fd 57 6c 54 3c ce 49 3c ba c0 63 88 f2 65 1d 1a ac bf cd|
|sequence||ff ff ff ff|
|output||value||62 64 01 00 00 00 00 00|
|scriptPubKey||76 a9 14 c8 e9 09 96 c7 c6 08 0e e0 62 84 60 0c 68 4e d9 04 d1 4c 5c 88 ac|
|block lock time||00 00 00 00|
The transaction is run through a hash function with the resulting output looking something like this:
This hash serves as the transaction ID and can be referred to when referencing the transaction.
Transaction malleability makes it possible to alter the scriptSig field in the transaction in a way that does not invalidate the transaction, but does change the transaction ID.
This does NOT mean an attacker can forge a transaction. It doesn’t mean an attacker can swap out the receiving addresses or double spend bitcoins. If this attack is performed, the transaction still goes through as normal. The bitcoins still end up at the proper location. All it does is alter the transaction ID. To the sender it would look as if the transaction never confirmed, even though it did. (Note this affects all copy-and-paste altcoins as well.)
How is this affecting MtGox? Basically, MtGox logs the transaction ID for every withdrawal. They are claiming that someone is placing withdrawals then using transaction malleability to alter the transaction ID and make it look to MtGox like the withdrawal didn’t go through even though it did. Then, presumably, trying to get MtGox to reimburse them.
I should mention that this is a relatively difficult attack to pull off. An attacker would need to see to it that the altered transaction makes it into the next block and not the original transaction. Since miners accept the first transaction they receive as valid and since MtGox broadcasts the transaction to the network, it is significantly more likely the original transaction will be seen by miners first and make it into the next block.
The attacker would need to see the transaction before the vast majority of miners, then relay the altered transaction to a large number of miners and hope his transaction propagates quicker than the original. Not something your average person can do.
Now as MtGox mentions, if the altered transaction doesn’t make it into a block, the attacker can just redeposit the coins and try again.
So that’s what they claim is going on. However, from my armchair perspective I’m still a little skeptical. Let me give my reasons.
- Even though the transaction ID has been altered, it’s still relatively easy to tell that the transaction went through. Just look at the receiving address and check to see if it received any transactions for the same amount of bitcoins. If so, check to see if the input address matches MtGox’s address. If done correctly, transaction malleability isn’t a problem at all.
- AML/KYC regulations require MtGox to record the identity of all its customers. To use the exchange you have to provide a government issued ID. In other words, MtGox would know who was doing this attack. I suppose this person could plausibly claim ignorance, but would you try to scam a company using an account linked to your identity?
- I suppose an attacker could be doing this to other people’s withdrawals, maybe in an attempt to create chaos and drive down the price. But even here, people would still receive their bitcoins as requested. Remember we had widespread reports of people not receiving any bitcoins. It seems unlikely to me that people would complain like that if the withdrawal actually went through.
So my gut tells me there are other problems with MtGox that we still don’t know about. Transaction malleability could be a problem, but it’s an easy fix for them. Either way people need to understand that Bitcoin is not broken. These are much more MtGox problems than Bitcoin problems.
Here’s what core developer Pieter Wuille wrote this morning on the developer mailing list:
I was a bit surprised to see MtGox’s announcement. The malleability of
transactions was known for years already (see for example the wiki
article on it, https://en.bitcoin.it/wiki/Transaction_Malleability it,
or mails on this list from 2012 and 2013). I don’t consider it a very
big problem, but it does make it harder for infrastructure to interact
with Bitcoin. If we’d design Bitcoin today, I’m sure we would try to
avoid it altogether to make life easier for everyone.
But we can’t just change all infrastructure that exists today. We’re
slowly working towards making malleability harder (and hopefully
impossible someday), but this will take a long time. For example, 0.8
not supporting non-DER encoded signatures was a step in that direction
(and ironically, the trigger that caused MtGox’s initial problems
here). In any case, this will take years, and nobody should wait for
There seem to be two more direct problems here.
* Wallets which deal badly with modified txids.
* Services that use the transaction id to detect unconfirming transactions.
The first is something that needs to be done correctly in software –
it just needs to be aware of malleability.
The second is something I was unaware of and would have advised
against. If you plan on reissuing a transaction because on old version
doesn’t confirm, make sure to make it a double spend of the first one
– so that not both can confirm.
I certainly don’t like press making this sound like a problem in the
Bitcoin protocol or clients. I think this is an issue that needs to be
solved at the layer above – the infrastructure building on the Bitcoin
system. Despite that, I do think that we (as a community, not just
developers) can benefit from defining a standard way to identify
UPDATE: Rick Falkvinge has provided a good summary of the problems:
Here’s the real problem: MtGox is running its own homebuilt bitcoin software, and has not cared to update and upgrade that software along with the developments of the bitcoin protocol. Recently, after a very long grace period, the bitcoin protocol tightened slightly in order to disallow unnecessary information in transaction records, and did this to fix the malleability problem that MtGox blamed.
So the problem of malleability remained at MtGox, while having been fixed in the rest of the world. This – the discrepancy itself – was the root cause of the problem, because it meant that MtGox started issuing invalid transaction records for bitcoin withdrawals. Obviously, they were rejected by the bitcoin network.[...]
What this means is that MtGox wasn’t the subject of some skilled hacking related to transaction malleability. Instead, bad code hygiene was causing MtGox to broadcast invalid transactions, which could trivially be corrected and re-broadcast, causing all these problems downstream.
Original content by Chris, copyleft, tips welcome