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