How is this a time stamp? The hash doesn't change if you touch the file's modification time.
For example, if you download a signed executable, but the signing certificate expired a while ago, does that mean you don't trust the executable? If you don't trust it, every executable would eventually break when the signing certificate went out of date. The solution is to require a cryptographic timestamp proving the executable was generated at a time when the code signing certificate was valid.
That's how you can download Java applets that were published and signed in 2005 and still know the signature is valid. Not that many people are using that technology these days!
Let me give a personal example: some time ago, someone deleted the public copies of some webpages we were using in our investigation and threatened to us that if we continued, they would simply claim that our copies of were forged later (after we had contacted them), and, they thought, make us look like fools & scuttle our claims (with some hints that they might also sue us for libel to boot). Fortunately, I had been timestamping all along and had timestamped the archived webpages in question; so I could prove that my copies are unaltered from well before they raised the question, and, further, at around the same time as they were independently captured in a different archive service. After we noted this to them, they had to back down on the threats and take us more seriously.
Indeed, no you don't---not on the basis of cryptographic reasoning, at least.
Certificates expire for a reason. That reason is the assumption that they are being actively cracked, and so have a limited shelf life. You can trust a 2005 certificate only to the extent that you bank on the underlying private key not to have been cracked.
If the key is cracked, then the attackers can create a brand new file, and make it look like its existence had been certified in 2005.
Old stuff that still matters has to be re-certified with new certificates in the face the impending expiry of the old ones.
What? If someone cryptographically timestamped a particular signed file in 2005, even if Eve cracks the original public key and can now produce arbitrary new signed files with that key, they still do not have 2005 timestamps for any of those new files! They could only make 2015 timestamps. That's the whole point of cryptographic timestamps.
(If you could certify a timestamp forever, in a non-expiring, uncrackable way, why wouldn't you just use that for the whole file?)
OK, so you don't actually understand how cryptographic timestamping works or the Bitcoin version. Please read up on it before commenting.
> If you could certify a timestamp forever, in a non-expiring, uncrackable way, why wouldn't you just use that for the whole file?
What you are timestamping is the whole file!
(Of course the time stamp is for the whole file; not just for a subrange of bytes or whatever; if anything is altered, then the timestamp doesn't hold for the altered object.)