I began with a set of VPSes in Japan, but actually found connection to west-coast US much better. I think a lot of locals use nearby VPSes as proxies (I know I do), and so connections, particularly https, seem to be getting throttled and blocked more often. I got blocked due to someone else on my same IP range -- didn't bode well.
Serving through CDN, I see sub-1-second page loads over 3G to W coast US. All assets will be served from CDN edge locations so it should be OK. How that scales to full-time trading will be the real test though.
For comparison, BTCChina, when not behind CloudFlare, seems to be on an east-coast Linode.
i had horrible experiences with running us-based services to the mainland. but what you say about vpses and cdns makes a lot of sense. i've only just started using maxcdn myself and haven't been able to run any mainland tests just yet.
i stress location and performance, but it really depends on what you're offering. basic trading should be fine, but if you're offering live charts and apis, then it could become a problem when serving the mainland's non-vpn userbase
(especially if you're competition IS in mainland -- YOUR service will seem slow and spotty). but i'm with you, when i'm there i have 3 private vpns in the us, eu and sg and just use the one that's giving me the best performance at the time.
For the Bitcoin server -- I looked; we began with a self-hosted solution. However, the only secure way I am really comfortable with is a dedicated server under my own control -- even whole-disk encryption means nothing on a VPS. The intermediate code is relatively backend-agnostic, so I can always go back to that route if needs be. Will possibly be adding alt currencies down the road, so would need to self-host anyway. I think the biggest draw for blockchain.info is that we plan to market it as a secure solution -- are new users more likely to trust a(nother) new exchange, or one of the biggest players on the block? I know where my money would go. It will help me sleep at night too...
i don't have any experience with the blockchain.info api, so what i know is purely from outside observation, but i just assumed so many people used the api for its "convenience" and "reliability" not so much for its security. imo security is still very much localized to your transaction server. i assume the exchange you've built will be automated for the most part, which means you will need to store those api keys on the server and at some point they will need to be
unencrypted and then transmitted to the api (which will probably be via ssl). the point right
before transmission will be the weakest link in your security chain. if that gets compromised, blockchain can't help you.
This is why I like blockhain... Yes we have to store the main password (encrypted, but reversible encryption means nothing) . But the second password is required for any move or send.
Btc in is automated by listening for transactions among a pool of user addresses that is created ahead of time (since addresses cant be created without the second password). Withdrawals are grouped and processed by an administrator who provides a secret to piece together the second password.
This second password is never stored anywhere, other than the split second in memory when actions are processed.
(Both passwords are long sha256 hashes of pretty obscure information combined with secrets.... So brute forcing isn't really an option)
So an administrator can't run off with the hot wallet coins (since they don't know either password), and someone owning the server can't do much with the coins, since they don't have the second password.
Obviously all comms with blockchain is SSL ( and we check the certificate each time)
I think it's a nice solution... And they make some nice fee income since they charge 0.0005 on everything, including moves. The main elephant in the room in my mind is uptime.
We could build something similar but on a VPS it would become the weakest link. So this way reduces the possible attack vectors a bit. Either way, this is just the current account, but it should make us less interesting.
Thank you for the recommendations. We have a waf and intrusion detection in place, and also run a self-built change check on all files. Agree that side channel attacks are probably the weakest link right now, but there's a lot we'll have to stay on top of. There's always a way in somewhere.
there are many side-channel attacks, but these 2 tools will at least cover the obvious and and alert you when attention is needed. paper wallets, hardened passwords, etc, etc, are a given.
i wish you the best of luck and look forward to the release
