Using passwords after they've been known to be compromised. Check.
Storing passwords protecting north of a million dollars in an online password storage system and not even using the provided two-factor auth. Priceless.
This is just like the Mtgox guys claiming the bcrypt was not good after getting caught using unsalted MD5.
This is amateur bullshit and the lack of actual penalties makes me think I should have finished the exchange I started writing. You know, one where I would have the common sense to store financial values as decimals and not floats.
These are such naively simple mistakes, it just is hard to fathom.
The first reply's conclusion is spot on
You failed to disable Mt.Gox API,
You failed to protect mt. Gox with a Yubikey,
You failed to change Lastpass password,
You failed to protect Lastpass with one of their many 2nd factor auth. (some free)
Surely you mean integer, not "decimal", right? I'm not an expert, but to my understanding none of the values in the bitcoin protocol are expressed as base-10 fractions.
It's a nit, obviously, but if you're going to ding someone for naive mistakes...
Fixed-point DECIMAL representation in the database is just as good as storing Bitcoin values as integers. Baked into the field definition is the amount of precision. And Python and other languages have features to work with fixed-point numbers. This approach relieves the mental overhead and complexity of converting to integers (which might overflow a 32-bit int) and back all the time.
I just looked this up (feel free to correct me if you think I've missed something): the value field in a TxOut is a 64 bit unsigned integer. It's true that by convention the unit is 1e-07 BTC (i.e. a decimal fraction), but nothing in the protocol actually cares, the "decimalness" is just in what you call it. Implementing this with decimal math is just wrong, and likely to break your implementation due to subtle bugs. Storing it in a database as a decimal fixed point is plausible as it prints nicely, but in no way would I consider that choice "just as good as" a quantity that was designed to fit in a native machine word.
Yes, the internal representation of Bitcoins is the 64-bit unsigned INT, but I'm talking about storing customer account balances, trade prices, etc. I would not use DECIMAL if I were writing an alternative client for Bitcoin or for some other software that must create network transactions at a low level.
Even the RPC protocol for the main Bitcoin client returns fixed-point numbers and expects non-integers for input arguments [1].
But I think we can all agree that using FLOAT for this kind of thing is just plain wrong.
(Ironically this is exactly what I was doing as the language I was using didn't/doesn't [actually rather annoyingly] support decimal types natively so I have various currency types which have different levels of precision and I store BTC as "natively" as possible). That and my code never progressed terribly far and it would have had many more (qualified) eyes looking at it from a number of angles (security, financial data, integrity, replication, etc) before it would've touched the Internet.
Using passwords after they've been known to be compromised. Check.
Storing passwords protecting north of a million dollars in an online password storage system and not even using the provided two-factor auth. Priceless.
This is just like the Mtgox guys claiming the bcrypt was not good after getting caught using unsalted MD5.
This is amateur bullshit and the lack of actual penalties makes me think I should have finished the exchange I started writing. You know, one where I would have the common sense to store financial values as decimals and not floats.
These are such naively simple mistakes, it just is hard to fathom.
The first reply's conclusion is spot on
You failed to disable Mt.Gox API,
You failed to protect mt. Gox with a Yubikey,
You failed to change Lastpass password,
You failed to protect Lastpass with one of their many 2nd factor auth. (some free)
This is embarrassing to watch.