If you've been following the bitcoin saga you may have heard about Mt Gox's halting of currency withdrawals. Well, it's come out that due to their (completely preventable) improper transaction tracking bad actors have been gaming them. Oops.
Mt Gox (bitcoin exchange) uses surrogate key improperly and pays the price.
I've determined a long time ago that overuse of surrogate keys is a huge problem in the database industry. They encourage lazy model design and poor understanding of database fundamentals. Their main advantage over natural keys is they facilitate cheap updates of the key since it isn't used for purposes of relating. Unfortunately that can lead to disastrous consequences since the data underlying the key is often important and that is exactly what happened here.
Subscribe to:
Post Comments (Atom)
7 comments:
I sort of see your point, but I would say this is more of a coding/protocol issue than a database one. Signatures are supposed to confirm the validity of what they sign. The bitcoin one does not and no matter how the developers spin it, the process is flawed. Sounds to me sort of like the old MySQL argument that FKs where not important and it is on the developer to code around their absence in the code.
Holy cow, I just made the front page of slashdot. Note, tried submitting stories to slashdot for years and never got accepted...and now this..HA!
A bit part of this is wallet implementators not understanding the bitcoin protocol.
Just because there are hashes involved, and signatures involved does not mean you can blindly assume that the hash corresponds to something that is signed and thus immutable.
People shouldn't get involved in coding Bitcoin software unless they understand exactly what's going on and why things are structured the way they are.
I don't endorse or defend Mt. Gox's handling of the situation in any sense. But I do think it's odd that such a design issue was not addressed more proactively considering that without perfect knowledge and understanding, it's a loaded-gun that fires blanks, but fails catastrophically.
It might be just me, but I would expect a transaction id to be immutable. Otherwise what is the point?
-- It might be just me, but I would expect a transaction id to be immutable. Otherwise what is the point?
The TrxId can be immutable, wherever generated. But.... if it's the only unique constraint on the tupe, then another (otherwise identical) tuple can be inserted, since it will have a differenct TrxId. Both the code (if the coders are really out to lunch) and the datastore won't know any different.
Then I am missing something because the Wiki(https://en.bitcoin.it/wiki/Transaction_Malleability) and a Bitcoin developer Greg Maxwell(http://www.cryptocoinsnews.com/2014/02/10/mt-gox-blames-bitcoin-core-developer-greg-maxwell-responds/)
would seem to say different. In particular this from Greg Maxwell from above:
"Basically, third parties can change the transaction IDs of transactions. "
At any rate I am not impressed with either Mt Gox or Bitcoin, seems a lot of smoke and mirrors involved.
Post a Comment