The True Cost Of Bugs - Bitcoin Errors
Written by Mike James   
Monday, 03 March 2014

The news that bitcoin exchange Mt Gox has gone out of business hasn't had the really big effect on the cyber currency that you might have expected, but it could contain a lesson of the difficulties in getting currencies and software to mix. 


There is an argument that cyber currencies should be treated as safety critical systems. In most cases a bug is annoying, but in a safety critical system a bug can result in injury or death - perhaps many deaths.

You might think that it is too much to put a software-implemented currency into the same category as, say, an automotive control system, but there are indications that the so far casual approach to implementing bitcoin's security and transaction software isn't acceptable.




Bitcoin has a very well worked out, if slightly low tech, approach to security. You could say that there is nothing novel in the algorithms it uses - it is the way they work together, plus some clever social engineering, that has made bitcoin the phenomena it is today. 

However, there is more to bitcoin than its security methods. It also defines a number of transaction mechanisms and these are far less well known and examined.  

For example, each transaction contains a small script that has to be satisfied before bitcoin can be spent. The original intention was that this script could be used to provide a level of flexibility to the transaction that would make up for the fact that there is no central bitcoin banker. For example, the script could be used to implement complex contracts such as escrow and placing deposits that cannot be spent until the full deal is completed.

The default script simply checks that the person who has the bitcoin is the person authorized to spend it. It does this by including the destination address and demanding that the new owner supplies a public key and a signature to prove that they own the corresponding private key. 

So far so good, but back in 2011 Mt Gox made a programming error and included a zero address in transactions, with the result that it was impossible to spend the coins. That is, the transaction completed and the coins were transferred but the new owner could never spend them. This simple bug removed 2609 bitcoins from circulation and lost around $1.5 million at today's prices. 

There are other ways that bitcoin can be lost from the system - typically using a destination address without access to the private key. However, the script is also the cause of a second problem - transaction malleability. It is possible to change the op codes in the script so that it still works, but  this changes the transaction hash. This effectively creates two transactions that move the same bitcoin from the owner to the same destination. If all goes according to planb only one of these will be added to the block chain by bitcoin miners. 

There is another minor problem caused by partial spending. If you spend one of two bitcoins you own then you can only do this by transferring the ownership of both bitcoins - one transaction to the person you are paying and one back to yourself as "change". If the block chain accepts a modified form of the first transaction it could cause the second "change" transaction to fail because the hash is different. Your solution is to resubmit the change transaction.  

The part of the picture that isn't clear is whether or not malleability can be used to double spend or otherwise steal bitcoin. Mt Gox originally suspended withdrawals blaming a malleability attack. It seems that what was happening was that the hash value was being used to to track transactions and when an altered block was accepted by the it was assumed that the transaction had failed when it had in fact worked. In this case Mt Gox is said to have sent the bitcoin a second time so paying twice. 

Now Mt Gox has admitted that 750,000 customer bitcoins have been "lost" and 100,000 of its own have "disappeared". After this loss of approximately $500 million it isn't surprising that the company has declared bankruptcy. The exact details of how the bitcoins went missing hasn't been explained but it is very likely to be another bug in the transaction mechanism. To quote from a recent Mt Gox press release:

"At the start of February 2014, illegal access through the abuse of a bug in the bitcoin system resulted in an increase in incomplete bitcoin transfer transactions and we discovered that there was a possibility that bitcoins had been illicitly moved through the abuse of this bug.
As a result of our internal investigation, we found that a large amount of bitcoins had disappeared. Although the complete extent is not yet known, we found that approximately 750,000 bitcoins deposited by users and approximately 100,000 bitcoins belonging to us had disappeared.
We believe that there is a high probability that these bitcoins were stolen as a result of an abuse of this bug and we have asked an expert to look at the possibility of a criminal complaint and undertake proper procedures."

So the next time you find a long standing bug in some code, just feel good about the fact that you don't code currency transactions - unless of course you do. 




More Information

A great deal of the technical information in this report has its origns in the excelent Ken Shirriff's blog which I recommend you read if you want more detail. 

Bitcoin Foundation Update on Transaction Malleability

Related Articles

Chain Easy Bitcoin Development       

ASICMINER's Immersion Bitcoin Miner - How Far It Has Gone       

Optimize Mining Bitcoin       

Hardware Mines Bitcoins Faster       

Bitcoin Hits 10.5 Million - Mining Payment Halves

Bitcoin Idea Gets $500,000 funding

Bitcoin still standing - but panic takes over

Inside Bitcoin - virtual currency

Bitcoin gains an open source client

Digital currency lets GPU cycles print money 

Hashing - The Greatest Idea In Programming       


To be informed about new articles on I Programmer, install the I Programmer Toolbar, subscribe to the RSS feed, follow us on, Twitter, FacebookGoogle+ or Linkedin,  or sign up for our weekly newsletter.


kotlin book



or email your comment to:



BusyBeaver(5) Is 47,176,870

The thing about the BusyBeaver function is that it is very easy to understand, but very difficult to compute. We now know its value up to 5, which isn't much progress for more than 50 years work.

.NET 9 Preview 6 Improves ARM64 Code Generation

.NET 9 Preview 6 is now available with a wide range of improvements to the runtime, SDK and ASP.NET Core.

More News


Last Updated ( Monday, 02 June 2014 )