💾 Archived View for nicholasjohnson.ch › 2024 › 04 › 08 › why-i-timestamped-my-journal captured on 2024-08-18 at 19:17:37. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2024-07-09)
-=-=-=-=-=-=-
_ _ _ _ _ _ _ | \| (_)__| |_ ___| |__ _ ___ _ | |___| |_ _ _ ___ ___ _ _ | .` | / _| ' \/ _ \ / _` (_-< | || / _ \ ' \| ' \(_-</ _ \ ' \ |_|\_|_\__|_||_\___/_\__,_/__/ \__/\___/_||_|_||_/__/\___/_||_|
📆 April 8, 2024 | ⏱️ 3 minute read | 🏷️ computing
Before I talk about timestamping, I just want to make clear that this entry does not constitute a return to writing. I'm still taking a step back¹ from writing. I'm only writing this entry to give context for the new timestamp I created.
As AI improves, it will get harder to differentiate synthetic (AI-generated) media from human-created media. Thus there's a need for a verification system that can confirm the human provenance of media. What does this have to do with timestamps? Well, for sophisticated data such as this journal, timestamps can be used to prove that it existed prior to AI's ability to generate it. This proves its human provenance.
One way to timestamp data is by embedding its hash into the Bitcoin blockchain. Even if Bitcoin falls out of favor and miners stop securing its blockchain, a historical copy of the ledger would be all that's necessary to verify timestamped data. Given Bitcoin's cultural significance and the fact that its ledger is widely witnessed, genuine historical copies of its blockchain will probably be preserved for a long time, allowing verification of any timestamps within it. OpenTimestamps² is the software I used to do just this.
Here's the procedure for verifying this journal's timestamp (and thus its human provenance):
Prerequisites:
Commands:
git clone --recursive https://git.nicholasjohnson.ch/journal ots verify -d "$(git -C journal show-ref --hash signify-signature-10)" journal/static/timestamp-2.ots
Now I first had this idea back in November of 2021 and wrote an entry about it titled "future-proof digital timestamping³". There are a number of issues with that entry and I could spend time nitpicking it, but its primary deficiency is that the idea of timestamp chaining via successor ledgers is erroneous.
Timestamp chaining could perhaps provide stronger assurance of the legitimacy of the timestamps (due to the successive blockchains having the largest amount of cumulative work), but the gains in assurance would only be very marginal at best, it's all predicated on Bitcoin having endless successors that also rely on energy-intensive proof-of-work, and there would have to be software supporting such a scheme. In my estimation, that's all highly unlikely.
But one good idea contained in that entry was to restamp this journal's Git repo to future-proof its timestamp. The old timestamp was performed on the old repo which used the broken SHA-1 hashing algorithm. Since then, I converted the repo to the new SHA-2 object format and SHA-2 support in Git has been stabilized. So everything I needed to create a new, stronger timestamp was present. Well, almost everything.
The only issue I ran into was that the OpenTimestamps software does not have sufficient Git integration⁴ to embed timestamps within Git objects in SHA-2 repos like it can for SHA-1 repos. So I just timestamped the most recent tag⁵ manually, creating a fully separate .ots proof file⁶ which is verified without using OpenTimestamps' GnuPG wrapper.
Hopefully the new timestamp lasts. If not, both Software Heritage⁷ and Archive.org⁸ have centralized timestamps of this journal as fallbacks.
🔗 [1]: Journal Update 26: Taking a Step Back
🔗 [3]: Future-Proof Digital Timestamping
🔗 [4]: OpenTimestamps Git Integration
🔗 [5]: Most Recent Tag of Journal Repo
🔗 [7]: Journal Repo on Software Heritage
Copyright © 2020-2024 Nicholas Johnson. CC BY-SA 4.0.