Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 

Not Good Enough For Government Work

By Phil Factor,

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.

Total article views: 266 | Views in the last 30 days: 38
 
Related Articles
FORUM

System databases

System databases

FORUM

DBCC CHECKDB - System databases

DBCC CHECKDB - System databases

FORUM

Moving System Databases

Moving system databases to non system paritition

FORUM

701: There is insufficient system memory to run this query

701: There is insufficient system memory to run this query

FORUM

Lost model.bak from system database

Lost model.bak from system database, unable to add new database

Tags
bitcoin    
editorial    
 
Contribute

Join the most active online SQL Server Community

SQL knowledge, delivered daily, free:

Email address:  

You make SSC a better place

As a member of SQLServerCentral, you get free access to loads of fresh content: thousands of articles and SQL scripts, a library of free eBooks, a weekly database news roundup, a great Q & A platform… And it’s our huge, buzzing community of SQL Server Professionals that makes it such a success.

Join us!

Steve Jones
Editor, SQLServerCentral.com

Already a member? Jump in:

Email address:   Password:   Remember me: Forgotten your password?
Steve Jones