Note to anyone who's designing cryptographic currency 2.0: stabilize the price next time. It doesn't have to be tied to USD but it should be tied to something. Control over the supply automatically gives you control over the price, you can peg to whatever you want.
Global GDP futures perhaps? It would be interesting to have a currency worth a particular percent of global output.
That part of the point of BTC though, AFAICT - no price control, no supply control.
It appeals to libertarians for this reason. Doesn't appeal to me because I like stability in my currency and am happy to have central authorities that try to ensure that, but it appeals to libertarians.
It shouldn't really matter to Amazon. Their fulfillment service is just an API for saying "take this item from your warehouse and ship it to this address". Amazon doesn't know that you're shipping things in response to a BitCoin payment, versus goodies for KickStarter backers, versus holiday gifts for customers. All BitPay is doing is integrating their API with Amazon's API for you so that receiving a payment can kick off a shipment. It doesn't create any new potential liability for Amazon; they're not touching bitcoins and their payment for the fulfillment service is separate from what they're fulfilling.
To be honest, bitcoind, the original Bitcoin client has a very accessible json-rpc API [0]. This is the same daemon that runs behind the QT front-end of the "official" Bitcoin client. RPC is not my favorite (gotten spoiled by RESTful), but bitcoind's implementation is easy-to-use, and most languages have nice, easy-to-use json-rpc libraries [1]. You run bitcoind as a headless client on your server. It's pretty robust, and multithreaded. The benefit to that setup is that you are in control of everything, no need to depend on (or pay) a third-party. And there's no need to store Bitcoins on the server beyond what you need for your transactions, since you can set up a cron job to periodically forward x percentage of the balance to an off-site wallet with ease.
However, if you want something with a RESTful interface that you don't have to maintain yourself, ycombinator-funded Coinbase appears to have a nice API. But unlike bitcoind (which I've used for several small and one largish project), I've never used coinbase or any of the other third-party APIs.
That's the kind of set-up that has been hacked to high hell several times.
It's not that hard to understand why. Having a computer connected to the net to run bitcoind means that if you get it rooted by any chance, you just lost the entirety of your hot wallet.
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.
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.
I didn't say you shouldn't use wallets, just don't use the naive approach of having a plain wallet in a computer that's exposed via bitcoind. That's asking for it.
Cryptography is hard, but you can use this for instance:
It's already prepackaged for you. Give it a good read if you don't know it.
Free, Open Source, etc. And the author is a nice chap.
It's not the only way. But whatever you do, just don't keep a massive hot wallet in a server that's online. They will find it and if you move enough money they will put massive amounts of effort into hacking it.
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!"
actually, come to think of it, you just need to provide a Bitcoin address for payments to be sent to and a form that takes the customer's own address so you can know who paid and for what.
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).
Where to buy BitCoins easily? CoinBase is useless since they've "exceeded their maximum daily limit", and Mt. Gox wants me to verify my home address, but I just moved and don't have any bills yet.
I've had good luck with Bitfloor. They let you do a cash deposit at Bank of America, and it goes instantly to your account. No ID or addresses or anything.
Yes, they've been hacked before and lost bitcoins. I figure 1. being hacked once probably makes them a lot more cautious now, and 2. what was stolen was bitcoins that were sitting in user accounts there. You're at very low risk if you don't leave bitcoins sitting in your account - transfer them to a private wallet or convert them to USD immediately.
localbitcoins.com will work in a lot of places. ziggap.com is another one similar to coinbase. ziggap uses western union/ money gram and so has higher fees, but less wait time. also have seen btc sold on ebay, but with a pretty big markup.