This is a guest editorial from Phil Factor as Steve is on sabbatical.

Although there have been a number of instances where bitcoins have been, effectively, stolen from accounts, the most interesting bitcoin disasters for those of use using relational databases are the ones that exploit the lack of ACID compliance in the systems that are so often used for trading Bitcoins, recently brought to our attention by Denny Cherry.

Last year, On 3rd of March this year, the FlexCoin Bitcoin exchange folded after someone exploited the fact that the application FlexCoin used provided only ‘eventual consistency’ and managed to withdraw 896 BTC in the hot wallet by making a number of simultaneous requests to transfer coins from one account to another. There was a flaw in the code.

On March 4th, 2014, about 12.3% of the BTC on Poloniex was stolen. This was the same exploit in a system that couldn’t handle concurrent transactions.

There have been other exploits.

The problem, of course, was that the systems were intended to process complete transactions one at a time, and the ‘databases’ used had no concurrency. However, this was not enforced by a queuing system. There was no isolation, and there was only ‘Eventual Consistency’. Sure, there are uses for such things as ‘eventual consistency’ as an alternative to ACID as long as you don’t mind losing records or accidentally trading the same thing twice.

The science of online trading systems is extremely complex, and transactional integrity is at the heart of it. Although we tend to be impressed by the shiny new things in SQL Server, the part of the product that takes enormous effort and expertise is the robust concurreny, and all that is implied by that. Not every application needs that: for a social-networking website, you could even use some NoSQL ‘persistence layer’ like MongoDB.

It is very difficult to explain in simple terms why the principles of relational database are so important. To be able to safely determine whether a system requires a relational database, or can alternately, be entrusted to a NoSQL startup, requires a great deal of expertise. Sure, there is room for variety and experiment with databases and RDBMSs aren’t the answer for every problem, but it isn’t really a decision for the unqualified. If you get it wrong, as the Bitcoin amateurs did, real people and businesses can get hurt.