Third cryptocurrency exchange becomes hacking victim, loses Bitcoin

http://www.zdnet.com/third-cryptocurrency-exchange-becomes-hacking-victim-loses-bitcoin-7000027052/

by brownbat • 12 years ago

66 55 12 years ago

nisa2• 12 years ago

FTA: Busoni said that a hacker took advantage of a processing flaw in the Bitcoin exchange post. When users submit a withdrawal request, the input is checked against your balance, deducted, and the new amount recorded within a database. However, it was discovered that placing several withdrawals all in practically the same instant meant each request was processed at more-or-less the same time, resulting in a negative balance but "valid insertions into the database, which then get picked up by the withdrawal daemon."

Isn't ACID the solution to these problems for like 30 years?

willvarfar2• 12 years ago

And withdrawals are even the classic example used in schoolbooks too...

Xylakant• 12 years ago

You can use an ACID compliant database and run into this problem, it's a classical race condition. The solution is to implement double bookkeeping and bank reconciliation, but it's tedious and complex to implement. I saw a pretty nice blog post with detailed information on the subject, but I can't remember where, didn't bookmark and my google-fu is weak at the moment. So either somebody remembers or you'll have to google yourself :)

arethuza2• 12 years ago

This one?

http://highscalability.com/blog/2013/5/1/myth-eric-brewer-on...

"What accounts for the consistency of bank data is not the consistency of its databases but the fact that everything is written down twice and sorted out later using a permanent and unalterable record that is reconciled later."

But isn't that talking about "traditional" financial institutions that (in my experience) have staggeringly complex (messy) computing environments just by the nature of how these businesses grow (e.g. lots of acquisitions).

Surely for a brand new service such a Bitcoin exchange there isn't that excuse?

nisa2• 12 years ago

It's been a few years but at least in theory ACID should avoid any race conditions. So you mean you'll face problems in a concrete implementation or due to performance optimizations? I can't image that ACID has a theoretical possibility for race-conditions - I'd like to learn if this is the case - Google did not turn up anything.

sehrope2• 12 years ago

You can use an ACID compliant database and run into this problem, it's a classical race condition.

No it's not. It's just sloppy code and/or a misunderstanding of database transactions and isolation levels. If you use an ACID compliant database like PostgreSQL it's pretty straightforward to write proper code that would not have this issue.

The main concept to understand is that you need to lock all the rows that you'll be touching before you use them. In most case this method works fine with the default read-committed isolation level.

Code that queries your database in multiple round trips and then compares the values for validity on the app side will have this problem. Anything you read could have been modified by the time you "act on" the information you read. Heck even stored procedures running on the DB itself will have this problem if run in the default read-committed isolation level.

The high level solution is to use SELECT ... FOR UPDATE and lock everything that you'll be touching before you update anything.

The solution is to implement double bookkeeping and bank reconciliation, but it's tedious and complex to implement.

This is a business requirement for any accounting/financial software but it's not a technical one. Having an audit trail, double entry accounting, and recon are business functions. You'd be crazy to design a system that didn't include them but it's not strictly required (again from a technical sense, not a business one!).

mootothemax2• 12 years ago

You can use an ACID compliant database and run into this problem, it's a classical race condition.

Isn't it a quick fix to add an ACID-friendly clause to the UPDATE statement, e.g. some pseuosql like:

UPDATE balances SET balance = (balance - amount) WHERE user_id = input_user_id AND (balance - amount > 0)

Xdes• 12 years ago

I think the solution is continuous monitoring and auditing. Keeping track of the balances is the simple part. Reconciling the balances is the complex part. Banking is inherently eventually consistent, so putting audits in place to verify integrity of the balances is critical.

mcv2• 12 years ago

Isn't ACID the solution to these problems for like 30 years?

Yes, but this is bitcoin, which is so totally unlike anything that existed before, that such outdated notions as ACID aren't valid anymore. We need to start with a clean slate and reinvent all the wheels all over again.

castis• 12 years ago

I dont know that I'd consider ACID an outdated notion.

codygman• 12 years ago

ACID is outdated? Shall we use mongodb for bitcoin?

ChuckMcM• 12 years ago

Ok that totally made be laugh!

stingraycharles2• 12 years ago

Transaction isolation is not what you think it is. Most databases run at a liberal isolation level. For example, from the PostgreSQL docs[1] you can read that they use 'read committed' as an isolation level by default. In this example, it could mean that the following could happen:

* At T=1, transaction 1 will read the current balance * At T=2, transaction 2 will read the current balance * At T=3, transaction 1 will update the current balance * At T=4, transaction 2 is in a race condition situation, since the update of transaction 1 'leaks' into transaction 2, but the last read balance in transaction 2 still is the 'old' balance.

In other words: this is an area where a lot of people introduce race condition bugs without being aware of it.

[1] http://www.postgresql.org/docs/9.1/static/transaction-iso.ht...

raverbashing• 12 years ago

What looks like is needed is a serialization of user transactions.

And also risk-avoiding schemas (in the general provisions of the business, not only on the system running it)

sergiosgc• 12 years ago

That's the default, but you can, and should, use a serializable transaction isolation level where required by the problem domain.

davidw• 12 years ago

This is a repeat from yesterday: https://news.ycombinator.com/item?id=7340908

bertil2• 12 years ago

Thank you: I was starting to wonder… Three? Wasn't that yesterday's count already?

paulgb• 12 years ago

That's the problem with a decentralized count ;)

maaku4• 12 years ago

I'm pretty sure there's been more than three exchange heists.

willvarfar2• 12 years ago

I liked the recent tweet:

"It's like all these bitcoin sites are running a bug bounty without even realizing it.."

https://twitter.com/jjarmoc/status/440927360821764097

maaku4• 12 years ago

This is why we need trustless exchanges:

http://www.reddit.com/r/Bitcoin/comments/1zgbza/i_am_buildin...

unclebucknasty4• 12 years ago

How is this insulated against the future regulatory environment? For instance, the Feds have already come down on the KYC side of things. A trustless exchange is immune to such regulation. So, why wouldn't they outlaw participation in or operation of (as a gateway or other node) same?

These are earnest questions, not statements.

dmix• 12 years ago

It changes the dynamic of the regulatory environment from enforcing a few mega-exchanges organizations to having to enforce (possibly hundreds of) thousands of vendors selling BTC for currency and consumers buying it. It would be as difficult as enforcing drug dealing and we've seen how effective that has been.

maaku4• 12 years ago

The exchange itself would be impossible to shutdown or regulate. However regulatory agencies would be able to apply pressure at the gateway interface with the real world: the banks which accept USD wire transfers and issue "USDcoin" crypto tokens, as well as perform the reverse redemption.

It is entirely possible and I would argue acceptable that regulatory authorities require KYC compliance for these gateway entities, but that only affects people moving national currency in and out of the system. It's entirely possible that people will trade and do business in USDcoin without cashing out directly through the regulated banking gateway. This is a reality that regulators will have to get used to.

Nursie• 12 years ago

Third?

I'm pretty sure it's been more than that in the last few years...

stonemetal2• 12 years ago

If you were running an exchange why would you keep everyone's money in the same wallet? It seems like you would keep a wallet per user with their funds in it. Then any attempt to double transfer would fail on the bitcoin side because their wallet wouldn't have the money.

lutusp• 12 years ago

A quote: 'However, it was discovered that placing several withdrawals all in practically the same instant meant each request was processed at more-or-less the same time, resulting in a negative balance but "valid insertions into the database, which then get picked up by the withdrawal daemon.'

I can't believe programmers are alive today who don't know what a race condition is. In the future, when parallel processing is more the norm than the exception, race conditions will be the first thing we'll have to think about, not the last.

jackgavigan• 12 years ago

The owner of Poloniex posted details of the bug here: https://bitcointalk.org/index.php?topic=499580

Third cryptocurrency exchange becomes hacking victim, loses Bitcoin

Related Stories