5 ms·

Oh my gosh you don't expose it to the public Internet. RPC is just an API -- just because it runs over an IP address doesn't mean you run it exposed to the who

Oh my gosh you don't expose it to the public Internet. RPC is just an API -- just because it runs over an IP address doesn't mean you run it exposed to the whole world. I thought that would go without saying, but clearly I was wrong. It's just like anything you connect to via IP...including simple databases like many of the NoSQL databases. You run it on a secure internal network, and connect it to your web server, and expose the web server to the public, via a reverse proxy. This is no different. And if you send the balance to an off-site wallet every hour, or less, then you aren't exposing much of your balance anyway. If you're an exchange, it gets a lot harder since you have to figure out how much to keep on a hot wallet. But if you're just accepting Bitcoins, there's little to no risk, as long as you regularly send your balance off-site to a cold wallet. And if your web server is rooted, then they've got any balance you've exposed to your web app, regardless of whether you are running it on bitcoind or some third-party web service.

muyuu 14y ago
That's better but still this is what bitfloor ran and it got hacked. I recommend cold wallets instead. You can have your server rooted and not lose a satoshi.
- eric_bullington 14y ago
  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.
  - muyuu 14y ago
    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 14y ago
      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 14y ago

That's better but still this is what bitfloor ran and it got hacked. I recommend cold wallets instead. You can have your server rooted and not lose a satoshi.

eric_bullington 14y ago
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.
- muyuu 14y ago
  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 14y ago
    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.