The image contains the previous block’s hash.
Wouldn’t this establish both a lower bound and an upper bound on the time the image could have been produced?
The image contains the previous block’s hash.
Wouldn’t this establish both a lower bound and an upper bound on the time the image could have been produced?
Back when I was on Twitter and following a lot of infosec accounts, it was quite common to see tweets that were just a hash. Sometimes they'd have an explanation "Zero click RCE in Android 10 - {hash}"
In the past I've used gmail for this internally - email a hash of something critical (logs, configurations, decision docs, etc) to a dedicated gmail account - relying on the in feasibility of "faking" the date/time once it's onb Google's servers.
The important thing here would be to make sure those hashes are published somewhere where its technically infeasible for the police to change it after the fact, so not on a platform the police run or p-aid for (or that is run or paid for by an organization that the police can request or coerce the operators to make changes).
As a community service you need them to have enough scale that no individual hash or source can be tampered with without being likely to become known as unreliable to everyone else as well ala certificate transparency records.
(You could probably just bootstrap let's encrypt for this - issuing a certificate you use to sign a bunch of data would stamp several minimums on the order anything could have happened).