[muyuu]

The extra measures needed are non-trivial and should be detailed (or an alternative, like Armory, given).

Otherwise, in real life, most people take the easy way out which means a standard client without no special measures. Note that encrypting the wallets still is not good enough if your webapp needs to be able to operate it (it will typically have the means to transfer funds just there, either keys or source code capable of replicating it).

Crypto is too hard to do right to leave all that as an exercise for the reader.

[eric_bullington]

This is my last comment on this thread, since you keep repeating the same unfounded complaint. I did mention the extra measure of moving coins offsite in my original comment (which is trivial if you know how to use cron). As long as you do this, your risk of exposure is the amount of Bitcoins you accept during n interval, where n can be practically as small as you want it to be.

Also, I get the distinct feeling you're lecturing us about something you've never done. "to operate [a wallet]"?? "to transfer fund just there, either keys or source code capable of replicating it"?? How would you connect a web app, say a Ruby on Rails app, or a Django app if you're more comfortable with Python, to Armory to process Bitcoin payments? There's a new feature that's just been merged that I see would allow Armory to be used on the web, but as far as I can tell, no one is using it in production. But assuming this feature is production ready, how would you use Armory to process payments on the web? Have you actually done this? You're just mentioning a product and nothing about implementing payment processing. The extra measures needed to set up payment processing are most decidedly non-trivial and should be detailed.

Finally, I should mention that Bitcoin Armory is under AGPL (even stricter than the GPL), which means that no serious business is going to use it for payment processing since they would have to open source whatever app they are connecting it to (it's just fine to use it to store a business's Bitcoins, however, since in this case, it's not connected to your application). From the BitcoinArmory site: "Armory is licensed under the AGPL version 3, which guarantees that any derivative programs based on Armory source-code must also be open-source." bitcoind, on the other hand, is under the MIT license and can be freely used in commercial software without the obligation to share your source code.

[muyuu]

The only problem I had about your initial comment, is that someone unaware of the risks would be encouraged to do the same things that caused a gazillion hacks in the past.

The option of just having a small hot wallet and a cron script (risking just the amount in the hot wallet at any given time) is probably good enough for most people, and it's a lot simpler than the kind of crypto needed to set up a wallet that can be safely operated in untrusted media. That much is fine.

Still, hotwallets combined with limited human resources (can't have someone constantly checking the balance, cannot automate the loading of the wallet and keep that in the server for obvious reasons) usually end up in cutting corners, getting robbed and essentially financing crooks.

Cannot go around saying safe, home-made BTC wallet support is trivial for a newbie. If you think so you live in la-la land.

It's just unrealistic and conveys a dangerous message, that's all. 99% of HN's readers would be much better off using any of the already put in place payment processing systems and pay them for their years of expertise.