Flattening Bitcoin: What is Transaction Malleability?

The past few weeks have not been good for Bitcoin. Mt. Gox shut down withdrawals due to concerns over transaction malleability. The same flaw was reportedly used to loot more than 4,000 BTC (worth more than 2.7 million US dollars) from Silk Road 2.0 Deep Web marketplace. These stories, together with others that have shaken the confidence of the Bitcoin community, have pushed the value of Bitcoin to just slightly over 600 US dollars, a significant plunge from its peak values of more than $1200.

So, what is transaction malleability, and why has it caused such a big problem for Bitcoin?

Imagine I’m going to send you a check numbered 700 for $25. If you know that I only track finances by check number, you can carry out a transaction malleability attack against me as well.

When you receive the check from me, you change the number by, say, adding a “1″ to the end, making the number 7001. (For the purpose of this discussion, let’s suppose you can do this without the bank noticing.) By itself, changing the check’s number has no impact to the value of this transaction. You then wait, then tell me that you never got the check.

If I now look in my bank account I see check 7001, but not 700. If I send a new check you win – you cashed two checks from me. Even if I don’t send out a new check, you still have the original check, which can still be cashed.

This is the same idea behind the transaction malleability vulnerability as exploited in Bitcoin.

Let’s say you have two parties, Alice and Evan. Alice intends to pay Evan some Bitcoin. Evan wants to scam Alice out of her Bitcoin. When Alice submits the transaction to the Bitcoin network, it is identified by a hash value. One of the elements of the hash value is the ScriptSig field.

This signature field verifies the authority of this transaction to spend the Bitcoin in the source transaction. These signatures are encoded in a format known as DER. It is rather simple using a type, length, and data construct. One possible type is “0″ or null, or no data. If the attacker adds one or more “0″ bytes to the DER, it is still a valid signature for that transaction, however the transaction will be known by a different hash value.

Evan would watch the Bitcoin network for his transaction (from Alice to Evan). When he finds one, he takes a copy and edits it so that the hash value changes. She submits many copies of the new “transaction” to the network. If he is lucky, her transaction may beat the legitimate transaction into a block on the block-chain. If Evan is successful, Alice’s transaction will get rejected because the incoming transaction will have already been spent.

If Alice was only using transaction numbers to keep track of transactions, she would see that the transaction failed, and maybe an automated system would re-issue the transaction. You can see where this is going. If Evan fails, he gets the (original) Bitcoin, if successful, he gets twice the money.

As scary as this sounds, it is no match for a well-designed payment tracking system. This is a flaw in how exchanges and merchants keep track of payments rather than anything in Bitcoin itself. The hash value should not be used as the sole tracking identifier by Bitcoin users, as it is prone to modification by outside parties. That said, some of these parties are already implementing changes to ensure that the signature can only have one value.

Always wait for confirmation on outgoing and incoming transactions before considering them paid in full to avoid “double payments” like those that occurred here. Confirm transactions by source address as well as transaction hash.

Post from: Trendlabs Security Intelligence Blog – by Trend Micro

Flattening Bitcoin: What is Transaction Malleability?