I somewhat expected to start seeing my "held" BTC balance tick downwards ever so slightly as transaction fees are being collected, but it hasn't happened. Maybe it's a manual process now, but Roman should automate it. Continuous, incremental progress toward getting everyone paid back, even if it will take years, would be a welcome sight.

Intuitively, it's:
http://blog.bitfloor.com/

Thanks for the attempt at transparency, but this is too vague. What was the problem? How did you correct it? You're on the Bitcoin Forum; you can get technical with us. Humor us. We need to want to trust that you know what you're doing.

Yeah, I know. I was responsible for several dozen of those.

On successive reconnection attempts by my bot (which uses an exponential back-off):


Ouch.

Why is Bitfloor so unstable, even with scant traffic?

The symptom is over. We have no way of knowing whether the problem has been solved since Roman hasn't been forthcoming about what's going on, either here or on the Bitfloor blog.

Still down. This is not helping Bitfloor's already sullied image.

Using the API, I was able to cancel all of my outstanding orders and withdraw my entire BTC balance. The transaction shows up on BlockChain.info now, so I'd guess it'll confirm.

If this is another hack, they haven't emptied out the wallet yet.

EDIT: It has one confirmation now.

Bitfloor's web site is having gateway timeout errors now. Repeat attack? Seems similar to the symptoms last time. I'm going to pull out my BTC immediately if it comes back up, just to be safe. I had the opportunity to do that last time, but I didn't. If this actually is a second attack and it's successful, I'm finished with Bitfloor.

Interestingly, the Bitfloor API still appears to be functioning.

Common doesn't imply good. The Keynesian model of economics is common, but that doesn't make it good.

This whole "security model" looks like something designed by someone with no education in cryptographic protocols.

Neither the secret key nor the passphrase nor the signature are actually needed to ensure the security and authenticity of customers' API requests. The API key is already sufficiently large (128 bits) to avoid a brute force attack, and it's never transmitted except over an encrypted (SSL) connection, and the client won't send it if the server's certificate doesn't validate, so neither a MITM nor an eavesdrop are possible. Also, SSL does already include nonces, so a replay attack is not possible, and thus the nonce field is unneeded, too.

Of course, there is still the possibility of a database dump, which would reveal all API keys to the attacker. Really, you should be requiring client-certificate authentication on the SSL connections to the API server, and your database should contain certificates for all of your API users. Then it wouldn't matter if an attacker obtained a dump of your database; they still couldn't pretend to be any of your users because they wouldn't have the private keys associated with those certificates.

Basically, all of these extra HTTP header fields are clumsy attempts to solve a problem that is already solved in SSL. And by the way, you're supposed to prefix non-standard header field names with "X-" so they don't conflict with any future standards.

Given the fact that all customer deposits of BTC are now held in an offline (cold) wallet, and the online (hot) wallet contains only Roman's own funds with which to fulfill BTC withdrawals, it's likely that the online wallet has bottomed out. Perhaps a lot of users who had USD still sitting on the exchange when it reopened decided to buy BTC and withdraw it. That would have put a strain on the online wallet. Roman will have to refill it from the offline wallet.

The error message could be better.

My ACH withdrawal of ~$540 hit my bank account this morning, too.

Maybe someone is waiting for the statute of limitations to run out? LoL, just kidding. I don't suspect Roman in the least.

I look forward to the day when valuing BTC is a no-brainer for a judge but valuing USD would be laughable. (Think Zimbabwean dollars, Weimar marks, or Confederate dollars.)

"SAVE US, PO-PO!" Give me a break. The police aren't going to be able to do jack shit; Bitcoin was designed with anonymity and irreversibility as core features. And the police aren't going to care either, as Bitcoin is still seen as a fringe element. It's like how murders of homeless people and prostitutes largely go unprosecuted.

ADDENDUM: You can't have your cake and eat it too. If you want your money to be free from the State, then you can't go running to the State when things don't go your way.

Bet has not yet been approved.

Wrong. There is a way to know. But it requires the code for the entire system, from front end to back end, to be published for public scrutiny. And not just the program code, but the server configs and software versions and everything. In fact, it should be possible for the entire file system of every server to be available via public, read-only, anonymous FTP — minus the one directory containing the private keys and the one directory that holds the database table containing the users' personal information, if such a table exists. There is no reason that the remainder of the systems' contents shouldn't be held out for the light of day to wash over them. Security through obscurity is no security at all. Cryptographic algorithms are secure despite their method of operation being public knowledge. The same should be true of web sites.

LoL! They do. Those hackers are known as "banksters."

I'll point out that Mt.Gox is a Japanese company. The culture over there is even less inclined to admit fiduciary mistakes than it is in the Western world. Look at TEPCO for a prime example. If the underbelly of Mt.Gox were being eroded away by security breaches, they might not say a word.