TIL BuyVM offers Anycast VPS's: https://buyvm.net/anycast-vps/
Very tempted to find an excuse to use that. 😂
Anycast works fine for short-lived TCP connections, so it'd probably work fine for scaling up OpenTimestamps infrastructure. I'd really like to avoid being vulnerable to DoS attack, as I've got competitors that are straight up scammers. Currently it wouldn't take that much effort DoS attack OTS into the ground. Wouldn't take much to fix either! But better to be prepared in advance if it can be done cheaply.
There's two issues OTS calendars have re: DoS attack: each calendar server query is a database lookup (hence disk IO), and submitted digests take about a second or two to complete, so you have all the overhead of maintaining a connection until that finishes. The usage pattern makes CDN's not all that useful, as there's little opportunity for caching.
The good side, is the protocol is very low resource compared to most, and all the relevant calendar data easily fits into ram (<16GB right now).
@pete how come the DB query takes 1 second if the whole thing fits in memory?
@pox What takes about a second isn't the database query: it's the process of creating a new timestamp.
See, because I want the database to remain small, OTS aggregates timestamps together. So each second a merkle tree of all submissions is created, and the calendar only saves the tip of that tree. The database lookup is to fetch that tip, plus the subsequently created bitcoin timestamp on that tip.
So I'm thinking a good setup for DoS attack resistance would be to run the calendar servers themselves on reasonably fast machines to answer calendar db queries quickly (esp cache misses), and maybe use anycast'd on the front end w/ submitted digest aggregation to limit the geographical impact of a DoS attack.
The latter might not be relevant: a fast Rust calendar implementation can probably serve more bandwidth than I can afford on a single reasonably fast box. 😂 Modern hw is amazing.