That has nothing to do with why Bitfloor lost such a large sum -- they stored unencrypted keys to a wallet holding a large sum on a server that was hacked. They could have used whatever solution you or I propose and if they stored unencrypted copies of the keys to a wallet holding $250,000 worth of btc on an online computer that was hacked, the same thing would have happened.

At the time, Roman Shtylman, the founder of Bitfloor, described it: “last night, a few of our servers were compromised. As a result, the attacker gained accesses to an unencrypted backup of the wallet keys (the actual keys live in an encrypted area). Using these keys they were able to transfer the coins. This attack took the vast majority of the coins BitFloor was holding on hand.”

So it was a storage issue and had nothing to do with what we're discussing, which is how to process Bitcoin transactions. Which brings me to the question: how would you process transactions on this cold wallet you speak of? Somewhere, you have to have either bitcoind or libbitcoin running (and most business will avoid the latter because it's AGPL, unlike bitcoind which is under MIT license).

To be clear, I strongly agree with the suggestion to keep as much money as possible on cold wallets. If you are just accepting Bitcoins for payment, this can be virtually 100% of your coins. As long as you are regularly moving your coins off of the bitcoind daemon connected to your web app, you are risking very little. Hell, you can transfer the balance off-server every minute if it makes you sleep better.

Did you read my original comment? You basically just described a solution that mirrors my own, which was to send x percentage of your balance to an off-site wallet (maximizing x to the extent possible, obviously). I didn't get into how to securely store your coins off-site, since that wasn't the question.

EDIT: BTW, you do realize that Armory is a front-end to bitcoind, right? You still have to run bitcoind for Armory to work.

From their Github page:

"Armory has no independent networking components built in. Instead, it relies on on the Satoshi client to securely connect * to peers, validate blockchain data, and broadcast transactions * for us. Although it was initially planned to cut the umbilical * cord to the Satoshi client and implement independent networking, * it has turned out to be an inconvenience worth having. * Reimplementing all the networking code would be fraught with bugs, * security holes, and possible blockchain forking. The reliance * on Bitcoin-Qt right now is actually making Armory more secure!"

Yes, absolutely. If you're thinking of a low-volume, semi-manual system, you can simply generate a list of addresses, store them on a DB, and display them to customers for payment. Then send out your product/service once you verify payment has cleared on the Blockchain Explorer. That's a good, simple, low-tech way of taking care of things, as long as you carefully match addresses to customers and take care to securely store the wallet you used to generate the addresses. But assuming you can program, it's not hard to implement an automated payment processor, or to integrate a third-party API. Please don't be scared off by alarmists. As long as you are taking care not to store large sums of Bitcoins on your server, there's no problem. You can easily set a cron job to move the full balance off your wallet every minute to a cold, air-gapped, inaccessible, off-site wallet (Armory looks good for storage). As long as you're not distributing bitcoins (like exchanges have to do), you don't need to worry about keeping a large sum on the wallet you use for your app. Please feel free to contact me at the address on my profile if you have any questions (my user name is my real name).