Bitcoin Transaction Malleability Theory in Practice – Ruxcon Australia 2014

Two weeks ago we gave a talk at the Ruxcon 10 conference in Melbourne, Australia titled "Bitcoin Transaction Malleability Theory In Practice". Despite having the same title as our Blackhat USA 2014 talk, we came to Melbourne with some new insights that we'd also like to share with you here on the SpiderLabs blog.

During the presentation we demonstrated one type of transaction malleability involving the manipulation of the length part of the "Scripsig" using PUSHDATA Opcodes (PUSHDATA1, PUSHDATA2 or PUSHDATA4), thus changing the hash of the transaction without harming its validity.

The block chain is the best place to look for signs of transaction malleability attempts that happened in the past. Tracking the demonstrated type of Transaction Malleability is also quite simple. All one has to do is search for transactions that use the PUSHDATA Opcodes redundantly.

We have used the following Python code to track suspected malleable transactions:

Figure1: Searching for transactions attempting to exploit Transaction Malleability

This code inspects the value of the first byte of Scriptsig. If it detects the use of one of the Opcodes (PUSHDATA1, PUSHDATA2 or PUSHDATA4), then it evaluates the length field. If this value could be represented without the use of this Opcode, there is a high probability that the transaction is attempting to exploit transaction malleability.

If, for example, the code detects the use of PUSHDATA2 (0x4d) Opcode at the beginning of the Scriptsig and the actual length denoted by the length field is lower than 0xff, then the use of that Opcode is redundant. It's redundant because the length of the Scriptsig could have been expressed by a single byte length field, and therefore the code marks this transaction as a malleable transaction.

We've searched the block chain for malleable transactions in the past year and a half and the results were quite surprising. In the following chart you can see a tremendous uptick in the use of "suspected" malleable transactions during February 2014:

Figure2: Malleable transactions accepted to the block chain

Basically, no-one used this technique either before or after this short period of time. A closer look tells the whole story:

Figure3: Zoom in on February 2014

Apparently, after the announcement that Mt.Gox was the victim of a Transaction Malleability attack, a lot of attempts were made to steal money through the Bitcoin network.

The total number of transactions that were mutated and inserted successfully into the block chain is approximately 5,585 transactions with approximately 60,000 Bitcoins involved and with more than 9,000 unique wallets addressed.

When taking a closer look at the suspected malleable transactions we were able to find, based on the source of the wallet address of the incoming Bitcoins, who were the targets of those so-called malicious transactions.

In general, according to our findings, the targets of the various malleable transactions could be divided into four main groups:

1. Bitcoin betting services such as "SatoshiBones" and "SatoshiDice"
2. Bitcoin trading services such as "BTCe" and "BITSTAMP"
3. Testing
4. Wrong usage of the attack

According to our findings, however, most of the attempts to attack those targets failed and didn't generate high revenue for the attackers. According to our calculations, the total amount of stolen Bitcoins is approximately 116 Bitcoins, which is much lower than the potential of 60,000.

The chart in Figure 3 shows that after February 11, 2014 the total amount of mutated transactions, which were successfully inserted in the block chain, has practically zeroed. Although the formal patch to the Bitcoin client was released only a month later on March 19, 2014.

We don't know for sure what caused this sudden drop but we do have two main theories that if they occurred simultaneously could explain what happened:

• After the Mt. Gox announcement, trading and betting sites were extremely cautious - double-checking every transaction coming their way trying to avoid the transaction malleability scam. Therefore, most of the attempts to steal Bitcoins from those sites failed, which caused the attackers to give up on the attacks.

• On February 11^th, a fix to the transaction malleability was committed to the Bitcoin client code. We believe that the biggest mining pools applied this fix immediately and didn't wait for the official patch. Since those pools cover most of the mining power of the Bitcoin network , the effect was immediate and almost all of the mutated transactions were filtered out.

Although the patch to the Bitcoin client was released almost a year ago, it still doesn't guarantee that other types of transaction malleability will not pop up in the future. Since this problem is critical and has already caused damage to Bitcoin trading sites, we recommend that all companies dealing with Bitcoin rely on something else in addtion to transaction IDs when tracking the route of Bitcoin money. Especially when it comes to rejected transactions. In those cases, before generating a new transaction to compensate over the failed one, it is important to check for the rejection reason and to check whether another transaction with a different transaction ID didn't already pass the same amount of Bitcoin to the same wallet. This "double check" is important to avoid a heist.

To see our live demonstration of a transaction malleability please refer to our previous blog post.

This blog post was written by Daniel Chechik and Rami Kogan.