The split between a hot wallet holding the working float and cold storage holding everything else is the oldest piece of received wisdom in exchange security. Two well documented incidents show that the split is only as good as the routine deciding which side of the line a given file ends up on.
What Failed at BitFloor in September 2012, and What Did Not
The best account of the BitFloor loss came from the operator himself, in public, the day after it happened. On 4 September 2012 at 5:08 in the afternoon, the exchange's founder, posting as shtylman, opened a thread on Bitcointalk headed "bitfloor needs your help!". The servers had been compromised the previous night, and the theft, in his words, took the vast majority of the coins BitFloor was holding on hand. Pressed in the same thread for a number, he gave roughly 24,000 BTC and described it as almost all of the bitcoin.
He was specific about the mechanism, which is what makes the thread worth reading rather than the coverage that followed it. The intruder reached an unencrypted backup of the wallet keys. The actual keys, he noted in the same sentence, live in an encrypted area. A few replies later he explained where the backup had come from: it was created when he manually did an upgrade, and it ended up in an unencrypted location on disk. A companion thread was opened alongside it to track the stolen coins as they moved.
Nothing cryptographic broke that night. The encrypted key store did exactly what it was built to do, and the operator says so plainly while the incident is still unfolding. What defeated it was a copy, in plaintext, sitting on a machine reachable from the network because a maintenance procedure had put it there and no step afterwards had taken it away.
This is why cold storage is better understood as a procedure than as a technology. The technology is trivial: private keys that are not on a networked machine cannot be read off one. The difficulty is entirely in the discipline that classifies every piece of key material, every time it is written, including the copies produced incidentally during an upgrade, a migration or a backup. Those copies are precisely the ones nobody classifies, because they are not created by the part of the process anybody wrote a policy for.
The Same Question, Answered the Other Way
Eighteen months later the same question arrived at Mt. Gox from an unlikely direction, and got the opposite answer. After the company applied for civil rehabilitation, its old-format wallets, used prior to June 2011, were rescanned. On 7 March 2014 one of them was found to hold approximately 200,000 BTC, a figure the announcement gives precisely as 199,999.99.
What happened next is documented to the day. The coins went to online wallets on the 7th, and then, between the 14th and the 15th, to offline wallets. Whatever else was mishandled in that company, and the court record documents a great deal of it, the first instinct on recovering a large balance was to get it off a network-reachable machine, and it took eight days. The contrast with BitFloor is exact: one operator moved keys deliberately toward cold storage and logged when; the other had keys drift out of it as a side effect of routine maintenance, and found out afterwards.
Records and Keys Were Governed Differently
There is a detail in the BitFloor thread that gets less attention than the loss and says more about how the exchange was run. The founder states that all of the logs for accounts, trades and transfers were intact, that no records were lost in the attack, and separately that all USD bank accounts were secure. The books survived the night. The bitcoin did not.
That asymmetry is the whole lesson. Records and keys were subject to different handling routines, and the routine covering the records was the more careful of the two, which is the reverse of the priority an exchange holding customer bitcoin ought to have. A working float online and a reserve held back was the convention across the exchanges of that period, European ones included. What survives of one like BitMarket.eu is the rates and pair listings it published. Where its reserve sat was never something an outsider could check.
The thread also leaves something open. Having said the dollar accounts were secure, the founder floated a shutdown followed by account repayment using currently available funds, and what fiat on hand could have done against a shortfall denominated in bitcoin is not answered anywhere in it. His own summary of the damage is the clearest statement of the split: no records were lost in this attack.
Questions About Wallet Practice
What is the difference between cold storage and a hot wallet?
A hot wallet holds keys on a machine connected to the network, so it can sign withdrawals automatically and cover day-to-day flow. Cold storage keeps keys on hardware that is not reachable from the network, which makes remote theft impractical and makes every withdrawal from it a manual operation.
Was BitFloor's encryption broken?
No, and the operator was explicit about it at the time. The encrypted key area held. An unencrypted backup of the same keys, created during a manual upgrade and left in a readable location on disk, was what the intruder found.
How much was taken?
Roughly 24,000 BTC, a figure the founder gave conversationally in the thread rather than as an audited total. He described it as almost all of the bitcoin the exchange was holding on hand.
Does cold storage protect customers on its own?
Not by itself. It removes one attack path. It says nothing about whether the reserve is large enough to cover customer balances, or whether anyone outside the company has verified that it exists, which is a separate problem addressed by reserve attestation rather than by wallet placement.
Why do backups keep causing this?
Because they are produced as a side effect of other work. An upgrade, a migration or a routine snapshot can write key material somewhere no policy anticipated, and the file is not classified as key material by whoever created it. That is the exact sequence the BitFloor founder described.