Introduction
By now, the story of Mt. Gox is coming to a close. Once the lawsuits are settled, it seems this chapter of Bitcoin History will be finished. Many people know Mt. Gox and what happened (they used an insecure password, got hacked and lost thousands of Bitcoin).
But did you know Mt. Gox had made some oopsies in the past too? They were one of the first victims of the transaction malleability attack (https://en.bitcoin.it/wiki/Transaction_Malleability). From what I can tell, some attackers withdrew Bitcoin from Mt. Gox, then malleated the transaction such that the transaction ID would change. At this point Mt. Gox would see that the withdrawal never went through (the tx ID they had in their system is no longer in the mempool or in any block), and so they would start another withdrawal.
I think one of the most interesting displays of Mt. Gox's incompetence is when they destroyed around 2000 Bitcoin in a single block due to one mistake. The infamous block 150,951 has losses totalling over 2600 Bitcoin that can't ever be recovered.
Inside one of the transactions
By far the biggest loss was in the transaction aa62bdd690de061a6fbbd88420f7a7aa574ba86da4fe82edc27e2263f8743988, which destroyed 367.758 BTC
Notice anything strange? Lets inspect the UNKNOWN output further:
If you're familiar with Bitcoin Script, you might have spotted the issue already. For those not in the know, let me briefly explain what happened. A normal P2PKH output's locking script looks like this:
- Compute the hash of the public key that was put on the stack
- If the public key hash matches, then check that there is a valid signature on the stack for that public key
- If these conditions are met, you can spend the output!
But.. that's not what this output does. Instead of pushing a public key hash to the stack, it simply pushes a 0. So what this output is saying is: If you can provide a public key that hashes to 0, and you have a valid signature for that public key, you can spend it.
But there is no public key that hashes to 0! Even if we were to start finding it, it'd take us far longer than the heat death of the universe to find such a special key. Thus this output is unspendable. Infact it gets even worse; as far as I can tell OP_0 pushes a single byte to the stack. A RIPEMD-160 hash is 20 bytes. So this script is just not valid at all, because OP_EQUALVERIFY would always be false (comparing a 20 byte value to a 1 byte value).
Thus this, and all other similarly malformed transactions in this block are unspendable. Here's a list (thanks bitcoin-supply.com):