Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Or it could, again, be stupidity by MtGox:

This was a "test account" that had no real user attached to it. After all, if the trade is internal on MtGox, it's just a double in a database.

If that is the case, then hell yes, I can see why MtGox would want this rollback.



That's a really good point. Who says that there really was anyone with that many bitcoins in their account? Maybe someone just hacked the database, put 500,000 btc into an account, and then sold them on the market? We know the user database was dumped, so why shouldn't we think that someone edited the account balances too?


The way I understand bitcoin is that you can't simply sell coins made by adding them to a db record. Perhaps the MtGox system can artificially generate the appearance of those coins, but the actual validation of the transaction by the network would have failed.


The way I understand Mt. Gox is that they have a giant pool of real btc. They are the "owner" of these btc. So, for instance, if your account says you have 3000 btc, then your 3000 is just an entry in a database, and the only time that actually becomes a bitcoin is when you cash out the coins from Mt. Gox. At that point, they give you the amount of coins that you requested to be withdrawn from their giant btc pool. So, in other words, there aren't actually any specific bitcoins that are assigned to you specifically. You essentially own an IOU for 3000 bitcoins that you can cash out at any time. That's also why they can roll back transactions, because no bitcoins are actually transfered in their system, only database entries that state who owns how many bitcoins. That's why I think someone could update an account's bitcoins balance to any number, and then sell them on the market, because you're not really transferring bitcoins. You're transferring IOUs for bitcoins in a database.

Judging by the amateur security issues they've had lately, I think it's highly unlikely that they have the right controls in place to catch something like that automatically.


Or, to analogize, your MtGox balance is a gold certificate, MtGox is the bank with the actual gold in its vault, and someone just robbed the bank.


I imagine that all BTC available for trade at MtGox are in a MtGox-owned wallet. All trades are just done in their database, and a transaction only hits the bitcoin network when a user wants to withdraw BTC out of the market.


In that case, while adding fake BTC will not let you actually withdraw coins, it would allow one to issue mass sell orders and crash the price for BTC. Then the exploiter could purchase them at their lower valuation.

'Sell' fake coins. Crash the price. Buy 'real' coins. A virtual coin laundering. Fascinating.


It seems the hacker got access of a copy of the database by compromising the machine of an audit.

If this is really the case, he couldn't possibly edit the main database with only that.


Unless an admin reused a password somewhere.


> After all, if the trade is internal on MtGox, it's just a double in a database.

Dude, don't use double to represent money.


There are 21 million bitcoins and they divide down to 8dp, so you need 16 decimal digits to represent them exactly. Coincidentally (?) double precision floating point is capable of precisely representing exactly 16 decimal digits.

http://en.wikipedia.org/wiki/Double_precision

So using double is in fact perfectly OK in this case.


16 digits of precision != 16 digits of accuracy.


Doubles are capable of accurately and precisely representing 16 digit decimal numbers.


Not 10^100 + 0.0000000000000001


A 116 digit number is not a 16 digit number.


+1 -- I keep warning people about this, but them don't seem to get it through their thick skull :)

The bitcoin client and protocol itself doesn't use doubles internally, but fixed-point numbers. I don't know about MTGox, though.


If this was the case though, don't you see a really big issue? They're running test data through a financial production system? That wouldn't just be retarded, it would be illegal anywhere else. If you're *SX and creating fake money in a real system you're going to get into a lot of trouble.


If it was test entries in a database, then how could the OP transfer real BTC to his wallet?


I don't know how Mt.Gox arranges it's accounts, but it's possible it came from the mt.gox BTC pool?


Should mt.gox even be allowed to participate in trading? Seems like a massive conflict of interest to me. If it was their account and their account could perform trades, then that sounds like a big problem.


Unless it was the BTC mtgox directly own, that would mean that the BTC you upload aren't the ones that are transferred when you trade (remember BTC are unique). Although I haven't used MtGox, I was pretty sure that it is the case that BTC you upload are the ones that are transferred.


When you transfer money to MtGox, you're essentially giving it to them. They give you a unique address to send to (so they know who sent the money to them), but after that transaction they have your money. Then, they just update the DB reflecting you have X amount of BTC in your account. As you trade with other people on the market, your respective accounts are updated in the DB. When you want to withdraw, you tell MtGox where to send the money. They check the DB and deduct that amount, and send that money from their big stash of everyone's money.

That is why trades can be instantaneous, and don't require confirmation the network (except when you are sending to or withdrawing from MtGox itself).

In this case, if you could hack the DB and convince MtGox that you had more BTC in your account than you really did, you could still withdraw BTC, but there would no longer be enough BTC for everyone to withdraw.


Which is why a centralized account holding the majority of BTC out there breaks the entire model.....


> After all, if the trade is internal on MtGox, it's just a double in a database.

Floating point representation for financial data. That does sound like something MtGox would do...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: