Peter Todd @pete@petertodd.org

@icedquinn I literally just walk in and mumble something about "no to all" of their questions. I've yet to be challenged. I'm sure the majority of those guards know the job is bullshit too.

@drgo Fauci's antics re vaccines sure seem like he's trying to discourage people at risk from getting them, with plausible deniability...

Gotta be a lot of public health people who secretly don't want this to end. Masks alone have become literally a $200 billion/year or so business. Not even joking.

So why would elderly security guards end up doing this you might ask?

Simple: there's tons of security guards, retail clerks, etc. on various levels of disability because they can't stand/walk for full shifts. So sitting in a chair doing next to nothing is a great way for management to give them something useful to do while they (hopefully!) recover.

Hence the least healthy people end up with jobs that if we were following science would go you young teens. But this isn't about science...

The local malls are now required to "screen" people. So an elderly security guard sits in a chair by the door with an ill-fitting masks, and asks you if you have any covid symptoms or have been travelling. They have no way of verifying any of that.

Something tells me this is getting more elderly security guards infected than anything else...

Public health is a scam. I mean that quite literally: they know this nonsense is harmful. But theatre fools the voting public into paying their salary.

@drgo @pox Well, if you can wait, just save the data for your timestamps. OTS already has that functionality after all: the 'ots upgrade' command does that.

The reason why OTS has calendars is just to be able to return timestamps ~instantly.

@drgo @pox Note that calendar data *can* be compressed! You might think since it's the output of hash functions, it'd be uncompressable. But remember that 1/2 of a merkle tree can be derived: the intermediate digests. So the bare minimum is actually just slightly over 32 bytes/second, or 1GB/year (the slightly over part being the bitcoin timestamps themselves). The tradeoff of course is having to recompute digests. With SHA256 opcodes, that may be even faster than disk!

https://en.wikipedia.org/wiki/Intel_SHA_extensions

@drgo @pox Now, it is true that there may be some clever cryptography tricks that could be used for the specific case of things like phones. But I really don't think it's worth it: all those tricks would have to be something other than standard hash functions. Long term timestamps are useful in case of things like quantum computers - I'd rather maintain as few as possible cryptography assumptions to continue being useful for that.

@drgo @pox Not really. Someone needs to store that data. If not the calendar server, then the client.

...which means clients would have to update their timestamps to be able to validate them in the future. That's just not feasible for a *lot* of applications, eg git commits.

Uncompressed, each commitment probably takes ~150 bytes of memory, or ~5GB/year; RAM has flatlined at about $10/GB. That's not free. But it's still very affordable.

https://aiimpacts.org/trends-in-dram-price-per-gigabyte/

No such thing as a 100% vegan diet.

I used to have pet rats. Wonderfully smart and sociable animals. Also, a pest that farmers need to exterminate.

https://www.youtube.com/watch?v=l2Pyu-Cj0gg

@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.

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).

@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. :)

@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.

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.

TIL BuyVM offers Anycast VPS's: https://buyvm.net/anycast-vps/

Very tempted to find an excuse to use that. 😂

https://sebastianrushworth.com/2021/01/10/are-the-covid-vaccines-safe-and-effective/

Re: the Astra-Zeneca vaccine:

"The British and Brazilian arms were single-blind, while the South African arm was double-blind. ... This is strange, and really quite unforgivable, because it makes it much easier for the researchers to manipulate the results... There is no reason why a big, well-financed study like this shouldn’t use a double-blind methodology across all trial arms."

WTF.

Read the rest of the article, that's not even the only thing wrong with the trial.

@waxwing Pity. I really don't need an order flow for a simple donation, at least right now.