Doesn’t this rely on Surety being trusted though? It seems technically possible for Surety to modify documents consistently in and out so the hashes are consistent, but not representative of the submitted documents.
Especially back in the 90s when generating crypto hashes wasn’t as easy for users.
So this is similar to notaries where the trust lies with a different party.
The killer app, I think, that made blockchain blockchain is the trustless nature.
Surety is certainly cool, but just a better version of putting a hash in a bank’s safety deposit box.
Surety is not a trusted central authority. There is no mathematically feasible way to backdate a document and weave it into the chain. The only way to circumvent the system would be to generate the same submitted hash value (using two different hash algorithms) with a different document. Additionally, for it to be actually useful, you would need to generate a hash collision for a different document with a purposeful modification (for example, changing the amount due for an invoice.) I can't begin to calculate the odds on making that happen.
Also note the hash values sent to Surety were calculated on the end user's computer. Surety never sees the actual file being timestamped.
As for the safety deposit box metaphor, the Haber-Stornetta approach is akin to nailing the hash to a post in the town square.
Especially back in the 90s when generating crypto hashes wasn’t as easy for users.
So this is similar to notaries where the trust lies with a different party.
The killer app, I think, that made blockchain blockchain is the trustless nature.
Surety is certainly cool, but just a better version of putting a hash in a bank’s safety deposit box.