"trustless" is not the word here... you are trusting the economic incentives of the blockchain system to remain in-tact. But I do agree with you that one could feasibly trust it "more" than a single entity protecting a key and acting correctly. However in practice "more" comes with a very very hefty price tag, in my experience one that makes it completely impractical in the real world. Look at the verification requirements:
- run a full bitcoin node, download the full blockchain
- wait several hours after the timestamp is produced for the system to publish to blockchain (which also reduces the granularity of the timestamp, within this window the system is only "as secure" as a solution trusting a single entity)
- download all the commits in the Merkle tree that was signed and published, and search for the commit you are verifying within the tree
Security in practice is about tradeoffs, and I can't imagine a scenario wherein these tradeoffs would work for me without ultimately having a centralized provider verify them for me, at which point I just have complexity with no gain over the traditional trusted timestamps.
Yes, because it's very small list of companies that have trusted timestamp servers and follow a strict set of rules re: key storage, rotation, issuance, etc.
TBH this is a good argument not to trust timestamp servers. AFAIK usually you just want to stick to one, and not treat a group of them interchangeably (ala the Internet Root Bundle). In any case, the owners of the repo (or email message) would decide for themselves which one(s) they want to trust.
We do use just a specific one at work. My point was that it's a highly secured process limited to just a few companies, and becoming one is a lot of effort, if at all possible. There are even some RFC3161 servers just not trusted by Windows, ergo: useless for most timestamping uses.
- run a full bitcoin node, download the full blockchain - wait several hours after the timestamp is produced for the system to publish to blockchain (which also reduces the granularity of the timestamp, within this window the system is only "as secure" as a solution trusting a single entity) - download all the commits in the Merkle tree that was signed and published, and search for the commit you are verifying within the tree
Security in practice is about tradeoffs, and I can't imagine a scenario wherein these tradeoffs would work for me without ultimately having a centralized provider verify them for me, at which point I just have complexity with no gain over the traditional trusted timestamps.