Transaction Malleability Attack

On February 10, 2014 — three days after Mt. Gox suspended withdrawals — this transaction was confirmed in Block 285,160. It moved 1,882.71 BTC ($1.56M at the time). It is a confirmed malleated transaction — its scriptSig uses a non-standard encoding that changes the txid without invalidating the signature.^†

The attacker used the most common malleation technique (28,595 of 29,139 documented attacks): replacing the single-byte push opcode with OP_PUSHDATA2, which uses a 3-byte encoding to push the same data. The signature and public key are identical — only the push opcode changes.

The txid is SHA-256d of the entire serialized transaction, including every byte of the scriptSig. Changing even one byte — even a push opcode that doesn't affect the signature — produces a completely different hash.

The original transaction (with txid X) was broadcast by the sender. The attacker intercepted it, replaced the push opcodes, and rebroadcast the malleated version (txid Y). The malleated version won the race to be mined in Block 285,160. The original txid X never existed on the blockchain.

Mt. Gox tracked withdrawals by txid. When a customer requested a withdrawal, the exchange would broadcast a transaction and record its txid in the database. An attacker would:

1. Request a withdrawal from Mt. Gox
2. Watch the mempool for the withdrawal transaction
3. Malleate the scriptSig (replace 47 with 4d 4700)
4. Rebroadcast the malleated version
5. If the malleated version confirms first, the original txid "disappears"
6. Contact Mt. Gox support: "My withdrawal never arrived"
7. Mt. Gox looks up the original txid — not found on-chain — and re-sends the BTC

Using Google BigQuery's public Bitcoin dataset, we can find confirmed malleated transactions — those whose scriptSig starts with 4d (OP_PUSHDATA2) instead of a normal single-byte push opcode. During the Mt. Gox attack week (February 7–28, 2014), the largest confirmed malleated transactions include:

According to Decker & Wattenhofer (ETH Zurich, 2014), 35,202 malleability conflict sets were detected between January 2013 and February 2014, involving 302,700 BTC. Of 28,595 attacks using the OP_PUSHDATA2 technique, 5,670 (19.46%) successfully confirmed the malleated version. The researchers concluded that while malleability attacks were real, they could not account for Mt. Gox's claimed loss of 850,000 BTC.^†

Bob, trusting the original txid, had already created transaction TX_B that spends his newly received coins. TX_B references TX_A's original txid as its input — but that txid doesn't exist anymore.

Bob's coins exist — they're in the output of TX_A' (txid f9e8d7c6...5432) — but TX_B points to the wrong txid. Bob must create a new transaction TX_B' that references the correct (malleated) txid.

Now imagine Bob is an exchange. Alice requests a withdrawal. The exchange sends TX_A, records txid a1b2c3d4...7890 in its database, and waits for confirmation. Alice (the attacker) malleates TX_A before it confirms.

Alice contacts support: "My withdrawal never arrived." The exchange looks up the txid — not found. They re-send the BTC. Alice has now received double the intended amount. Repeat this thousands of times across automated systems, and you have the Mt. Gox exploit.