TIL BuyVM offers Anycast VPS's: https://buyvm.net/anycast-vps/
Very tempted to find an excuse to use that. 😂
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).
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.
@pete I had VPSs with buyvm. Good experience.
@verretor Currently I use Amazon and Digital Ocean on the two calendar servers I run. That works fine. But I spend a fair bit per month ($150 or so), and that doesn't even get me enough disk space to run archival nodes.
Also, both Amazon and Digital Ocean's backup schemes are annoying, as it's not that easy to download snapshots of your disk images.
@verretor I also don't like how annoying it is to get btrfs root drives... I'd *much* rather have the piece of mind that the data on disk is actually correct via btrfs's checksums. It's saved my ass before when flaky hardware was causing corruption. I have ECC on my desktop for a reason!
I'm sure you can build custom images; I'd rather not use my time learning a bunch of modern system administration. :)
@pete Understandable. Time is precious.
@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.
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.