Algos For Cryptos

Amazon AWS > My MacBook at Home

I enjoy using AWS and intend to run my bot for automated crypto trading from one of the AWS’ locations. Since my home machine depends on my “civilian” internet bandwidth and latency I will be using a data center to reduce this risk. Another benefit is that I can rent as many CPUs as necessary for data capture, analysis and trading.

Can’t Trade Alone…

All trading requires at least two sides: one buyer and one seller. My “chances” for trading opportunities are greater when I am also participating on exchanges that have already attracted many other traders. Earlier I mapped the geographical locations of the 40+ biggest crypto exchanges ranked based on their trading volume. I am adding AWS’ coordinates to get a ball-park idea which data center is “closest” to each crypto exchange. In theory, shorter distance between my bot and the order-matching “engine” should result in faster, more profitable trades. Since some trading strategies exploit differences in prices between exchanges I should be also able to guesstimate the “best” data centers for combinations of crypto exchanges.

Included and Excluded Exchages

Few top exchanges have choosen to conceal information about their location. I was able to find clues about their corporate registration in places like Samoa or the Seychelles. Since they are probably not hosting their servers in such exotic locations, these exchanges are excluded from the map:

This list in alphabetic order represents the top crypto exchanges on the map with the locations of the AWS data centers:

Click (Tap) Clusters to Zoom In

It’s Simple?

Asumming that my coordinates are reasonably precise and that order-matching engines are located in the vicinity of the exchange offices I can see that AWS Seoul should be an excelent host to bots for trading on bithumb, Upbit, KORBIT, GOPAX, COINNEST and coinone.

Likewise, AWS Tokyo is relatively near and equidistant to Zaif, bitbank, FISCO, bitFlyer, BTCBOX and QUOINEX.

AWS London is probably a decent choice for BTCC and CEX.IO and EXMO. If COINEGG is indeed in Manchester, it might be better served by the AWS Dublin.

Now, Wait a Millisecond!

Everything looks straightforward until I “poke” around Hong Kong. It is assumed to be the home to several prominent crypto exchanges but all AWS centers are quite far away. AWS locations in Seoul, Tokyo, and Singapore might work well. One way to find out what’s going on is to spin up a nano server in AWS Seoul and ping API endpoints for a few exchanges in Seoul and in Hong Kong. I hope that pings from AWS Seoul to exchanges in Hong Kong will be almost the same as pings to exchanges in Seoul.

Assumed to be in Hong Kong & pinged from AWS Seoul:

www.bitmex.com
PING www.bitmex.com (52.212.184.113) ...
rtt min/avg/max/mdev = 244.844/244.904/245.024/0.545 ms

real.okex.com
PING real.okex.com (47.90.109.236) ...
rtt min/avg/max/mdev = 84.023/84.123/84.177/0.192 ms

api.bitfinex.com
PING api.bitfinex.com (104.16.171.181) ...
rtt min/avg/max/mdev = 32.080/32.148/32.263/0.236 ms

Assumed to be in Seoul & pinged from AWS Seoul:

api.coinone.co.kr
PING api.coinone.co.kr (104.16.114.35) ...
rtt min/avg/max/mdev = 32.072/32.131/32.217/0.063 ms

api.coinnest.co.kr
PING api.coinnest.co.kr.cdn.cloudflare.net (104.16.206.233) ...
rtt min/avg/max/mdev = 32.135/32.185/32.223/0.229 ms

api.korbit.co.kr
PING api.korbit.co.kr (104.17.128.109) ...
rtt min/avg/max/mdev = 32.144/32.201/32.280/0.167 ms

Btw, crypto exchange powerhouse Binance is also assumed to be in Hong Kong and Bithumb should be in Seoul but their end-points did not respond to my pings.

Looking at the results, it appears that AwsSeoul-to-Seoul is ~32 milliseconds. Meanwhile, AwsSeoul-to-HongKong was much “slower” at 244 millis and 84 millis but also a very competitive 32 millis for Bitfinex. Perhaps my assumptions are incomplete or even flat-out wrong? I found a useful hint in COINNEST’s ping: its endpoint domain was resolved to a CNAME with the word “cloudflare” and the IP address “104.16…” looks very similar to Bitfinex’s “104.16…”. Quick IP/Geo lookup indicated that both IPs belong to the same CDN provider. In other words, the Bitfinex ping was ~32 millis because it was returned by the nearest CloudFlare edge server, probably located in the vicinity of AWS Seoul.

Another unexpected discovery was this fragment from BitMEX:
64 bytes from ec2-52-212-184-113.eu-west-1.compute.amazonaws.com

“eu-west-1” is in Dublin and I am sure that AWS Dublin would be much faster and better location for bots intending to trade on BitMEX.

Considering the above findings, the next step in my data center selection process is to measure the network latency between all AWS regions and all exchange API endpoints. I will write a Java program and use AWS’ Lambda service to ping all the endpoints for a total of ~550 measurements. Stay tuned…

Goals:

• Setup a modern blog about my work in the crypto / trading domain.
• Learn (more about) the WordPress platform & ecosystem.
• Leverage my experience with Amazon / AWS while making use of all the relevant free-tier services.
• Achieve the lowest total cost.

A “recipe” for these goals:

1. Use Namebright.com because they sell .com domains for USD 8.53.

   HOST records management for A, CNAME, MX etc. types, is included as well as a free first-year of domain privacy.

   Alternative to free HOST records management would be to use AWS/Route53 for USD 6/year (minimum) since Rout53 does not have a free-tier.

2. Use MXRoute.com (affiliate) for email/inbox-only hosting with unlimited domains & emails plans starting at ~USD 25/ year: much cheaper than Google.Apps at USD 5/inbox-month.
3. Amazon / AWS hosting & free-tier services: Bitnami’s WordPress AMI on EC2; CloudFront CDN to improve performance for visitors around the globe; S3 storage for WordPress caching & backup; free SSL cert issued by Amazon, to get the cute green lock in the address bar.
4. I like Medium’s style so I selected a free WordPress theme Wilson which I thought would let me deliver my content in a similar way: thank you Anders Norén.

Valuable “cooking” lessons I learned:

• AWS’ SSL certs require domain ownership validation. You can choose to do so via a CNAME entry or by a confirmation email sent to the WHOIS contacts. My first attempt using the CNAME, timed out after 72h and I never understood what went awry. Luckily, the confirmation email showed up immediately and I was validated in mere minutes.
• RTFM: AWS certs for use with CloudFront MUST best requested/issued in the AWS/Virginia region.
• When browsers ask for https sites or are redirected (“forced”) from http-to-https, the browsers “expect” all links/content from the respective site/domain to be also delivered via “https”. Otherwise, we will get a security warning and the browser will “refuse” to display the page due to its mixed security content.
• WordPress serves all its content with fully qualified absolute URLs. Therefore, all content is http only or https only, depending on the protocol defined in the site name configuration.
• I setup CloudFront with the SSL cert and configured it to force http-to-https for all visitors irrespective of the protocol they might have requested. Therefore, CloudFront passes all requests to my EC2/WordPress “origin” also using https. In order for the WordPress to return all pages and their links with https only, I had to setup WordPress to also use https only and respond to CloudFront with the WordPress https & cert. Allowing WordPress to still use http results in mixed security content issues when pages are processed by the clients’ browsers.
• Since CloudFront does not accept https from “self-signed” certs, I had to install a legitimate “Let’s Encrypt” SSL cert specific to my domain, on the EC2/WordPress server. Originally, I hoped to avoid this as I mistakenly assumed that the AWS’ cert on CloudFront would suffice.
• I wanted the AWS’ cert for the entire site. Therefore, I had to configure CloudFront to use my own domain name in the “alternative domains” setting. When I attempted use CF’s default domain in the WordPress CDN/cache settings I got “could not contact origin” errors.
  Btw, CF’s default domain name goes into host/CNAME records (“@” and “*”).

Conclusions & unresolved “mysteries”:

• I was somewhat wrong about https and caching. When I had to setup https on the EC2, I thought that the CDN would not cache any assets. Page performance by GTmetrix and Response/HEADERS indicate that content is being served by the CDN. I have configured an S3 “origin” to offload some assets for caching but I am not sure if CF is using S3 over http or EC3 over https and then caching after decryption.
• My EC2 does have to do more processing than I originally hoped because it must encrypt/decrypt all its communication with CloudFront.
• Domain host records use CNAME pointed at the CloudFront’s domain for my distribution. Without CF I would use A records and point them to the EC2’s ip address. If the dynamic content is always served by the EC2 and never cached by the CF due to https, does that mean that I am wasting an extra network hop between the CDN and EC2?
• If I am “wasting” a hop perhaps the “speed” of the AWS’ network between CF and EC2 makes up for the slowness of the “wild” internet between the browser and EC2?
• I used BackWPup plugin to setup WordPress backup to S3. It seems that the free version has a bug which prevents the plugin from working with S3 buckets in US-Ohio region. Instead, I set it to use the “US-Standard” setting which corresponds to the US-N.Virginia region.
• W3 Total Cache plugin does not “play” well with CloudFront backed by S3. It was pushing all wp-includes and wp-content files to S3 each time it was supposed to push just those that have changed. The consequence was that it quickly spent the entire free-tier provision for S3 operations. After a lot trial-and-error I resolved the issue by switching off the setting that says:
  

  Force over-writing of existing files / If modified files are not always detected and replaced, use this option to over-write them